Faith Peterson

IIBA tip explains «extends» use cases

noreply@blogger.com (Faith Peterson) — Thu, 12 Mar 2009 15:59:00 +0000

The latest IIBA® Tips & Techniques Bulletin has what seems to be a pretty useful explanation of the «extends» use case relationship. Should help BAs who don't have a programming background. If you've been struggling with what «extends» is for, see if this helps.

Tip #2: «Extend»’ing vs. «Include»’ing a Use Case

When does it make sense to split up a Use Case, and what options do I have?

«extend» and «include» are useful ways to reduce duplication and help sequence your work.

Develop an Include use case if its functionality will be required by multiple use cases. While most Include use cases tend to be fairly simple, formally capturing the details in a single Include use case allows you to avoid repeating requirements.

Examples of Include use cases: logging into a system or automating a credit check.

Extend use cases formalize an alternate flow (from one use case) into a separate use case and apply only to that other use case. A common reason to create an Extend use case is to accommodate release planning. By moving an alternate flow off into a distinct use case, it can be prioritized and tracked separately from the parent use case while still being able to show how it fits into that bigger picture.

Those looking for a good basic description of a variety of modeling techniques, including use cases, might like Scott Ambler's Agile Modeling site. There are a lot of sources for nuts-and-bolts info about use cases, but Scott also discusses how to use good judgment when deciding what models to create.

More agile BA articles: Google

In search of great business analysis: imagination, analytical power, critical thinking skill, creativity, wisdom

noreply@blogger.com (Faith Peterson) — Mon, 09 Mar 2009 17:22:00 +0000

Recently I've been asked how to identify and develop business analyst talent. I've found it to be an interesting question and would like to offer some observations.

The software development field has been grappling for nigh on to 50 years with problems related to requirements. For a generation the business analyst was seen as the key to solving those problems. The Agile generation saw traditional requirements practice itself as the problem, with some members advocating the radical disintermediation of software development. The business analyst community has recently begun to address the challenge by introducing greater professionalization to its practice as well as adapting its methods to the Agile world, even as an almost nihilistically pragmatic "post-Agile" movement emerges (apologies to Jason Gorman). This history begs the question of whether we, like Diogenes, ultimately will be disappointed in our quest for a solution to problems with requirements and, ultimately, successful project outcomes.

None of these approaches tries to identify what distinguishes great business analysts from the competent or the ineffective. Are BAs made or born? Can business analysts be trained, coached, or mentored to greatness? Will certification result in better requirements practice? Can using subject matter experts as BAs improve the chances for project success?

A case can be made that a handful of intangible qualities characterize truly great business analysts, whether they work under that title or some other (such as programmer/analyst, SME, product owner, user experience designer). These qualities can be refined or developed if present in raw or latent form. I am skeptical, though, that anyone can create them through training or experience. These qualities are:

Imagination
Analytical power
Critical thinking
Creativity
Wisdom

The information space has to be imagined in order to explore it (you have to know what question to ask before you can ask it), and re-imagined as new information is discovered. The information, once gathered, has to be interpreted, restructured, and communicated so that team members can together create and craft a solution. All along the way information and ideas must be evaluated and good judgment must be exercised. Even Agile methods that use creating the solution as the exploration process, omitting the formal BA role, still often find that success relies, as does that of any approach, on the team's ability to manifest these qualities.

Frameworks and conventions serve, if these qualities are present, to reduce risk, bring stability to the effort, and help organize and communicate it. Without these intangibles frameworks and templates can actually increase risk because they create the illusion that the requirements effort was done – the “form over substance” problem.

I'd love to hear your comments as I “think out loud” in subsequent posts about whether or how

these qualities can be developed
various approaches, tools, and techniques intended to improve requirements practice can support practitioners and teams who (inevitably) are unevenly gifted.

Brightkit Hands-On: One Month In

noreply@blogger.com (Faith Peterson) — Thu, 01 Jan 2009 20:13:00 +0000

Update 9 Mar 2009: Brightkit is now HootSuite and has continued to add and improve features.

I reported on Brightkit's functionality in mid-December. I've now been using Brightkit about a month and I'm still impressed with its labeling, navigation, and information presentation. Brightkit's UI progressively reveals operations, data, and forms so they are readily available but don't overwhelm. Its designers and developers roll out UI tweaks rapidly in response to user feedback. (Some early Brightkit idiosyncracies seem to have been resolved already.) I hope to see a more compact, information-rich interface at some point, but the service's utility outweighs the remaining (minor) irritants.

Brightkit's dashboard provides immediate access to stats for recently-sent tweets and tells you if there are any pending outbound messages, new @replies, or direct messages. You can create new tweets for any of the profiles directly from the dashboard, where you can also manage Twitter profiles and editors.

The tweet form conveniently embeds link shortening. Clicking “Shrink It” shortens the link and updates the character counter. “Edit” reveals the original link.

Graphs in the sent messages list present link stats. You can sort by tweet date, create date, or author. Date range shortcuts filter for today, week, month, and year. The custom filter defaults to the endpoints of the time period you've chosen, an example of the thought put into UI details.

The list also displays tweet error alerts. Clicking them reveals the Edit Tweet form so you can reschedule – another example of Brightkit's thoughtful UI approach.

It's easy to switch profiles with any of three dashboard options. The “jump to profile” selector bypasses the dashboard. Labeled tabs and icons make each profile's content and Twitter actions readily available. “Sent” and “pending” icons provide category cues for each message - helpful when tabs scroll out of the viewport.

The feed search's “Show Examples” reveals clear translations of the simple syntax and let you run each example to preview results.

Brightkit's large type and spacious layout make it easy to learn but soon got in my way. Showing and hiding stats per tweet and jumpy scrolling make monitoring click trends a little awkward. With just three profiles and a couple dozen sent messages I'd already like to see a no-training-wheels version. Overall, though, Brightkit's UI brings its power easily to hand. For me, its utility and convenience remain compelling.

Hands-on with Brightkit

noreply@blogger.com (Faith Peterson) — Sun, 14 Dec 2008 20:18:00 +0000

Update 9 Mar 2009: Brightkit is now HootSuite and has continued to add and improve features.

Brightkit bills itself as “the ultimate Twitter toolbox” that “lets you manage your entire Twitter experience.” I've been using Brightkit for about a week and I like the way it combines services. So far I'm still using other clients for reading, but Brightkit has already become my main authoring and management client. Here are some features I've been enjoying.

Add accounts
Brightkit's dashboard makes it easy to work with my three Twitter profiles. I can switch easily among profiles to monitor tweets and follow, reply, re-tweet, send direct messages. Each keeps its own history of pending and sent tweets, @replies, direct messages, and saved searches. Brightkit says they're working on tools to track and manage friends and followers, capabilities it needs to become a complete Twitter presence and reach management application.

Schedule tweets
I tend to generate tweet-worthy observations in batches, but I want to maintain a steady Twitter presence when people I care about are watching. With Brightkit I can schedule tweets at five-minute intervals starting at now +15 minutes. I can delete, edit, or change the send time of the pending message. Brightkit will (optionally) e-mail me when my tweet is sent.

On the downside you can only post your tweet to one account at a time. My profiles have very different goals so so far this hasn't been an issue for me, but it's easy to imagine situations that would benefit from this.

Monitor reach with link shrinking and tracking
Brightkit integrates Tweetburner-like shrinking and tracking capabilities into the message editor where it automatically adds the link and updates the character counter. Stats report daily click counts with more stats on the way.

Add editors
You can share authoring responsibilities for a profile without giving people access to all the profiles or to Brightkit administrative functions – useful if you have a social media presence team.

Search and save keywords
Monitor presence and buzz with saved searches for each Twitter profile. Go beyond keywords to find messages containing hashtags or links, sent before or after a certain date, or to, from, or about a Twitter profile. I'd like to be able to monitor streams side-by-side as in Tweetdeck or Monitter, but if I want to check periodically or cycle through topics the current feature works fine.

All of this comes wrapped in a open, Web 2.0-ish user interface, which I'll review in a later post.

Twitter holiday helpers

noreply@blogger.com (Faith Peterson) — Sun, 07 Dec 2008 20:17:00 +0000

These Twitter-based services will help you save money and stay organized through the retail (er, Christmas) season and beyond.

Find a Wii or WiiFit

Those of us shopping for a Wii or WiiFit (and who isn't?) need all the help we can get. These Twitter bots keep checking major retailers and tweet links when they detect available stocks.

WiiTracker (twitter.com/WiiTracker) sends updates like this:

Costco.com has the Nintendo Wii Super Mario Galaxy Bundle in-stock for $350 http://tinyurl.com/ytfnmd 11:11 AM Dec 5th from twitterfeed

NowInStock (twitter.com/NowInStock) and NISWiiFit (twitter.com/WiiFit) check stocks
at Amazon, Best Buy, Walmart, and other retailers. (www.nowinstock.net). You'll get a message like this one:

Nintendo Wii Fit in stock for $89.99. Go here http://tinyurl.com/6rab3l 2:00 AM Nov 28th from web

Get a PC or laptop deal

Dell Outlet announces deals via Twitter at twitter.com/delloutlet. For example,

20% off any Outlet Inspiron™ Mini. Enter code at checkout: SDN2Z85FXG5XD9 http://tinyurl.com/6gk7cq - expires 11:59PM CT 12/8. Online only 7:06 AM yesterday from web

New offers posted for Season of Savings this morning. 15-20% off select Dell Outlet products: http://tinyurl.com/5tamne 9:44 AM Dec 4th from web

Track gift shipments

TrackThis (twitter.com/trackthis) sends you package tracking updates by direct message. Send TrackThis a direct message with the FedEx, UPS, USPS, or DHL tracking code first and a nickname for the package, like this:

123456789123 Macbook Air

They'll send you a direct message each time your package changes location.

trackthis Macbook Air: In Transit To: Lousville, KY 09:25 am April 16, 2008

Have a holiday secret you can't wait to share?

Spill the beans to SecretTweet (secrettweet.com). The secret will be posted publicly but completely anonymously at both secrettweet.com and twitter.com/secrettweet.

Tweet Sheet

Finally, get Jason Theodor's super-portable, super-simple "Tweet Sheet" so you'll always have the command list with you.

Chicago Agile Project Management meetup

noreply@blogger.com (Faith Peterson) — Sun, 30 Nov 2008 00:44:00 +0000

If you are an Agile practitioner you might be interested in the Agile Project Management meetup. The meetup is new with 40+ members and meets monthly.

Dec 2nd's topic is user story life-cycle patterns from backlog to production, a topic of interest to business stakeholders and business analysts in addition to project managers and engineers.

Get information at Chicago Agile Project Management at Meetup.

Game-day: your clutter is not my clutter

noreply@blogger.com (Faith Peterson) — Tue, 02 Sep 2008 02:18:00 +0000

37Signals' Ryan Singer joined the controversy over the TripLog/1040 iPhone app's UI. Critics have faulted it as cluttered and, not to put too fine a point on it, ugly. Ryan points out that the designer made a concious tradeoff in order to meet user requirements for fast access to the two most common actions.

TripLog/1040 is a model of concision compared to real-time game trackers now common on professional sports Web sites such as the NFL Game Centers, the PGA shot tracker, and MLB Gameday. These applications provide a dynamic dashboard that gives direct access to scores, lineups, play-by-play in text and graphics, individual and team stats, and all manner of other information depending on the sport. Although they aren't mobile apps like TripLog/1040, they do illustrate that sometimes a UI needs to have a lot going on if it's going to meet users' expectations.

These applications are targeted at the needs of serious (read motivated and engaged) fans, whether of a team or a sport. They assume the viewer has a certain minimum of domain knowledge, enough to expect certain kinds of information. Furthermore, sports have long-standing conventions for representing game data with which they viewer may be assumed to be familiar. Event viewers are accustomed to processing several streams of information as they watch a game or event - at minimum the action and the scoreboard, with additional information that varies with venue or medium. Many also have their own collection of facts, stats, and other contextual information at the ready, either in their own memories or their co-viewers'. Some watch multiple events at the same time, through premium broadcast packages or using picture-in-picture, or simply timeslicing their attention to various broadcasts.

Game-tracking applications reproduce this rich information context on the Web. As a standalone experience, the applications re-create the suspense, anticipation, and armchair analysis parts of the sports-watching experience. They can also supplement individual or shared viewing experiences as information resources. Because the user doesn't have to navigate a page stack, the user can enjoy the experience rather than hunt - or wait - for hidden information. On the other hand, supplemental information is available on demand. Fans can explore it at will, for example, during breaks in the action, to get context for the next action, or to try to anticipate a team's next strategic moves.

If these applications were less "cluttered" they would also be less useful, possibly to the point of failing utterly to achieve their purpose. Game-day applications intentionally create a rich information context that match the needs and characteristics of the audience, and masterfully leverage the existing cultural context in which sports are played and experienced.

The road is paved with good intentions

noreply@blogger.com (Faith Peterson) — Mon, 01 Sep 2008 22:42:00 +0000

There's an interesting discussion going on at Chad Meyers' blog about quality in both design and execution. Chad argues there is such a thing as Good Design, that knowledgeable observers can reliably discern its presence, and that "but it works!" is not a defense or justification for bad design choices.

The bad design characteristics Chad spotlights prevent teams from responding effectively to demands on the application. With each release the team is less and less able to respond until they are locked in to long projects that deliver little incremental value. How do teams start down the path that leads there?

Chad's post hinted at an important consideration that doesn't seem to get enough attention. Too often people make fast delivery of finished features the top priority, then define everything else as speeding up or slowing down delivery. The problem is that driving to "finished features" (where finished = fully realized) prevents the team from engaging in "fast fail, fast feedback" cycles. If there is also a stated desire to work in an "agile" fashion the team might try to marry the "finished feature" driver with a short-timebox approach with disastrous results. On a large project few fully-realized features can be started and delivered in a single 2-4 week period.

The Agile team will look for a way to decompose the desired end feature into meaningful chunks and distribute the work across the team such that each 2-4 week period delivers a coherent, complete piece of functionality. The wish-we-were-agile team calls on the team to keep the feature "simple," not to "gold-plate" it. Once headed down this path all kinds of things become gold-plating - error handling, usability, even the goal of working software can be set aside under the banner of producing "good enough" software quickly.

Of course there is nothing wrong with "simple," "good enough," or "rapid delivery." Problems arise when the team identifies "simple" feature realization and "simple" process with undesigned, untested and incomplete. The team might find itself choosing to hack up a feature, not because it's a justifiable approach given the business needs but because their inability to decompose the feature and plan across iterations has created an artificial pressure to cross the feature off the project plan. That team can report that features are "done" but pays the price later when the customer doesn't accept the feature or the market demands more.

Done-ness, Denial, and Golf

noreply@blogger.com (Faith Peterson) — Sun, 31 Aug 2008 19:08:00 +0000

Totally Test-driven Scrum Delivers Better Objectivity In Measuring Real Progress - Agile Software Process Improvement

Progress is measured entirely in terms of story points collected for tests passed. There is no "A for Effort" in my way of doing things. It's either testably delivered or it's not.

The analogy I use - and, yes, it's a golfing analogy - is to differentiate by measuring the completeness of a hole by whether or not the players took the shots they planned to vs. whether or not the ball actually finished up in the hole.

Jason Gorman puts his finger squarely on one of the keys to software development success. Performing tasks only matters if they result in complete and correct work product.

Jason's golf metaphor conveniently illustrates a couple of related antipatterns, "close enough" and "pick it up after 10 strokes."

In "close enough," someone makes a decision that whatever is currently implemented seems pretty done, so the developer should move on and try to get something else implemented. This is like finding yourself on the green putting for double bogey, and deciding to stop and move on to the next tee. You cover all 18 holes in 4 hours, but you can't post a score because you haven't really played the round.

In "pick it up after 10" the team concedes its inability to bring a feature to testable completion. Just like a course policy to keep people moving around the course, the software team decides that they have spent all the time they can on a feature and must move on. Like the 10-stroke golf hole, they've used more time than they expected and didn't achieve the required result, but they figure they've done all the can in the time allowed. If the customer is lucky, the 10th stroke will be on the green close to the hole. If not, the 10th stroke will fail to clear the edge of the bunker and trickle back into the sand.

I am still learning about Agile methods, but I have to believe the Agile team would have a couple of responses. "Close enough" is essentially a quality issue; the team thinks it's implemented something acceptable even if not what was asked for or agreed to. If the product owner accepts the close enough solution, just like in the cartoons the hole can slide over under the ball so it can drop in. Voila! No longer close enough, the feature is now done.

"Pick it up after 10" seems like a reasonable strategy on the surface. It's the golf equivalent of timeboxing. Teams get into trouble only if they mark the feature done and check it off the list. Seems to me the Agile team might talk it over with the customer and decide they're only go to play the front nine today. Playing the hole to completion will mean they can't finish the back nine, and the customer just can't accept the ball-in-the-bunker solution. Teams create problems for themselves when they pick it up and move on to the next hole, card a 10, and don't tell anyone about the feature's unfinished business.

Closely related to "pick up after 10" is the mulligan. In some respects mulligans are necessary, even a mark of good practice, in software development. You learn from the failed attempt, and try again. Just as in golf, though, mulligans don't show up on the score card. The proud player strides off the 18th green tallying up his 90-something score, but everyone in the group knows Mr. Mulligan couldn't have broken 100. On software projects there's a lot more at stake than who buys the first round. Unreported mulligans eat up time, and worse, keep the team from assessing its own likely performance on future efforts. Mulligans often lead inevitably to "close enough" and "10-stroke limit" situations.

Ah, golf. You can fool yourself if you like, but the rattle of the ball in the cup is what the game is all about.

Betting on Scrum

noreply@blogger.com (Faith Peterson) — Sun, 24 Aug 2008 01:20:00 +0000

It's been a year since my ScrumMaster training - time to renew my Scrum Alliance membership. Time to consider the value of membership. Time to consider my place in the Agile community. Time to decide if, as an experience designer, I can find a place in that community!

First, what did I gain for my original investment of $1300 out of pocket and a couple of vacation days?

I discovered Jeff Patton's excellent work. He offers one of the best collections of experience design resources I've found at his site, AgileProductDesign.com. The discussion list he moderates on agile usability attracts leaders in both fields.
I'm happy to work in a framework that values empathy and story in addition to analysis and research.
I like working with and learning from engineers. I'm glad I get to talk with them more.
I'm passionate about enabling real people to do real things, and with tools that come easily to hand and leave them happy. Seems like lots of Agile engineers are, too. I like that.

I've found some things less congenial.

I'm tired of "how many agilists can dance on the head of a pin" discussions. Who's really doing Agile? What methods are really Agile? Can you be an Agile practitioner if you don't produce code? Which Agile guru speaks with the most authentic voice? Can you trace your Agile sensei's pedigree through an unbroken chain of master and student to the founders? Are you still Agile if you learned from someone else? What does the Manifesto mean and whose interpretation is Agile?
The Agile world does not seem to be a comfortable place for user experience practitioners, still less for business analysts. I have been stunned by the number and intensity of insulting, patronizing, and downright hostile opinions I have seen expressed. Manifesto values like respect have at times been glaringly absent.
Scrum is a hard practice to evangelize. Managing a product backlog or scrum backlog seems to require discipline at least as great, if not greater, as does "traditional" project planning. It's more structure than people who don't like project management overhead want, and people who have to pass regulatory audits are afraid it's not enough.

The software world has never been without its religious wars, and you can't please all the people all the time. Experience designers, product people, and engineers eventually will find their places under the Agile umbrella.

And somewhere there's a dogma-free Web app team full of people passionate about enabling people to express their personal and professional power through software - and room for one more like them.

At least, I just bet $50 on the possibility!

Designing for the Edges

noreply@blogger.com (Faith Peterson) — Sun, 24 Aug 2008 01:03:00 +0000

"Explore your edge cases for the sake of innovation."

Nick Finck is just one of the prominent designers who see the value in edge cases. On the other hand, the casually dismissive "Oh, it's just an edge case!" is all too commonly heard. Before tossing out your edge cases altogether, ask these questions:

Is the case a user goal believed to be shared by only a few users?
Is the case created when technical limits prevent the application from fulfilling a user goal?
Is the case created when users interact with the application in unexpected ways?

If the answer is "Yes," the edge case indicates the opportunity to introduce delighters/exciters, usability improvements, technical innovation, or trend-anticipating product innovation. Capture this information somewhere for follow up if you must drop the case from your current design effort.

I saw these factors in action some time ago when I was designing a new, much-requested, feature. One customer had what some believed to be a novel requirement. The requirement seemed to make business sense. The solution would extend an existing feature and require the addition of a minor option to the feature I was designing. Even so, my business stakeholders asserted this customer's request was wholly unique. They were sure no other customer would use the new option because, the stakeholders believed, none of them used our application the way this customer did.

I decided to inquire further. After all, these same people had asked us to invest a significant part of the project budget to design a different capability targeted at the very use pattern they now were sure was used by only one customer. It didn't add up.

Sure enough, there were customers who had asked for something similar. Engineering had not anticipated their requirement in their original design. Later, engineering removed a configuration option from a related feature. Without the configuration option, the first feature was unusable.

Someone had figured out a hack that mimicked the desired behavior, a hack that was subsequently employed for other customers. The hack was "good enough" - until a customer needed both the original feature and the flawed related feature. The workaround obscured an underlying limitation in our application that could have been easily remedied at any time.

This "edge case" qualified on all three criteria: people believed the request was idiosyncratic, a technical limitation prevented solving a customer's business problem, and the need to solve the business problem was unexpected. By repairing the flawed feature we could serve the insistent customer to their satisfaction, and deeper-than-face-value analysis revealed prospective customers would likely appreciate the feature, too.

Read the 4-part series Designing for the Edges at Functioning Form, where Luke Wroblewski collected a number of perspectives on the value of edge cases.

noreply@blogger.com (Faith Peterson) — Sun, 26 Aug 2007 16:40:00 +0000

Over at Russell Wilson's blog guest blogger Ben Erwin raises the question of how valuable good design is to a successful legacy application. In his example, if a prospect wants XYZ report, sales needs it fast to close a deal, and engineering can deliver the report faster than it can if a designer participates, what's wrong with that? I guess nothing - even a rock will pound a nail after all, and if you have to nail something right now and all you have is a rock there's no reason you shouldn't try to use it. How many of us have resorted to using a shoe as a hammer in a pinch? But being minimally serviceable transforms neither a rock nor a shoe into a hammer.

My further comments on Ben's post:

It used to be said that a tool might "come well [or easily] to hand." How a software feature "comes to hand" is the designer's province.

Luke Wroblewski has written that design is the "manifestation of your product strategy." Everything about your product says something about your company. All designers are experts in communicating via the tangible and intangible characteristics of their chosen medium. Graphic designers are experts in communicating via the characteristics of advertising or of marketing collateral. Why do companies invest in creative services for branding? Why not just have the Photoshop production guy create your collateral without involving a graphic designer?

Other designers do the same through the media in which the products they design are realized, architects, through their buildings’ characteristics, and interior designers through the beauty and utility of their spaces. Sure, you could order up some lobby furniture and let the guys who deliver it decide how to arrange it. What difference does it make as long as people can find the card swiper? Most companies that can afford in-house software development efforts might care a little more than that what their lobbies say about them, and might therefore hire interior designers. How does that show up in the bottom line?

That said, we should consider whether it’s inevitable that design = slow. As designers, can we accept that there might be such a thing as “good enough design,” and that some software engineers are capable of it? Can we recognize that the best software engineers do care whether their applications come easily to the user’s hand? Can we trust the sales and marketing organization to make reasonable judgments about whether a feature has importance to just one customer or has the potential for a broader competitive impact?

If we make those choices, what, then, is our value? Kevin McCullagh, writing in last fall’s Design Management Review, makes a powerful argument for designers, whom he characterizes as uniquely capable of interpretation, tangibility, synthesis, and resolution. And good designers “are smart at turning knowledge into action—they solve problems, resolve tensions, draw tangible and practical conclusions, and hit deadlines.”

The new manager is a designer

noreply@blogger.com (Faith Peterson) — Wed, 08 Aug 2007 00:05:00 +0000

Since My ScrumMaster training, as an experience designer and manager I've been thinking a lot about the value of those roles. At first I was tempted to think that Scrum meant organizational managers are obsolete. How could they, after all, do anything but obstruct the Agile organization? Well, Agile is onto something there - but if so, it's to expose most companies' failure to value and develop an effective management practice.

I've decided that every manager's job is to create an effective organization. If a manager isn't working today to help the whole organization work smarter with better results than it did yesterday, that manager's company is not deploying its headcount for highest business value.

My first stint as a department manager gave me an established team of programmer/analysts and help desk analysts. As it happened, the company relied on me most to manage projects and tasks the department's members were working on. To the people who reported to me I was an interrupt-managing interface to the rest of the organization.

Something didn't seem right. What of serving a team that is effective and satisfied, proud of their accomplishments and continually learning and growing? What of moving beyond caretaking or task management to finding new ways to add value? It seemed that outside of the budget and annual reviews (to which most employees and managers paid lip service) department management seemed to exist mainly to relieve the administrative burden of higher-level managers.

I went on to do my tour of duty as a consultant. I watched project managers create and shepherd projects that delivered value-generating products. I watched product managers deploy that product to realize its power in the marketplace.

In a seemingly unrelated activity, I've been designing a BPM application in which reporting relationships and organizational structure can be used for various process management purposes. In the the world of workflow, organizational units become active delivery mechanisms of essential resources.

Now all the pieces came together. Project managers deliver products via projects. Product managers deliver revenue via products. And organizational managers deliver effective human systems for deploying expertise, coordination, authority, and responsibility. To do so, managers have to design experiences and interactions.

As it happens, I've been seeing quite a lot of discussion pointing to this very conclusion. Next month Richard Buchanan will speak on management as design in his presentation The Four Orders of Design at the Design Management Institute annual conference.

I'm both a designer and a manager; expect this topic to become one of the main themes here.

Product Design Matters

noreply@blogger.com (Faith Peterson) — Sat, 21 Jul 2007 17:40:00 +0000

Luke Wroblewski (Yahoo!, Functioning Form) talks about the strategic importance of product design at SHIFT 2006 (Lisbon).

A recent trainee's comments on the Scott Ambler vs. CSM debate

noreply@blogger.com (Faith Peterson) — Wed, 04 Jul 2007 21:43:00 +0000

Last week I completed the Scrum Alliance's Certified ScrumMaster training. Coincidentally, Scott Ambler's sidebar "Bringing Ethics to Scrum Certification" had appeared just a couple of weeks earlier (Coming Soon: Agile Certification, 8 Jun 2007). I had opportunity to read Ambler's article between my training days 1 and 2. I find myself thinking that if the 2-day course were called "Scrum Alliance-Certified Training in How to Be a ScrumMaster" the ethics issue - to whatever extent there is one - would shrink dramatically.

First, let me say I agree with Ambler that any professional certification worthy of the name should have some real teeth, with real professional development and demonstrated experience requirements as well as an exam. If a certifying body endorses an individual as competent, that body should have reason to do so. And - to whatever extent it might happen - it's just not OK for trainees or vendors to present attendance at a class as in any way equivalent to the achievement of a professional designation like the PMP.

That said, I found the training useful and I would take it again. I didn't expect to receive a professional designation. I expected only that someone who knows what he is talking about would transmit accurate and useful Scrum knowledge. I also did not expect to become a master of Scrum through taking the 2-day course. Rather, I expected to have the understanding necessary to perform the duties of the ScrumMaster role on a real-world project. At the start of our training that's what our trainer said we could expect, and I believe it's what he delivered. I list the Certified ScrumMaster training in my resume and online profiles along with other professional development and training experiences, where I hope readers will understand it as evidence both of my commitment to ongoing professional development and to Agile - a commitment I've backed with $1200 and 16 hours of vacation time.

Schell Acres - attorney helps Illinois go green

noreply@blogger.com (Faith Peterson) — Sun, 24 Jun 2007 18:46:00 +0000

My friend, attorney, and former legal editor Rich Schell set off down the green agribusiness path a couple of years ago when the publishing company he wrote for closed its local office and he inherited some land in Polo, Illinois. Since then he established Schellacres.com to serve biofuels, green, and fiber entrepeneurs. Rich is a smart guy and a good person making a difference.