People who already use Scrum will only find one new thing in this article – a way to communicate what happens inside a sprint that has proven effective for me.  People who are new to Scrum who wonder “how do things work inside a sprint?” will see how things work in a way that avoids hyperbole and is easy to map to what they already understand from traditional software development processes.

Two Teams Separated by a Common Process

George Bernard Shaw was an Irish author in London who memorably said “England and America are two countries separated by a common language.”  The same can be said about teams developing in agile and waterfall processes.

The story of agile adoption is one that has many colorful examples of adoption and of spreading the gospel.  Some practitioners traveled across the ocean from the agile continent to the lands of agile and opportunity to reap the rewards.  A few of those, after realizing the benefits of agile, invade our consciousness with a hellfire and brimstone tale of doom for anyone who doesn’t convert to the new religion.

Others seem hell-bent on kidnapping entire development teams, smuggling them across the ocean in the belly of steamer ships and unceremoniously dumping them in the land of agile, ready or not.  Scrum is but one branch of the agile movement.

Stalwarts of the old way, which has worked fine for me, thank you very much, refuse to leave their comfortable lives to step into the unknown wilds of agile.  Open-minded but responsible potential converts ask questions to gain an understanding of what life in the new world might be like.  What will life be like if I join this Scrum congregation?

How Does Scrum Really Work?

The best explanations of how scrum works that I’ve read come from Mike Cohn and Mountain Goat Software.  The training, videos, and explanations they share provide fantastic top-down introductions (as well as guidance after adopting Scrum).  His book, User Stories Applied, is the ultimate reference when gaining an understanding of the mechanics of using user stories as the central artifacts for developing software with scrum.

[larger image]

The process diagram above provides a good outside-in, top-down view of how “this newfangled process” results in shippable product, incrementally.  It is a great way to present the concept of Scrum, and incremental development in general.

When people I’ve worked with first gain this understanding, they often ask, what are the artifacts that live in these backlogs?  User stories live there.  Sometimes use cases make more sense than user stories for Scrum- it depends (read the article to see which works best in your circumstance).  The common element is an outside-in, user-centric approach to describing which problems the software is intended to solve.  This is also known as goal-driven development.

Once people understand the top-down view of the process, and have an idea of what user stories are, the next question they tend to ask is “how do stories move through the Scrum process?”

The first attempt at answering this question leans on the process diagram above:

1. The product owner takes the most important stories from the product backlog and puts them into the sprint backlog – collaborating with the team to agree on the scope of work for this sprint (based on the amount of work, capacity of the team, real-world constraints, etc).
2. The team “works the stories“, meeting every day to communicate effectively and provide progress updates – best visualized with a burndown chart.  This chart says “we started with X work to do, and every day, we track how much of X remains to be done.”
3. At the end of the sprint, the work is done, and the software (or an update to the software) is ready to deliver.
4. Sometimes, multiple sprints happen between releases – launches of the updated software, because customers (and the rest of your organization) incur a cost when changing to the latest version.  But the output of each sprint is deliverable – that’s a key concept – even if you choose not to deliver it just yet.

What Does it Mean to Work The Stories?

I’ve repeatedly had people ask, after absorbing the above explanation, “what does it mean to work the stories?”

I’ve had consistent success (in bridging the language divide) using the following diagrams (drawn on a whiteboard) to explain how stories flow through the sprint process in Scrum.

The first diagram shows that user stories have a structure – the story itself, and the acceptance criteria for the story. I also establish that the story is going to go through a life cycle within the sprint.

[larger image]

Next I remind folks that the user stories make it into the sprint backlog because they are the most important (highest priority) not-yet-implemented stories in the product backlog.

[larger image]

Developers on the team pull stories from the sprint backlog and begin working on them.  These stories are work in progress, and are owned by individuals.  Some teams maintain that priority order within the sprint backlog (e.g. implement the most important story in the sprint first, etc.), while other teams use a more coarse-grained approach, relying on the product backlog prioritization to assure that everything in this sprint is the next most important stuff, and the order that the team implements, within the sprint, is up to the team.  Some folks like to strenuously debate this decision (don’t prioritize within sprints vs. do prioritize within sprints).  Both approaches are valid, and you should choose the right one for your team.

[larger image]

As each user story owner believes that her work is complete (all unit tests pass, and the developer believes that the acceptance criteria have been met), the story is ready to be tested by QA.  This step, in particular, helps people who are new to scrum and who think of things as “code and test”, to make some sense of the inner workings of a sprint.  When working with a team that was under-staffed in the QA department, I discovered that calling out this queue of user stories waiting to be tested helped convince management to increase QA investment in the team.  When too many stories pile up here, you know you have a problem.

[larger image]

The scrum team member responsible for testing the user story has the responsibility of assuring that it meets all of the acceptance criteria.  He pulls the story from the queue of “done” stories, and tests.

[larger image]

If the story fails to meet any of the acceptance criteria, it moves back into either the sprint backlog or the being developed column, where a member of the team resumes ownership of the user story and works to resolve the issue.  Once the issue is resolved, the user story is re-queued for testing.  When the user story meets the acceptance criteria, it is moved into the done done column.

[larger image]

Conclusion

If you are new to Scrum, and wondered how the sausage is made inside a sprint, this gives you a framework for understanding what is going on, and how the team delivers.  If you already know or use Scrum, you may have learned a couple things.

• Using this framework to describe how a sprint works is effective when explaining to people who do not have any experience with agile.
• Laying things out this way visually, will give you an easy-to-see signal if your team is unbalanced between developers and testers.

I’ve been involved with agile teams and processes for just over 11 years now, and incremental development is burned into my brain.  If you are new to scrum, please let me know if this seemed like a good way for you to consume this material.  If you’re an old hat, and have other suggestions or presentations, please add them in the comments below, because future readers will benefit from the additional ideas.

“For what one idea do you want your product to stand in the mind of your customer?”  I heard Roger Cauvin ask that question at the most recent ProductCamp Austin [correction - he said it here - thanks Roger], and the quote has been jumping to the front of my mind almost daily ever since.  Maybe by writing about it I can exorcise the demon and get back to using the idea instead of being haunted by it.

The One Idea

You’ve just been given a new assignment – your company needs a new software thingamajig so that you can play in the whatchamacallit space, and you’re going to drive product management for it.  You’ve also been asked to deliver the first version in six weeks.  Of course you’ll be able to do follow-on releases, after all, you are agile.  That’s how “agile” works, isn’t it?

Cool.  Exciting.  Challenging.

You sit down with the folks who will be building the product, and find out that they have already spoken with several stakeholders.  Excellent. You circle back with the stakeholders, and start to gather data about your market and audience.

Your schedule is aggressive, so you think about what is realistic to get done in a very small timebox.  With the current schedule, you can’t afford to get caught in analysis paralysis, and you can’t realistically do in depth market analysis, persona development, hyper-accurate requirements prioritization, etc.  You do, however, have time to do the most important thing – define the one idea that will define your product.

If you cannot come up with this idea, you need to push back on your management team, and delay the launch of your product until you have that one idea.

Don’t Abuse Agile

Agile is designed to help you rapidly create iteratively better products, with iterative development and continuous infusion of market feedback and data.  Agile is not a process by which you start typing without any idea of what you intend, releasing it and then getting feedback in an iterative process.  If that’s how you’re approaching agile, your process is broken.

[image from Market Driven Competitive Advantage]

Unless you’re very lucky, your first iteration will be a waste of time and money.  Wouldn’t you rather be intentional than lucky? Make sure you have that one idea before you start developing.

Strategic Alignment

You need to come up with a one idea that is aligned with and supports your corporate strategy.  At a minimum, you have to make sure that you have an idea that is aligned with your stakeholder’s goals, based on the assumption that those goals are aligned with corporate strategy.

Wow

Your one idea really needs to make your users say “Wow!”

I was explaining the importance of this to a colleague (who is not a product manager), and his response was “Oh, you mean the hook.”

I was reminded that you not only have to provide a wow experience for your users, but you have to present a hook that will capture the imagination of your buyers.  Remember that buyer personas make decisions based on their perceptions of user problems [more on convincing buyers].

Satisfice

Remember that you don’t want to try and do everything perfectly in the first release – you want to satisfice.  You may only be able to target a single persona with a solution to a single problem.  You just need to make sure you are solving the right problem – which is where Kano analysis is very handy for identifying the Minimum Market Acceptance criteria.

[From Minimum Market Acceptance]

Conclusion: A Balancing Act

Defining the one idea for your product is a balancing act.

• You have to align the one idea with your corporate strategy and stakeholder goals
• You have to solve a valuable problem for your users, presented in a way that captivates your buyers
• You have to create a product that is compelling right away – good enough in execution to enter your market
• And you have to get the first release out in six weeks!

Good luck!  Or better yet – Good Intent!

Engagement – that’s what this whole product management blogging thing is about.  Check out what Tyner Blain readers found to be the most engaging articles in 2009.

Deep Dives

If you’re new to Tyner Blain, you may be surprised by the length of the articles here.  I joke that they are long because I don’t have time to edit.  Stewart Rogers jokes that they are long because I’m incapable of writing a short article.  If you’ve been here a while, you know what you’re in for.  If you’ve been here a long while, then you’re glad (like me) that I don’t write one per day any more.

Product Management is simultaneously a broad and deep discipline, requiring us to have a breadth of perspective combined with a depth of insight.  We then have to apply that in a market context, effectively navigating the political waters of our organizations.  Most of the articles here either try to skim the breadth of a range of related topics, or plumb the depths of a single topic.  Doing that in under a thousand words is pretty hard.  Most of the articles here also link to other articles, to try and provide even more depth and context, and encourage additional critical thinking.

One measure of the quality of the articles here is how often they stimulate readers to read further, or dive deeper into the topics.  While web analytics won’t allow us to measure how thought-provoking an article is, we can look to see how many people dive into the linked articles, versus how many people move on to something else.  We can measure the bounce rate of an article to see how often people leave a page without following any of the “tell me more” links.

Looking at ~170,000 page views at Tyner Blain in 2009, narrowed down to only those articles with at least 100 page views, here is the top-ten list of most engaging (or “least abandoned” if you’re a “cup is half empty” person) articles:

1. Use Case Series: Introduction: A collection of articles on the “traditional” forms of use cases – informal, formal, UML.
2. Agile Development of Use Cases: A dive into the dynamics and cadence of an agile process for developing use cases.
3. How Do You Manage Market Data?: A collection of articles exploring different market-immersion techniques in depth.
4. Scheduling Requirements Changes – Part 2: A focus on practical techniques for managing change with an agile development process.
5. Yesterday’s BPMN Post Was A Big Fat Lie: A mea culpa and clarification of interest to folks following the BPMN Series.
6. Everything I Needed To Know I Forgot in Kindergarten: Why asking why? is important.
7. Plan Your Next Sprint by ROI – Part 1: Prioritizing by Bang for the Buck, not just Bang.
8. Ten Common Mistakes of Going Agile: A collection of articles about common pitfalls encountered when adopting agile practices.
9. Perpetually Almost Finished Projects: Organizing a project with discrete deliverables and rolling-wave planning to avoid the “90% done, 90% remaining” problem.
10. How To Use Timeboxes for Scheduling Software Delivery: One of my personal favorites.  A rational approach to making trade-offs when your “perfect” plan has to change.

OK Stewart, that’s only 519 words.

Design-Free requirements are important for two reasons, and hard for two other reasons.

Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.”  Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.

Design-Free Requirements – Revisiting

It has been three years since I wrote Writing Design-Free Requirements as part of The Big Ten Rules of Writing Requirements.  In that time, agile development practices have moved from being an esoteric development methodology to being the topic on the tips of everyone’s tongues as executives and organizations try to either (1) get the benefits of the state of the art in software-development process or (2) do something shiny and fashionable.

The previous article centered on elements of designs within MRD, PRD, and SRS artifacts.  A regular alphabet soup of artifacts.  Honoring the values behind the agile manifesto encourages us to emphasize working software over comprehensive documentation.  In that light, we’ll take a “what is needed” approach to talking about how requirements, design, and implementation are all needed – rather than issue an edict about where that information should be captured.

Agile Development Inputs

When creating software, someone needs to know:

• What problems are being solved, and how important (valuable) they are to be solved.
• Who has the problems and who is using the software to (help) solve those problems.
• What constraints limit the space that defines the universe of possible viable solutions.
• What acceptance criteria define if the delivered solution will be acceptable.

Subject to those inputs, someone needs to make design decisions:

• User experience design - what interactions will a user of our solution love?
• Program design – how (in a nuts and bolts way) will our solution function?

When talking about agile and talking about design, we should take a look at how Kent Beck and Alan Cooper, as respective though leaders in each space, view this.

Cooper doesn’t talk much about creating the requirements to support the daily use scenarios – he proposes moving directly into design of the solution. This differs from the more traditional technique of writing functional requirements to support use cases. Cooper also breaks down design into two components – program design and interaction design. Program design is everything you don’t see. Interaction design is everything you do see.

[...]

Cooper argues that designing the interaction should happen before any code is written. He uses a construction analogy to drive home his perspective – you can’t pour the concrete before you build the forms. Kent Beck, founder of the XP programming philosophy disagrees with the premise. Beck believes that the cost of changing software is low, and the imagery Cooper uses is hyperbole. We touch on, and link to that debate in this post.

Interaction Design Process Overview

I don’t believe that Beck is arguing for “don’t do design” – I believe he is arguing for “don’t do big upfront design that would delay implementation.”  He’s championing the agile values that emphasize creating working software and responding to change.  I can imagine him saying “no one will buy a design, they want a solution.”  Cooper’s point is that create a solution without first understanding how someone will use it, you can’t create a great product.

Program design has many hidden impacts – cost of maintenance, cost to change, and the performance of the solution.  You can have a design (or architecture) that makes everything easier to do in the future – at the cost of delaying the delivery of anything.  Or you can have a design that minimizes the time to deliver the first thing, while increasing the cost to deliver any particular next thing.  Or you can design a solution that falls somewhere between those extremes.

If you say “we don’t do design” you’re lying.  Every solution includes design.  Your team’s design process may be “big and upfront” or it could be a couple sketches on a whiteboard, or some email exchanges.  You may create storyboards and wireframes.  Or design may be the thing that happens right before the programmer’s fingers strike the keys.  Design may be explicit or it may be implicit – but it never “doesn’t happen.”

In the movie Amadeus, Salieri is astounded that there are no rough drafts of Mozart’s compositions.  That’s because Mozart did the design in his head, not because he didn’t do design.  I’ve worked with programmers who’s “implicit designs” were great, but that is the exception, not the rule.

Who Owns Design?

Since design happens sometime before fingers strike the keyboard, the real question is – “who owns the design?”

• You have a product manager developing an understanding of market problems, and prioritizing the problems that should be solved with your product.
• You may have a product owner managing the backlog and clarifying those requirements (problems) for the development team.
• You may have an interface (or interaction) designer or team of designers who are broadly responsible for “how users interact with our products.”
• You may have an architect or lead engineer who is responsible for the “big picture design” of how your product works.
• You have developers and testers who are responsible for delivering your product. [Note: coding without testing is like typing code without compiling - maybe it works, but probably not.]

You may not have distinct individuals with each of these titles – every small team I’ve worked with has people wearing multiple hats.  This is especially true when you have an agile team full of specializing generalists – any given story (or task) may have a different architect and different implementer.  I’ve only worked with one company where the architects are NOT part of the development team.  If your team is set up that way, please comment below – I had never seen that before, and I’m not convinced that it is the best way to organize – what have your experiences been?

Generally, “program design” is clearly owned by the development team – and product managers (and product owners) know better than to specify program design in their requirements.  Neither the lead engineer nor the product manager believes that the product manager is a better programmer – so the product manager better not be specifying program design and mislabeling it as requirements.  Coincidentally, Steve Johnson, at Pragmatic Marketing has a post running right now with a bit of a quiz – is this a req(uirment) or a spec (design)?

Where the line is more blurred is around interface and/or interaction design.  Some development teams have interface designers as part of the team.  Some companies organize with interface design as a “shared service” within the company.  Either approach can be the “right one” – it depends on too many details to make a sweeping generalization.  When the designers are members of the development team, the solution (from a product management perspective) is the same – the “team” is responsible for all design.  When the designers are not part of the development team, the developers have to consume two sets of guidance – “solve this problem” from product management, and “the solution needs to look like / act like this” from the designers.

Collaboration between product management and user experience people is the ideal solution.  The “requirements” and “design” inputs to the development team are comprehensive and consistent.

Design-Free Requirements

There are benefits – especially when being agile and minimizing documentation – to delivering requirements and design at the same time.  Just don’t do it by embedding design constraints within the requirements.

• When people on your team misinterpret design as requirements, they are unnecessarily constrained.
• As a product manager – are you the best designer on your team?  If you’re busy designing, who’s product managing?

This is trickiest when writing use cases – sequencing a set of interactions is interaction design.  That is one benefit of writing a user story instead of a use case.  An approach that has worked well for me with multiple teams is to deliver user stories (requirements) combined with storyboards (interaction design) and wireframes (interface design).  When details are needed (usually when “changing” versus “creating” an interface), screenshots can replace wireframes.  When business processes are complicated, process flows can replace storyboards.

Just don’t embed the designs within the requirements.

Your company is building out a toolkit to support third-party developers.  You’ll need a bunch of different types of widgets – combo-boxes, text entry fields, domain-specific controls, etc.  You’ve got a long list of desired controls from your customers.  You’re agile.  What do you build first?

Agile In A Soundbite

Being agile is about delivering incremental value, quickly, getting feedback, and then delivering more incremental value.  Repeat until “done.”  Good agile adds a qualifier – do the most valuable thing quickly, get feedback, do the most valuable thing (that has not already been done) quickly. Better agile optimizes the rate at which you deliver value by taking into account both benefit and cost.  Great agile overlays a focus on getting better at doing all of these things while you do them – becoming a learning organization.

Boiling the Ocean

A product manager I was coaching was faced with a challenge commonly referred to as boiling the ocean. His team was tasked with solving a market problem, and they were constrained to doing it with a service-oriented architecture that exposed a set of widgets (user interface controls) that customers could easily integrate into their products.  This approach was designed to provide competitive differentiation by reducing the time and cost to deploy solutions that allowed customers to integrate his product into their existing platforms.

In initial conversations with customers, technologists, and architects, this product manager quickly amassed a list of desired widgets (controls) and scenarios (stories) in which they could be used.  The product manager’s team had recently switched to an agile development methodology.  The internal stakeholders, not yet accustomed to agile development, wanted “all of the widgets,” now.

This product manager was able to convince them that the team would deliver the widgets incrementally, following agile principles.

His question was – How do I sequence the widgets in the backlog?

Defining Widget Priority

The product manager had a list of widgets, combo-boxes, data-grids, text fields, radio buttons, etc., and for each widget, he had a real-world scenario showing how the widget could be used.  Most of the scenarios involved customers using multiple widgets.  He wondered if he should do some sort of analysis that detailed the frequency of use of each widget.  ”This widget is used in 7 scenarios, so it should be done first; this widget is used in 5 scenarios…”

There was a strong temptation to add several “Create a widget” tasks to his backlog.  It would be easy for his development team to estimate the effort required to deliver each widget.  His team wanted to deliver incrementally, and “one widget at a time” felt like logical, discrete chunks of work to them.  They could easily sink their teeth into estimating, building, and testing each widget.

A quick reminder of a main tenet of agile, delivering incremental value, illuminated the flaw in this approach.  This approach would have been an inside-out prioritization, when value delivery requires an outside-in perspective. (See the ‘recommended reading’ suggestions on this page to check out Kessler and Sweitzer’s great book.)

If the team used this approach, after the first widget was complete, they would be able to deliver exactly 1 task, and 0 stories.  Development teams don’t deliver tasks, however.  The team’s customers would not be able to get incremental value from having a single widget.  The team would have delivered seven incomplete stories – so they would have delivered no stories at all!

We reworked his approach as follows:

1. Assess a value for each story, making sure that each story would enable his customers to accomplish something valuable.
2. Engage their user interface / user experience designer to design a solution for the most valuable story.  This design was constrained to use widgets in the user interface.  The suggested way to communicate this design was with a storyboard and low-fidelity wireframes.
3. Identify the widgets needed to be built to deliver that story, using the designer’s design.
4. Deliver the story to the development team, including the storyboard, wireframes, and list of widgets to be used as acceptance criteria.
5. Get the development team to size (estimate) the effort to complete each story.
6. Where stories were too big (epics), collaborate to identify good ways to break up the stories into manageable chunks.
7. Repeat steps 2 through 6 until the amount of identified effort was likely to fill the release (keep the dev team busy delivering value).
8. As the team delivers each story, get feedback from the market, revisit the prioritization, and revise the “next” story.

What we discovered was that a scenario like the following (modified for this article) played out:

• The first story required two widgets.  As no widgets existed, both had to be built.
• The second story required three widgets, but two of them had been built to support the first story – only one incremental widget had to be created.
• The third story used one of the widgets from the first story, but required additional behaviors.  The original widget was modified to provide incremental capabilities (and value).

A Note On Team Structure

Astute readers will notice that there was a design step “inside the requirements process” – before the stories were delivered to the development team.  Technically, that is true, for the way this particular company was organized.  The user experience designer was not a member of the scrum team, but rather, an external consultant who supported multiple teams.  The product manager engaged the designer prior to engaging the development teams.

This just as easily could have happened as follows:

1. Product manager identifies, values, and prioritizes stories to be added to the backlog.
2. Development team, as part of sizing the stories, engages their user experience designer to select the appropriate widgets, and those design decisions inform the estimation process.
3. Everything else is the same.

This procedural variation does not have design “inside the requirements process.”  The same people do the same things, in the same sequence in this scenario.  The only difference is that the interface / interaction designer is a member of the development team.  That would be ideal, but that was not how the company was organized.

In this particular example, having the product manager collaborate with the UX designer made the most sense.  It introduced less complexity for the product manager to accept responsibility for this activity than it would have for the development team (who was still new to using an agile delivery cadence) to do it.

Conclusion

The key ideas at play here:

• Focus on realizable value to the customer (outside-in development), not tractable tasks (inside-out development).
• Collaboration with a UX professional is key to driving “interface requirements.”
• Deliver frequently and valuably, get feedback (learn), and incorporate that knowledge into whatever is next.

Concise requirements give your team a useful, easy to read and easy to change understanding of what must be done.  Great requirements exist to do three things:

1. Identify the problems that need to be solved.
2. Explain why those problems are worth solving.
3. Define when those problems are solved.

Concise Requirements – Revisiting

In the three years since we last looked at Writing Concise Requirements from the Big Ten Rules of Writing Requirements, the iPod evolved to give us a better experience.  Let’s see if we can do the same with the topic of brevity in requirements.  The size of our community here has grown ten-fold, and the people who were here back then have grown just as much.  It makes sense to look at this again.

Writing concise requirements is not just minimizing the number of words you use.  Writing concise requirements is presenting the most important information in the easiest format for your audience to consume.

Concise Requirements Identify the Problems That Need to be Solved

Ultimately, requirements are the problems that we choose to solve.  A concise requirements artifact (formal document, index card, photo of a whiteboard, whatever) is one that has the highest signal-to-noise ratio possible.  You’re maximizing the amount of communication, and minimizing the cost of communicating.

You want your requirements document to read like the lines, not the points.  If the line (the signal) is what you really want, and you communicate a big pile of points (the signal, hidden in the noise), you run the very real risk that your audience will misinterpret the signal.

User stories provide the best example of clarity that comes from conciseness.  The format you should use, based on Mike Cohn’s great book, User Stories Applied, is

As a [role], I want to [do something] [with some frequency] so that I can/will [achieve some goal]

The user story is not always the right communication format – it depends on what problems you’re solving, and who is on your team.  Sometimes, use cases work better than user stories.  Conciseness is important for use cases too.  Start with a good use case name.

Concise Requirements Explain Why Those Problems Are Worth Solving

Last week’s article on Valuable Requirements focused on why particular problems should be solved.  Your focus should be on value, and that article discussed five ways to assure that your requirements are valuable.  One of the techniques, the use of an Ishikawa diagram, provides a method for identifying the root causes of problems.

[larger image]

Imagine that you have a collection of user stories, representing problems to be solved for your users.  You need a way to demonstrate why this user story should be implemented and why that one shouldn’t.  You can often use the Ishikawa diagram in the same way.  A particular goal is achieved when a user is able to do something.  Perhaps several somethings are required.  The point is that you can use the Ishikawa to drive home the point – if this set of user stories are all implemented, then this goal will be achieved.

There are two reasons this is important – first, you’re providing context for your team.  They understand why they are doing something.  Second, you can make changes easily, because you can see the impact of those changes.  By understanding the cause-and-effect relationships between problems and their values (user stories and their goals), you can see the impact of changing one or the other.

Concise Requirements Define When Those Problems Are Solved

Clarity is the goal of conciseness.  It isn’t enough to say “work on this.”  It’s important to know why you’re working on it, but that still isn’t enough.  You have to know when you’re done.  When you’re defining problems to be solved (and therefore solutions), you must also define the measures by which the solution will be judged.

A measurement of success for “Cost of Operation is Too High” might be “reduce costs of operation by 10%.”  This gives you a testable criteria for knowing when that problem has been sufficiently solved.  Sticking with the Ishikawa, you can also map out the strategy for achieving that lofty goal.  You can say that the goal is to reduce fuel expenses by 20%, reduce cost of maintenance by 5%, and reduce payments by 15%.  This process continues – a 20% reduction in fuel spend requires that you operate with your tires within 5% of nominal pressure, and that you reduce the aerodynamic drag coefficient by 7% (or whatever).

This gives you clarity in your objectives.

User stories, when combined with user acceptance criteria, provide that last connection of testability that lets your team know when they are done.

There aren’t many things more frustrating to a development team than having them solve the wrong problems.  One of those things might be having their solution be rejected because it isn’t enough.  Writing acceptance criteria clearly and concisely lets the team know exactly when they can move on to the next problem.

Providing a crisp understanding of acceptance criteria also facilitates iterative development.  One challenge teams always face is making improvements that fit within the timebox of a given iteration.  Imagine a user story with 4 acceptance criteria, where the story is too big to complete in one sprint.  When talking with your development team, you may find that the story is too big because satisfying all of the acceptance criteria is too big.  This is where many teams miss an opportunity – by defining all of the acceptance criteria that are believed to be needed eventually and requiring that they all be implemented now.  One of those criteria is going to be more important than the others.  Implement the story such that is satisfies the most important criteria (timeboxing) now, and rewrite or enhance it to meet the additional criteria later.

Conclusion

Software Product Success depends not only on identifying the “right stuff” to build, but on making sure the team builds it and builds it right.

Concise requirements improve your ability to communicate with your team, thereby improving their ability to build the right stuff right.

The maturity model approach to describing organizations and processes comes and goes out of fashion.  It is a repeating framework de jour.  In the game of agile jargon whack-a-mole, the agile maturity model is poking its head up again.

Agile Maturity Model

Ellen Gottesdeiner, author of Requirements by Collaboration, tweeted (@ellengott) a few hours ago with a link to an article proposing a set of maturity models.  She graciously passed on the opportunity to comment about the “agile maturity model” when pointing out her like of the collaboration maturity model.  The article proposed the following as an agile maturity model:

Agile Maturity Model (AMM)

0 – Dormant

1 – Speed: Focusing on being expeditious.

2 – Reactive: Focusing on acting relative to change from the perspective of the moment rather than a longer timeframe.

3 – Responsive: Focusing on acting relative to change from the perspective of the moment balanced with a longer timeframe.

I didn’t find it to be a particularly useful model.  Although descriptive, it won’t help your organization improve.

What Does Maturity Mean?

I wrote a series of articles a couple years ago that explored the CMMI and RMM – the capability maturity model and the requirements maturity model.  These are two different models that use maturity as a concept for articulating different levels, or grades (or enlightenment, or rigor), with respect to organizational behaviors.  At the time, there was both momentum and confusion around the notion of a requirements maturity model.  CMMI is a description of an organization’s rigor in “saying what it does, and doing what it says.”  RMM is an assessment of the level of critical thinking incorporated into the ways an organization is using requirements to develop products.

The problem is that people were incorrectly assuming that an organization “at level 4 CMMI” would approach requirements management at a comparably enlightened level.  The problem is that they are putting entirely unrelated concepts into similarly named classifications.  An organization could be at CMMI 1 and RMM 4 or RMM 2 and CMMI 3.  That series of articles explored what it would mean to be in any of the combinations of “maturity” for those two models.  Check out all the articles in the series if you want to put it all in perspective:

• Foundation Series: CMMI Levels Explained
• What CMMI Level Should We Use?
• CMMI Levels and RMM Introduction
• CMMI Levels and RMM Level 1 – Written Requirements
• CMMI Levels and RMM Level 2 – Organized Requirements
• CMMI Levels and RMM Level 3 – Structured Requirements
• CMMI Levels and RMM Level 4 – Traced Requirements
• CMMI Levels and RMM Level 5 – Integrated Requirements
• Don’t forget to take our One Minute Survey on CMMI and RMM.

Making a Maturity Model Useful

Why bother with a maturity model?  Not so you can “keep score” relative to others – rather, so that you can improve your own organization.  For a maturity model to be useful, you have to be able to do two things.

1. You must be able to determine where your organization is in the model.
2. You must be able to identify actions you can take to “improve” your organization relative to the model.

If you can’t measure maturity, and the model does not provide guidance about how to improve, it’s useless.  One challenge with maturity models is that they risk becoming contextually narrow in their application.  The more concrete a measurement or suggestion becomes, the less extensible it is likely to be.  Ideally, your model would be broadly applicable to many organizations.

With an agile manifesto that emphasizes people over process, it is ironic to consider applying a metric that measures your agile process.  So – goal #1 is immediately undermined.  Goal #2 – improving your organization, is, however, very valuable.

Improving An Agile Process

I’ve worked in several agile environments, both as a practicioner and as someone helping to transform organizations to become agile (or better at agile).  I’ve worked in enterprise software, helping large teams adopt agile processes; with a SaaS consumer product team, and in large IT departments with collections of teams adopting agile processes at varying paces.  I’ve played on both sides of the fence (delivery/QA & product management/ownership).

Going from zero to sixty on agile is a big task.  You can’t solve all of the organizational, practical, and interpersonal challenges at the same time.  Or at least you would be more effective tackling and resolving each issue in sequence.  In fact, you should solve the most important / largest problem first – then move on to the next, and so on.  You can call it agile agile adoption, or you can call it eating the elephant.

One powerful use of a maturity model is highlighting the next-biggest hurdle you have to overcome.  Unfortunately, most communication about maturity models is “look which hurdle we just overcame” – but the focus should be on “what’s next?”

When helping organizations be effective with agile processes, there are some clear “you have to overcome this first” challenges, that if unresolved, make other challenges irrelevant.

If you’re a software developer, I’m sure you’ve experienced the following scenario:

• A bug is reported.
• You fix the bug, and write some tests to prevent it from reoccuring.
• While testing, you discover another bug that was hidden by the first bug.

Fixing that second bug doesn’t do any good until you’ve fixed the first one.

If you’re a product manager or business analyst, think about it in terms of capability enhancements.  Is a faster search important if the current search algorithm is not returning the right results?  Get good results first, then make it faster.

You have to solve the biggest/closest/roadblockiest issue first.  Then move on to the next issue.  That’s how you should use a maturity model – as guidance about “what’s next?”

When assessing / improving your organization’s ability to be agile, you need to be addressing whatever is next.

What’s Next?

Let’s discard the “maturity model” notion and focus on “what’s next?” instead.  And that of course starts with “what’s first?”  Here’s how I’ve presented an agile hierarchy of needs to in the past:

1. Staffing the engineering team correctly.  People over process is the right emphasis.  If you can’t find people that are “good enough” you might as well go home.  Doesn’t matter how agile you are if you don’t have the horsepower.  You also need people who are excited to “do agile” – they like to communicate, they enjoy the project and team dynamics of an agile process.  You’re also better off with specializing generalists – ideally, every member of the team can do any work that is needed.  This is an efficiency play – you risk introducing bottlenecks when you have a specialist who is the “only one” who can do particular types of work – because you will not have a consistent mix of types of work from release to release.
2. Assuring Quality is in your team’s DNA.  Arguably, this is part of what’s first, but there are a lot of teams that get cood at cranking out code, before they get good at cranking out good code.  Continuous integration is the approach you must have.  Test-driven development, spec-driven development, and other testing-integration approaches are extremely important, but are really reflective of different flavors of agile and quality, not different degrees.
3. Reducing overhead in the release process.  There’s a cost associated with releasing a product.  Once you get good at releasing, and are releasing good product, your next focus is on finding the right release cadence.  There are three factors that essentially dictate your release frequency.  The size of atomic deliverables (user stories and use cases, non-functional requirements, etc) your team is creating, the overhead (time and cost) of releasing, and your customer’s capacity to consume the releases.  My anecdotal experience is that teams are usually constrained initially by the cost of releasing – dedicated hours to creating a build, code freezes, etc.  Automating the build process (to reduce both costs and errors introduced while building) is first.  Integrating automated build and automated test processes together is next.
4. Feeding the beast.  Once you have an engineering / delivery team that is operating efficiently, you run into the problem of making sure they have enough important work to do.  There’s pressure on product owners and  product managers to schedule something because it is easy to define, not because it is important.  It is also important that the team understand the context and importance of what they are doing.  So you have to focus on making sure your product management team has enough capacity to keep the engineering team busy on delivering really valuable stuff.  The “right” solution to this depends on how the problem manifests in your organization. Is your product manager spread too thin across multiple products?  Too junior?  Too bogged down in sales support or trade show attendance or or or?
5. Managing stakeholder expectations.  A big challenge in changing an organization to become agile is in resetting and managing the expectations of stakeholders.  Execs are used to having an annual budget exercise where they dedicate X dollars in the pursuit of Y objectives.  We’ll set aside the reality that they’ll only achieve 1/3 of the objectives, at 2X the cost, much later than originally forecasted.  We aren’t looking at the failings of waterfall, we’re looking at the risks of agile.  There’s a ton of stuff here, from doing damage control to reverse perceptions that “people who want to do agile just don’t want to be accountable” or addressing the “we can’t tell you what X dollars gets you” message.  Again – the particular solution is a function of how the problem manifests in your organization.  Once your team is delivering valuable stuff efficiently, you have to make sure your management team is happy and engaged and knows what to expect.
6. Continuously learning from your markets.  This is really what differentiates an agile organization from an organization with an agile development team.  Agile processes do enable you to develop code more efficiently.  If you aren’t taking advantage of the faster development, feedback loops, and ability to change that agile enables, you’re leaving money on the table.  And one of your competitors will pick it up.  There’s a whole community of MBAs that talk about business agility without once thinking about software development.  They’re talking about an organization’s capacity for rapid response to changing market conditions.  It’s what separates the winners from everybody else.  And agile development makes business agility possible.  As long as your team is able to identify and value industry trends, competitive threats, and market opportunities.  When you’re good at this, you have an agile organization.  And you win.

Conclusion

Any agile “maturity model”, irony aside, needs to be structured to help organizations progress through the stages of enlightened operations – continuously providing insights into “what’s next?” for those teams to grow.

I know there are many readers here with years of agile experience – how would you improve the list above, to better provide a framework for “what’s next?”  When that framework is solid, we can do some wordsmithing and repackage it as a maturity model.  Until then, just focus on “what’s next” – that’s all a maturity model should be used for anyway.

Jump forward in time to the day of your next big product launch (first release, new features, new market segment, etc).  And your site/application crashes due to the “unexpected” demand.  All you can do now is look for a bucket of water to put out the fire.  What could you have done to prevent this disaster?  Jump back to today and start doing it!

Backwards Planning

Depending on how you look at things, this is a backwards planning exercise, or a variation of the  remember the future innovation game, or risk management, or proactive product management.  You can avoid a disaster by imagining what might happen, then hypothetically figuring out why it (would have) happened.  That leads to planning how you could prevent it.  And now you’ve left the dream world of a Gedanken experiment and returned to the real world of product management.

Problem Triage

The way to approach this is straightforward.  Imagine some failure scenarios and the importance of preventing them:

1. Imagine a failure scenario.
2. “Predict” the likelihood of the failure.
3. “Estimate the impact of the failure.
4. Repeat for each scenario

You can prioritize your failure scenarios by multiplying the likelihood of each with the impact of each, and sorting them from largest to smallest.  Then determine which ones you’re willing to address, and which ones you’re willing to risk.  You may not be able to predict the likelihood of some failures (at least until you do a root cause analysis).  Take each of these and put them directly above the scenario with the next highest impact.  The rationalle is that these are so bad, that you really want to find out how likely they are to happen.  Once you predict likelihood (see below) you can reprioritize.

Root Cause Analysis

For the failure scenarios you choose to address, the next step is to do a root cause analysis that identifies why it might have happened.  The best tool for capturing this analysis is an Ishikawa diagram.  Consider that one problem you might face is your website crashing.

[click for larger version]

Essentially, you can crash your site by having too many users, too many concurrent users, or too many concurrent sign-ups.  Developing a cause-and-effect diagram (another name for an Ishikawa diagram) is usually an iterative and exploratory process.  You probably won’t create the simple version above first.  You may ask your implementation team “What can cause the website to crash?”  For each of their answers, you identify when that situation can happen.  Or you start top down.  Most likely, a mix of the two.  Your completed root cause analysis may look like the following:

[click for larger version]

At this point, your team can probably predict many (maybe all) of the root causes of a website crash.  The predictions may be conditional – “we can handle 10 concurrent users, but 20 probably kill us, and 100 definitely would.”  Developers are notoriously good at answering questions with conditional statements that reveal the nuances of their thinking.

Remember that you’re looking back from the future.  At product launch, what are you hoping for / reasonably expecting?  For this example, assume it is 10,000 total users, with 100 concurrent users (normally) and 500 concurrent signups.  You determine these numbers by working with your PR, marketing, or mar-com people (or wearing those hats, when it is all you).  Your plan is to do a big launch with a demo and a promo code for signup.  You know your audience will have internet connections, and will have twitter running at the time of your presentation.  You expect/dream of an immediate burst of signups, followed by tweets and word of mouth, and eventually blog articles causing additional growth over the next couple of weeks.

Use this data to feed back into the developer’s conditional responses.  If you’re like me, you will have found “absolute certainty of failure” from something.  And you may have even identified the thresholds for each element.  For example, database loading can handle 75 concurrent users, but with the current implementation, you only have enough database connections available to support 25 concurrent users.

Jumping back to the present, you now have some very discrete, and very important things to do before your launch.  If you need to, revisit the prioritized list of failure scenarios.  By looking at the next level of detail, have you found that the order of importance (to fix) has changed?  What about the “must fix” versus “willing to risk” line?  Has it moved?

Fold the “must fix” items into your backlog, and prioritize them relative to the other capabilities on your roadmap.  As a side note – make sure you’ve built in some testing to make sure you actually prevent the problems.  This might even be a great opportunity to implement “performance regression tests” – it is not enough to prevent bugs, you have to prevent slowdowns.

Rethinking the Problem

Without going into details on how the team will solve each problem, make sure that together you keep the Ishikawa diagrams in mind, and see how any proposed solutions might “reappear” on the diagram.  For example, rewriting your database connections to use asynchronous processes and a set of pooled connections may prevent a crash, but it may really hurt performance.  You may not have time to find an elegant solution.  So stop and rethink the problem.

At this point, you’ve said

1. Given a marketing plan / launch strategy, we would crash the website.
2. We can make changes between now and the launch that will double the number of concurrent users we can support (or whatever), but that is not enough to support the launch strategy.
3. Solution: Change the launch strategy.

Maybe you can’t support a wide-open promo-code based signup.  You should modify your launch so that it can only create as much demand as your product (including pending improvements) can support.  Maybe you limit it to the first 1,000 new users (probably more code to write to enforce the limit).  Maybe you launch with per-user invitations, where you can control the speed of propagation of invites (start with 100, when those have been sent, make another 100 available, etc).

Entire Team Problem

This is a problem that is solved collaboratively, by the entire team.  It is not just a “go write the code” problem.  What your product can support at a launch should drive how you choose to launch, just as how you choose to launch should drive what you want your product to support.  

You may have to delay a key capability in order to scale.  Does your marketing team know this?  Slightly less bad than crashing would be announcing a feature that is disabled.  Still need to announce the feature?  Pre-announce it: “Coming in a month…”

This stuff is important for every company and product, but it is especially critical for start-ups.  As a start-up, you have limited opportunities to grow, and a limited safety-net to catch you when you fail to capitalize on those opportunities.  So make sure everyone (not just the development team) is aligned to make the best use of each opportunity.

Conclusion

You have an opportunity to prevent problems.  All you have to do is imagine that they have happened in the future, figure out why they would have happened, then do what it takes (in software, or organizationally) to prevent them.

Just because your requirement is not a user story does not mean you have to throw it out when planning your next sprint.  See one way (that is working) for managing non-functional requirements with an agile team.

Product Backlog Stories

Every article* I can remember reading that explains how to manage a product backlog talks about user stories.  Those articles are necessary, but not sufficient .  You’ll create better products by developing them from the outside-in, with a user-centric point of view.

*One loophole – scheduling refactoring (or the payback of technical debt).  A lot of articles talk about the need to do this, and refactoring is pretty much the opposite of a user story, since by definition, refactoring improves the software without introducing new capabilities.  The best idea I’ve come across for incorporating refactoring as part of a sprint is to write a user story, with the system as the user, and the lead architect / developer as the primary stakeholder.  This actually works really well, but it works by treating the work as a user story.

Atomicity

What is really important, when scheduling sprints (or releases, if you are not doing scrum) is that you are scheduling solutions to atomic, measureable, valuable problems.  Atomicity is the reason for breaking epics (really big stories) up into smaller stories.  It is also important that you communicate them unambiguously.  That might mean writing user stories or writing use cases instead of user stories, when things are complicated.

The problem is, not every atomic requirement can be represented with a user story.  Some things that must be, are not stories.

Non-Functional Requirements

Non-functional requirements always seem to be under-emphasized when writing requirements.  The Twitter fail whale has become famous, because twitter could not scale to meet the demands of a rapidly growing user base.  Maybe the Twitter team planned for scalability, but demand simply outstripped it.  Or maybe they failed to plan for it.  Either way, they failed to meet the non-functional requirements of supporting the growth that they did have.  (Un)Luckily, this type of problem self-corrects.  Scaling failures drive away users, reducing the need to scale, until balance is achieved.

Product managers and business analysts tend to neglect non-functional requirements.  Unfortunately, this is especially true when managing with a focus on users and their goals.  Not because goals don’t drive non-functional requirements – they do.  I believe this has happened because historically, non-functional requirements were treated as an after-thought.  In reality, they are explicitly driven by goals.  I proposed an equal rights amendment to the structured requirements domain model almost three years ago.  In short, it explicitly calls out the relationship between goals and non-functional requirements.

Agile Non-Functional Requirements

Getting non-functional requirements into your sprint planning is actually not that hard.  You only have to make two tiny adjustments to get from the waterfall world to the agile world.

The first adjusment is that you have to treat non-functional requirements incrementally.  Non-functional requirements often affect all of the other requirements – so they seem massive and unweildy.  You have to decompose them.  Consider the platform-compatibility requirements for a web application.  You may have to support IE6,7,8; Safari on Windows, Safari on OS X, and Firefox on Windows XP and Vista.  That could be incredibly daunting.  So break it down.  Your first group of users (key persona) are primarily Firefox/XP users.  So the first platform you support is that one.  The next big platform for your persona group is Safari on OS X.  Add support for that next without breaking the previous support for FF/XP.  With each release, you add a platform (or two, or none).  You are conspicuoulsy addressing the needs of your target users.  The key is that once support is added for a platform, all future development is required to “not break it.”

Each non-functional requirement is cumulative.  This is the second adjustment.  All development, once a non-functional requirement is in place, must continue to honor it.  You wouldn’t break a previously released capability (functional requirement), so don’t break a non-functional requirement.  You have to determine, in each sprint, if additional functionality is more important than additional platform support.  And add in the platforms as they become the most important “next things to do.”  In waterfall projects, I’ve seen many teams break and re-break platform support throughout the development process, with the knowledge that it only has to work “at the end.”  Include platform-specific support in your continuous integration tests.

You have a launch event coming up in six weeks.  You have an established user base.  You’re also developing a key new set of capabilities for your product that you believe will be a big hit and drive significant growth for your product.  You have a small group of people in a private beta, providing you with feedback about the new development.  If you believe the launch will cause your customer base to double very quickly (maybe over a month), how do you plan for that?  This is a serious scalability non-functional requirement.

Break the non-functional requirement up into cumulative requirements.  Assuming your plan is to add 10,000 users “at once” – have your implementation team brainstorm what that could/would mean for the system.  [Also, make sure you coordinate with your community manager and marketing folks, both to validate the anticipated growth, and to device any contingency strategies in advance.]  After talking with your development team, perhaps you learn that “at once” is a nuanced proposition.  Literally at once is very bad.  Spread out over a few days, not so bad.  OK – you can deal with this too.

Imagine you already have the following non-functional requirements in place:

• The system must be available 24/7, with no more than one hour of down time per day, and no more than one outage per day.
• The system must respond in under 2 seconds for >95% of uses [ in key user story].
• The system must respond in under 20 seconds for 100% of uses [in same key user story].

Based on what we’ve said above, these non-functional requirements must not be broken.  They essentially define the acceptance criteria for our scalability requirements.

Consider the following as the non-functional requirements that must be deployed by the time of launch (six weeks, or three releases from now):

• The system must support 10,000 additional users added in the month following SXSW.
• The system must support 500 new users signing up and initiating [troublesome user story] within the same hour.

Your dev team does not really know exactly what needs to be done – they just know that the current solution won’t scale – it barely meets the existing non-functional requirements.  They propose a couple redesigns that may get the job done.  But they point out the need to actually test that the designs work.  Schedule the following for the first release:

• The system must support 100 additional private beta users.
• The additional users will all have [troublesome user story] initiated within the same hour.

The second one is really a pragmatic solution – artificially creating a spike in demand, to test out the scalability of the new code.  From that data, we can determine what we need to do to hit 10,000 additional users, and to support 500 concurrent [troublesome user story] instances.  By managing expectations of the new users (that you’re queuing them up to test scalability), you can get the data you need.  And you have a couple more iterations to improve if needed.

As a benefit, you get to completely avoid the fail whale.  The other half of this is making sure you can constrain the rate of new-user sign-ups.  Work with your community manager and marketer to make sure you position this effectively.  You are creating scarcity, which may increase demand.  A crashed server won’t.  If your team can’t support 10,000 in time for the launch, plan on 2,500.

Conclusion

You can plan and schedule more than just user stories.  And your product will be better for it.  Give those non-functional requirements a chance.

User Stories are one of the key agile artifacts for helping implementation teams deliver the most important capabilities first.  They differ from use cases in some important ways, but share more commonalities than you might think.

User Stories Applied

Mike Cohn wrote User Stories Applied: For Agile Software Development.  It is the book for understanding how to write, estimate, and use user stories.  If you’re thinking about trying out “agile” for the first time – and you haven’t read his book, you need to.  He provides great detail and anecdotes about how to write, manage, and utilize user stories.

What are user stories?

A user story is a user-centric description of the goals that one or more people will achieve by using your product.  User stories are applicable whenever there is a person, interacting with an interface to a product, to achieve a goal.  They aren’t just for software – even though the tone of this article may imply it (since I live in a software mindset most of the time).

A user story is written in the format

• As a [person in a role] I want to [perform some activity] so that [some goal is achieved].

That’s it.  No more.  Perfectly atomic, very concise and unambiguous.  Where did this elegant idea come from?

User-centered design (UCD) is an approach to product design that can almost be considered a philosophy.  In college, I used to say that industrial designers designed things from the outside in, and engineers designed things from the inside out.  The ideal products are the ones that marry form (outside) and function (inside) in an elegant solution that blurs the lines of distinction.  The first designers of engineered products were the engineers, and the first designers of software were the programmers – they were the only ones who knew what could be accomplished.  Anyone who has used an application with a user interface designed by a database expert can remember what that was like.  Eventually, someone successfully adopted the mindset of designing a product based on what someone could use it to do instead of looking at what it could do and figuring out how to use it.  That under-emphasizes the importance of UCD, but you get the idea.

Out of UCD come different things that really drive how we create products today.  Kessler and Sweitzer focus on understanding these user goals in Outside-In Software Development.  Stakeholder goals drive (arguably, are) requirements.  But it is difficult to develop actionable implementation plans directly from goals.  You need something to bridge that gap.

A user story, in an agile process, bridges that gap.  In Wiegers’ world of structured requirements, that gap is spanned with use cases.

Conceptually, a user story crosses the same chasm as a use case.  A user story defines what people need to accomplish (e.g. faster call processing), in order to achieve the goals of the company (e.g. lower call-center costs), given a solution approach (write software versus outsource to lower-cost call center employees).

Now we find ourselves in a confusing situation – there are user stories, use case scenarios, and at least three different kinds of use cases – formal and informal use cases, and use case briefs.  How are they different, and how are they the same?

Usage Descriptors

Use cases, use case scenarios, and user stories all document descriptions of how a product will be used.  They vary, along a continuum, in terms of the amount of overhead required to create each.

• Formal use cases require the most effort.  They have a lot of pomp and circumstance going on, but they describe all the permutations of how some person does some activity (or its variations).
• Informal use cases are pretty much the same – just less formal.  The challenge is to provide the right level of detail, without the guide-rails of the formal use case to remind you.
• Use case briefs have almost no overhead, but have the same “how much is enough” challenges of informal use cases, only more so.  Think of it as a single-paragraph description of a formal use case.
• User stories have the least overhead, and provide the least context.

Use case scenarios are a slightly different breed.  Like a user story, a use case scenario describes one path through a multi-path use case.  But you can’t (or at least I’ve never seen anyone) create a use case scenario without first creating the formal use cases.  This artifact basically combines the weakness of a formal use case (high overhead) with that of a user story (limited context).  It can be very handy for developing test cases if your testing team is not well versed in writing test cases.  We’ll leave use case scenarios out of the rest of the discussion.

The cost of high overhead in documentation comes with a benefit – increased detail.

Because a user story captures a single path through a use case, while having less overhead, it also captures less detail.  This is ok, because an agile process stresses communication over comprehensive documentation.   You start to run into inefficiencies when the amount of conversation (especially when repeated) is burdensome.  The amount of conversation required is a function of the amount of domain expertise, or context, that the implementation team already has.

Should I write User Stories or Use Cases?

It depends on your audience.  The formal and informal use cases, in addition to having more overhead, also provide more context, and allow you to describe more complex usage patterns of your product.  Some uses are so complicated that you have to use a use case to describe them.  Others are so simple that anything other than a story is wasted effort.  The interpretation of complicated and simple, though, is not purely an assessment of what the users want to do – it varies with the level of domain expertise of your implementation team.

Some teams simply aren’t equipped to consume user stories or use case briefs.  You have to write your requirements for the readers, so you need to know when people are struggling to implement solutions based upon stories or briefs, and give them more structure and formality.  You have to adapt to the realities of your current situation, and the experience of your team.

You could replace the words “Reader Domain Expertise” with “Writer Trust of the Team” if you wanted, and the graph would look about the same.  This is another concept that is critical to a team working effectively – trust equates to delegation.

If you can trust your team to come up with a solution that matches the story, delegate that “next level of detail” to them.  If you can’t trust them, then don’t.  But you should.  One of the benefits of agile is that your team will quickly give you a solution, and then you can give them feedback.  If they don’t create a solution that meets your interpretation of your user’s needs, then give them feedback, and they will change it.  The agile process actually relies on this dynamic to allow less-verbose artifacts to still be effective.  Someone on the team will sketch out what the solution will look like, and get your feedback, before implementing.  The more this collaboration happens, the more effective a light-weight document will be.

Conclusion

Don’t just rely on platitudes about stories and use cases.  Think about the nature of the different artifacts.  Think about their strengths and weaknesses.  Consider how you interact with your team.  Should you trust your team?  Do you trust your team?  Determine what they need, and give it to them.

There’s really only one way to travel down a waterfall – in a barrel.  A lot of people died this way, but some survived.  Software projects have been predominantly waterfall projects since the start of software projects.  And stakeholders rode down those projects, basically in a barrel.  The people riding Niagara Falls 100 years ago didn’t know if they would survive until they got to the end.  Stakeholders in waterfall projects don’t know if they will succeed until the end.

An agile project is dependent upon tight interaction (and feedback) with stakeholders.

If you’re running an agile project, and your stakeholders are old-school barrel-riders, how do you make it work?

Expectations, Documentation, and Communication

The success of any project is dependent on setting and managing stakeholder expectations.  In Managing Stakeholder Goals, we talked about assuring that those goals are addressed by our requirements.  And in a later article, we proposed a way to balance the goals of different stakeholder groups when those goals are in opposition.  Those are good tools for making sure we are initially aligned with what we are hearing from stakeholders.

We need to also apply active listening techniques to assure that what we thought we heard is what the stakeholders thought they said.  One way to do that is to write use cases (or user stories) so that we can communicate the intent of the product back to the stakeholders.  This still primarily helps with kicking off a project, in the desired direction, with the correct goals.

There are many ways to document this initial intent of the project and stakeholder goals.  It is analogous to a stakeholder selecting a sturdy barrel and picking a good spot on the river bank to push off.  We’re well positioned to eventually succeed, assuming nothing changes.  After a harrowing fall, we find out how well we did.

A well-run waterfall project will provide status updates to the stakeholders along the way.  Imagine your stakeholder wearing one of those in-helmet headsets that NFL quarter backs use.  We publish effective status reports to let the stakeholder know what’s going on.  Like the falling barrel, however, a waterfall project has inertia.  The project, barring significant outside influence, will keep going in the direction it started.  Projects have change control boards to manage that change, but emotionally, I find that a formal change-approval process tends to inhibit change, rather than encourage it.  That barrel will keep falling.

Some project teams will try and do very heavyweight documentation to maximize the likelihood that the project will end up where it should.  The problem is, this heavyweight documentation only improves the chances that the project will end up where we used to think it should go.  It does not help us change the trajectory of the project as new insights are gained.  Just as responding to those changes provides a competitive advantage, ignoring those changes exposes a competitive weakness.  Someone will come along and exploit your weakness if you don’t respond to change.

From these dynamics, we can conclude that “big up-front requirements”, while better than “no requirements,” are actually a waste of energy and time, relative to an ongoing adaptation to change.  That adaptation to change, however, should also be documented.  It needs to be documented for two reasons – to manage expectations of stakeholders, and to keep the implementation team focused on creating the most valuable capabilities in your product.  As you get smarter about what is valuable, you need to apply that knowledge and change the path of the project.

This is where communication becomes critical with stakeholders too.  Especially the old-school barrel-riders.  They are used to being in the barrel, maybe with an occasional “looking good – you’re still falling straight down” message along the way.  They are not used to hearing “we’ve decided that gliding over the rocks is more valuable than falling – please extend your wings now” messages.  The shocked “what wings?!” response is what they immediately think.

Agile Expectations

An agile project will avoid the big up-front requirements, and gather just enough requirements for right now.  What your stakeholder might hear is “agile is magic – we don’t need detailed requirements.”  The real message is “agile is better – we don’t need details about the requirements yet.  But we will need them later.”

A given team needs the same amount of specificity in requirements to achieve the same result, regardless of project approach.  One team I worked with would not set the tab-order in a form to go from top to bottom if you didn’t specify that.  It simply didn’t occur to them.  Another team was very effective with “gather the following data in a form…” – and they would layout the form, manage tab order, add reasonable field validation, assure proper markup and support for screen readers (for visually impaired users), and implement a candidate error-message/feedback design for users.  The first team would never succeed without details, the second team would view those details as wasted effort by me to write them, and by them to read them.

I think most of the initial creators, proponents, and early adopters of agile processes are members of the second camp.  They designed agile to not require detailed documents, but to allow it when needed – because they acknowledged that some people need the details.  They were reacting to heavyweight processes that were designed to work for “any team” at the cost of slowing down the best teams.  Kent Beck told me once that when people tell him about the importance of testing, his response is “so, lack of testing burned you before?”  When people stressed the importance of gathering requirements, his response was “you’ve been burned by a disconnect with stakeholders.”

Enough is the operative word here.  You have to document enough.  You have to communicate enough.  You have to set expectations with your stakeholders that things will change.  And as those things change, you have to stay joined at the hip with your stakeholders to validate those changes.

While your team is responding to changes (based on feedback from stakeholders and the market and competition and implementation discoveries) with new plans, you have to feed that information back to the stakeholders.  It is a two-way communication.  And it needs to be a continual communication.

I joined a six month project once in the last month of the project.  Here’s a sanitized sequence of events describing what happened.

1. Initial vision for the project was defined and requirements defined and tied to goals and value.
2. The estimates came back and said “no way it will happen before the business-imposed deadline.”
3. The team said “let’s be agile” and chose a component of the vision to do first.  That component could be completed by the deadline, and stakeholder expectations were set – (a) do this visible thing first, “meet” the deadline, and then (b) regroup, re-prioritize, and then do the next thing next.
4. The team started developing the solution, and worked for 5 months.  After 5 months, someone concluded “we won’t finish by the deadline.”  A couple weeks later, the estimate was that the team still had between 1/3 and 1/2 of the work remaining to complete the first component of the vision.
5. In presumably unrelated events, all but 2 of the internal stakeholders left the company.  Literally.
6. When the CIO and president of the company engaged the project team, they weren’t thinking “we have an over-run on the first component of our vision” – they were thinking “not only is it not done, but what you’re trying to do is not the right thing.”
7. Project was stopped one week after the original deadline for the first component (which was not completed).

It may be that this was unavoidable, but one thing was clear – the “build the first thing first” expectation was not communicated effectively.  It didn’t help that the team did not track velocity, so it wasn’t until the end of the project when the “you’re going to hit the rocks” message was first heard by the stakeholder in the barrel.  Way too late to affect change.  For this and other reasons, I contend that the project was not agile.  It was a Chevrolet with a Ferrari sticker on it.

We can ignore the labeling of the process and focus on the lack of ongoing expectation management as the ultimate doom of the project.

Evolving Expectations

Patrick Masi had a couple great comments on our Simple Agile Model article.  Patrick pointed out a problem with simple documentation artifacts like this.  The early “here’s all we need right now” artifacts were insufficient to capture the full extent of what the stakeholders needed.  I’m not sure exactly where things broke down, but Patrick implied that the ongoing clarification with stakeholders was not happening.

This is a completely different manifestation, I suspect, of the exact same problem described above.  Thinking about Patrick’s comments is what got me heading down the whole “barrel rider” path in the first place.

I don’t believe I’ve worked with any stakeholders who would say “yes, ignore what we learned this year – it is more important to build last year’s product.”  I’ve definitely worked with stakeholders who did not have time to commit to the support of an agile project.  The ironic thing about agile projects is that they may do more requirements work through the course of the project than non-agile projects.  An agile project will respond to change.  That means some work is re-done.  It also means that some valueless work is avoided.  You can’t categorically say which influence is larger.

One possible source of the pain Patrick’s team felt is mis-set expectations of what is being delivered when.  Imagine developing a checkout-process for an eCommerce website.  The complete checkout process is too large for a single sprint, so you break it down into valuable atomic deliverables for each sprint:

1. Registered customers can buy any products, using previously saved billing / shipping info.
2. Individual product and “per order” discounting works and customers can use gift cards to pay for all or part of the order.
3. Anonymous customers can place orders (without accounts) and registered customers can modify billing and shipping information.
4. Orders can be placed as gifts (with gift receipts and wrapping services), and online call-center reps can interact with customers real-time to help with the process.

This is a nuanced message – basic checkout in sprint 1, with increasing capabilities in each sprint, until “complete checkout” is done in sprint 4.  That is a reasonable plan, but requires a more detailed conversation with stakeholders so that they know what is coming and when.  You don’t want someone freaking out after the 3rd sprint when they can’t place gift orders.

Another possibility is that the elicitation process before the third sprint (re-visiting checkout again with the same stakeholder) did not tease out that anonymous users must provide an email address (for order confirmation email, and to secretly create a “shadow account” for that customer).  All of those details need to be gathered, and it can be harder to spread out the conversation over multiple sprints than it is to have it all up front.  This is just incomplete discovery, but with delayed (and recurring) impacts.

In User Stories Applied, Mike Cohn stresses that the brevity of user stories is intentionally designed to facilitate (and I would add “dependent upon”) conversation.  I find it to be both a strength and a weakness of user stories.  It is strong because you can cover a lot of ground quickly (breadth) and capture a number of stories, much like the list above.  It is weak because the requirements documentation does not stand on its own – it requires conversation to fill in the details.  I’ve had some success using the “Verify that…” user acceptance tests as the method of documenting those details (depth), in conjunction with the brief, easily consumable stories.

You can write the stories quickly to decompose and schedule across sprints (revisiting the schedule as things change), and then write the verify statements as UAT for each sprint as it occurs.

Another benefit of the UAT is that it is explicit and cuts through the walls of the barrel for a stakeholder who “doesn’t get agile” as Patrick puts it.  “Here’s our lightweight multi-sprint plan – now lets define the specific acceptance criteria you need” is a pretty effective conversation.

Conclusion

You have to stay closely connected to your stakeholders – not just for messaging, managing, and changing the big-picture direction of the project, but also to drill down into the details at the last practical moment.

The second productcamp for Austin is just around the corner!  Are you going to be there?  You should.

Announcement

Paul Young has written a great announcement and explanation of what product camp is.  I really enjoyed and benefited from the one we did last spring, and I can’t wait to attend and present at this one!  If you are or can be in the Austin area on Jan 24th, make sure you head to the UT Austin College of Communications CMB building, studios 4B through 4E from 8 to 5:30.  And the networking afterwords is sure to be even better than last year too.

Presentation Topics

A key takeaway from our first productcamp was that people most enjoyed the presentations that were more collaborative.  These sessions tended to give attendees the ability to immediately put to use some really good ideas.  I’ll wager that we’ll have a mix of presentation styles again this year, but that it will skew to the interactive and practical.  The roundtables were also very well received, and I hope we’ll have more of those too.

I’m really looking forward to presenting again, and would love suggestions from you about topics you think would be valuable.  I guess this is pre-collaboration :).  At the moment, I’m leaning towards a presentation around using wireframes to rapid-prototype ideas in support of an agile development team. I’m currently doing this with the developers and stakeholders at OtherInbox, an Austin start-up that was one of this year’s TechCrunch 50, doing some awesome stuff to eliminate email overload.

So far, this is proving to be an effective way to rapidly evolve ideas and minimize the overhead of communication – and we’re doing it with a distributed team.  We’ve been using a combination of balsamiq mockups and google docs.  By the time product camp rolls around, we’ll have many sprints worth of experience under our belts, and I should be able to provide a mix of how-to’s and lessons learned.

Add a comment below if you have another idea, or if you have any feedback on this one.

A picture is worth a thousand words.  Agile values working software over comprehensive documentation, and it values customer collaboration over contract negotiation.  With that in mind, how much is a picture of a model worth?  Check out a simple example, how it helped, and what we didn’t do.

A Complex Conversation

I was working with a client on an eCommerce website, where one of the things that was important to the client was having and managing an affiliate network that refers visitors (and ultimately customers) to the website. The conversations around exactly what the stakeholders of the eCommerce site wanted were pretty convoluted, and different stakeholders described the “requirements” differently.

Affiliate Network Background

An affiliate network can work in the following way:

1. When someone visits a website, and does so by directly clicking on a link on an affiliate partner’s page, the website is able to identify the affiliate partner who “sent” the visitor to the website.
2. The website keeps track of who “sent” the visitor.
3. If the visitor becomes a customer, the affiliate partner who sent the visitor is compensated.  One way to compensate that affiliate partner is by giving them a percentage of the revenue that the customer generates for the website.

This can be a lucrative model for both the eCommerce site and the affiliate partner.  The partner gets paid for funneling traffic to the eCommerce site, but not necessarily doing any other work (beyond what it takes to encourage people to go to the eCommerce site).  The eCommerce site gets increased traffic, at a manageable cost – proportional to the revenue generated by the incremental visitors (who would probably not otherwise visit the site).

Each business gets to focus on its core competency (sending traffic, for the affiliate partner; converting that traffic into revenue, for the eCommerce site).  The eCommerce site invests the majority of the time and money (probably orders of magnitude more investment), and the affiliate partner shoulders all of the risk, but can do this for almost no cost (if they want), in exchange for an uncertain revenue stream.  This blog is currently trying out an affiliate relationship with Carbonite – because I love the product (and therefore think people who visit Tyner Blain will too), and because the revenue generated, if any, will help defray the costs of writing and maintaining the blog.

Specific Complexity of an Affiliate Model

The complexity of this “simple” model becomes apparent when you ask a few clarifying questions.

• Will there be multiple affiliate partners?  (Yes)
• If someone is referred by multiple affiliate partners (on separate occasions), who gets credit? (The last affiliate partner who sends the customer to the site)
• Does the visitor have to purchase during the visit that was made from the affiliate partner’s site? (No)
• Is there an expiration date, after which an affiliate will not get credit for customer purchases?  (Yes, “N” days).  [Note: I am obscuring the actual value for this article, but N is a real number.]
• If a customer who was referred by an affiliate makes multiple purchases, for how many of them is the affiliate partner credited?  (One)

Asking these questions in different ways generated some different, and potentially conflicting answers.  The list above is the “after we put it all together” answer.

A Simple Model

We solved this problem by grabbing the immediately available stakeholders and pulling them into an office with a whiteboard for about 3 minutes.  [Ed: Our first article about using object-oriented analysis as part of requirements gathering is from three[!] years ago, this is not a new idea, and wasn’t then, either.]  I drew the following state transition diagram on the whiteboard, using an active listening technique, to confirm that I had consolidated the inputs into the right set of business requirements.  Documenting business rules with a state transition diagram was very effective at highlighting them.

Most of the explanations from stakeholders were in more of a use-case format, but a state-transition diagram was more effective at validating the rules and requirements in this situation.

The diagram above uses the following approach to describing the problem:

• Some customers are considered to be “actively referred” by an affiliate partner – and when that is true, an affiliate receives compensation for the order placed by the customer.  Other customers are not considered to be “actively referred” and no compensation is due to the affiliate partner.
• Customers can be “temporarily actively referred” and events modify that state.

What the diagram shows, given that context is the following business rules:

• When a customer is referred to the site, the “to be compensated” affiliate partner is identified, and associated with the customer.
• When the same customer is referred to the site by a different affiliate partner, the new affiliate replaces the old one.
• If “N” days pass after a customer was referred by an affiliate partner, that affiliation expires, and the affiliate partner is not compensated for future purchases.
• An affiliate partner is only compensated for the first purchase made by the referred customer.

The stakeholders that were present confirmed that this perfectly represents their business requirements.  Even cooler – a couple days later, the business person most-directly-responsible for implementing the programs came by, looked at the whiteboard, and signed her name on it to record her approval.  We also have a camera-phone snapshot of that.

What We Didn’t Do

I could have titled this article Mini-Model and Requirements, but Agile seemed more appropriate, because we didn’t go over the top with it (and it is a rapid-development, incremental project).  The diagram above also represents the minimum deployable version of the affiliate program for a given release.

We stopped short of creating the following diagram:

This diagram is more of a “classic” artifact that you would see in a BUFR (big, up-front requirements) project.  Our team collaborates regularly, and the affiliate program details were now relevant/timely.  We had the conversations, drew the diagram, confirmed (in about 10 minutes), took a picture, and shared it with the rest of the team.  There would have been marginal incremental value in making a pretty version of the diagram, so we didn’t do it.  Our goal is working software, not comprehensive documentation.

Conclusion

Just do what you need to do, then move on.  For our team, clarifying the intent was important.  Creating a formal, pretty picture added no extra value.  So we didn’t do it.

Satisficing probably makes more sense than perfecting your product.

Can?  Open.

Worms?  Everywhere.

Are we really saying “don’t make it perfect?”  Yup.

Product Perfection

A perfect product will be successfull.  It will solve the right problems, generate as much value as possible, and be so intuitive to use that you don’t even realize you’re using it.

Perfection is a bit of a catch-22, however.  When I was still working as a mechanical engineer, I joined a team who introduced me to my new role with the following statement about the product I was going to replace:  “the design engineers are really good, they designed a great <product> – the only problem is that we can’t build it.”

My first thought – “you’re not using the same definition of great that I use.”  The same holds true for the perfect product.  Perfect at what cost?  If you spend too much making the product otherwise perfect, you won’t make enough money selling them, or your customers won’t benefit enough from using them, so you won’t sell as many, so your profits will be lower, so …, so …, and so on.

You can aim towards perfection, and still probably be ok, because you’ll never get there.  Your ideal product is a moving target, because your market is moving.  Since you’re prioritizing the most important capabilities to build at any given point in time, you’ll never reach the end state of having done “everything.”

There was a math problem that made my head hurt when I was in college.  It went something like this:  If you were 100 feet from your house, and every hour cut the distance by half (after one hour, you were 50 feet away, after another hour – 25 feet, etc), and it was going to start raining in 10 hours, would you be inside before it started?

What if it wasn’t going to rain for 10 days?  Or 10 years?

That may be why I became an engineer, and not a mathematician.  To me, at some point, you would simply take one reasonably sized step, and be in the house.  An engineer would be inside the house before it started raining – and he’d probably be fixing (or breaking) something.  A mathematician would never make it into the house.  I could never appreciate that kind of math.  But I like fixing things.

Every capability you add, or every problem you solve, gets you closer to perfection.  The problem is, it doesn’t get you “10 feet closer”, it is more like “30% closer.”  And like the mathematician, you’ll never get there.

Even the engineers won’t get there, however.  Every solution you deliver to your customers changes the definition of perfection.  Each solution enables new opportunities, and exposes new challenges.  Perfection becomes a moving target.

Product Paralysis

People talk about analysis paralysis fairly often.  Product paralysis comes when you spend so many cycles agonizing over the perfect thing to do, or the perfect thing to do next, that you don’t do anything.  Its the product management version.

I was on a call today, introducing some users to a product we’re developing.  We just stood up a website release – the first sprint that has enough content to be independently consumable by non-software folks.  One of the folks on the call, when trying to explain how agile works, and how user acceptance testing would work, made a statement that I thought failed to capture the essence of what we were doing (in a language that the audience could appreciate).  Paraphrased, the statement was – “in an agile project, there is no ‘release date’, the website will be done when it is done.”

I interrupted to share how I think about this project, and agile in general – “In this project, we’re building a release for you every two weeks.  Every two weeks, you get to decide if it is ‘enough’ to share with customers, or share with more customers.”  [Note: In that statement, "customers" are people who use the website to purchase products from our client, who is also our customer.]  This project involves replacing a legacy system, as quickly as makes sense.  The new solution introduces new capabilities (and value) relative to the existing solution.  Today, it also lacks many capabilities (and value) provided by the current solution.

The question we are working with the business to answer is “when do we switch from the old system to the new one?”  There are at least some people who insist that we cannot switch over until all of the current capabilities are live in the new solution.  If we use that metric (and we may – that has not been decided yet), there will be a period of time where the new solution is more valuable than the current one, but that value will go unrealized.  I think that is another form of product paralysis.  We won’t have perfect data, so it will be a qualitative decision.  Right now, we’re trying to establish an alternate view of “enough”, and then predicting how long that will take, to manage expectations with stakeholders.  Fun stuff.

Sprint Satisficing

Ivan Chalif just published a review of the book, Don’t Make Me Think, by Steve Krug.  In his review, Ivan points out one of the themes in Krug’s book – doing “enough.”

Many choices that a Product Manager has to make are based on having to balance between the optimal solution and what can be done in a given time frame with the available resources. We bet that if we satisfice, it will be enough to address the short-term requirement or at least buy some time to refine the feature in a later release.

That made me remember another book, The Paradox of Choice, by Barry Schwartz.  Another good book, where a central theme is that when given an arbitrarily large set of choices, people don’t choose optimally – they focus on eliminating choices, then choosing the best from a select few options.  If I remember correctly, Schwartz argues that people don’t optimize when faced with too many choices, they satisfice.

When it comes to determining what to include in a particular sprint, we’re faced with an arbitrarily large set of choices, so we prune.  And then we satisfice.

In another conversation today, one of the developers asked an insightful question about one of the stories that was committed for the sprint.  As part of answering that question, we realized that the “perfect” answer was to change the design approach for that story, resulting in extra work that would push the team beyond capacity for the sprint.  We have a theme for the sprint, and this story is a key element in that theme.  If we have to push something to a later sprint, we want to push something else.

The story was written for three classes of users – logged in users with existing accounts, people who just created their accounts, and people who didn’t have (or want) accounts.  The project involves integrating COTS (customized, off-the-shelf) software with legacy systems.  We discovered that the design changes would only be needed for people who did not have accounts.  The theme of this sprint is to enable an end-to-end path through the site (essentially, completing an epic).  We decided that we would be satisfied by completing the epic for the logged-in users in this sprint, and add the other users in the next sprint.  That met our tactical goals for completing the epic.  Our alternative would have been to delay another story (or two) to a later sprint, just to be “perfect” with our epic.  This is the better solution, in this case.

What made this possible was that we remembered that each sprint asks the question about the solution – “is it good enough?”  And by implication, each sprint asks the question about each story – “is this approach good enough?”

We decided that today landed in the “a good day” column on the ledger.

Planning by ROI.  Hmmm.  Isn’t that impractical?  In an econometric way, yes.  But you can still estimate the relative value of the capabilities / stories you’re planning for your scrum sprints.  The point is – don’t look only at value – also look at costs.  While “ROI” may be a poor choice of terms, “bang for the buck” is not.

Mea Culpa

In the previous article, Plan Your Next Spring By ROI: Part 1, I made a bad choice of sloppily using ROI (about a dozen times) to describe “bang for the buck.”

Just over a year ago, we showed how prioritizing by ROI delivers value faster.  The reason this works is that each sprint (or timebox) has a fixed capacity for work, so you want to cram as much value into that box as possible – not just do the most valuable thing first.  Here are a couple images from the previous article that show the impact of using this approach.

[...]

So far, we’ve argued that prioritization should be by ROI, and while accounting for other people, should be user focused.  Actually, nothing above is sprint-specific, the same concepts apply to any product planning and development approach.

Plan Your Next Sprint By ROI: Part 1

[Editor: Note - the author has also messed up again, this time by burying the lead at the end of the article.]

Giants.  And Their Shoulders.

I had a great conversation over the weekend with Luke Hohmann, founder and CEO of Enthiosys, and realized my mistake.  Consider the titles of three (excellent) articles Luke wrote earlier this summer:

1. Why Prioritizing Your Product Backlog for ROI Doesn’t Work (Part 1 of 3)
2. Developing Attributes for Backlog Prioritization (Part 2 of 3)
3. Prioritizing for Profit (Part 3 of 3)

Not to mention giving a presentation at Agile’08.

You’d think I would have noticed, and been more careful in my use of language.  Sorry about that.

Luke, in his first article, provides several arguments against econometric assessment of ROI, and I agree with all of his points.  In his second article, Luke goes into details about defining attributes for reflecting the goals of internal stakeholders, external stakeholders (buyers and users), and the system.  I promised to do the same in this article, but frankly, why reinvent the wheel?  Our differences from Luke’s article would at best be nuanced, so the best use of your time (and mine) is to just go read his second article.

Our experience is that successful Agile Product Managers have an almost natural, intuitive feel for prioritizing backlog items to drive profitable growth. Fortunately, this natural ability is greatly enhanced when they make the link between the backlog and their ability to drive profit explicit. As an aside, it is this set of attributes that most clearly distinguish the Scrum-centric role of a Product Owner with the full responsibilities of an Agile Product Manager.

Developing Attributes for Backlog Prioritization (Part 2 of 3)

Including Costs in Sprint Planning

There are two dimensions by which to keep costs in mind when planning a sprint.  The first is in determining how much work to schedule for any given sprint.  When you use timeboxing to plan a sprint, you’re saying “we have the capacity to do X work per sprint” and “we should only schedule X work per sprint.”  Your plans are based on estimates, so you need to have a feedback mechanism to make sure you’re doing a better job in planning each sprint than you did with the previous sprint.  Burndown graphs are a great way to do this.  The burndown provides feedback within the sprint too, not just at the end.

Mike Cohn, of Mountain Goat Software, gave a great presentation on how to estimate costs for an agile project.  Without giving it away, he proposed (starting on slide 14) using planing poker to get quick estimates of user stories [more details] at the product backlog level.  Then, more detailed estimates are created for the tasks within the sprint.  If your team uses use cases, you can choose to use use case points as a low-overhead estimation method (but not nearly as low as planning poker) to determine the initial estimates of costs.

A Planning Example

You have the following set of items being evaluated in your product backlog.  Note that there are a mixture of strategic, user-centric, and code-refactoring items under consideration.

• Profile Editing – As an insurance agent in the community, I want to be able to edit my profile to personalize my identity within the site.
• Data Abstraction Refactoring – The system’s data model is inelegant and needs to be refactored, if ongoing development is to be easier.
• Action Notification – As a manager of agents, I want to be notified whenever my agents submit quotes to potential customers.
• Grouping Items – As an insurance agent, I want to be able to group contacts, proposals, communications and other items, so that I can organize my work.
• Reporting – As a manager of agents, I want to be able to run reports to track financial metrics and activities by agent, product, geography, and time period, so that I can manage my team effectively.
• Serializable Objects – The system’s implementations for data backup and data export are redundant and brittle and should be refactored to clean up the code.
• Customer Centric UI – The user interface is currently product-centric in approach.  Our strategy to offer multi-vendor product lines will require agents to focus on customers first.

Using the value-estimation and cost estimation techniques outlined by Luke and Mike you determine the following value and cost estimates for each “story.”

If you were to ignore the cost estimates you would do the data abstraction refactoring and customer-centric UI stories first, followed by the profile editing, action-notification, and other tasks in order of descending value.  As it turns out, that is not the way to maximize value over time.  At first glance, the profile editing story looks like the biggest bang for the buck.

Create a scatter plot of value versus cost.

[larger version]

You can clearly see the differences in value and differences in cost of the different stories.  If, however, you add the element of value/cost – bang for the buck – and prioritize by it, you will schedule stories in a different order.  Value / cost is also the slope of a line from the origin of the graph to each story.  If you draw those lines, you see the following:

[larger version]

To maximize value delivery over time, work across the chart in a clock-wise direction.  Profile editing is the first task, but grouping items and data abstraction refactoring are tied for second place.  This is different because you’re prioritizing by bang-for-the-buck, not just bang.

Collaboration And Agile

When you consider the agile manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

© 2001, the above authors. this declaration may be freely copied in any form, but only in its entirety through this notice.

you see that there is an opportunity to take this even further.

Have Developers Improve ‘The Plan’

I proposed an idea to the development lead on an agile team a couple weeks ago.  A couple hours later, he pinged me to let me know he had just applied it and was very excited.  A quick whiteboard session (started with a version of the diagrams above), and he was able to immediately make his sprint better.

I told him that when I was still slinging code, and later, when working with teams of engaged and talented developers, I often ran into the problem of having a “cool capability” and wanting to get that capability into the current release.  I wasn’t pushing for the capability because it was high bang-for-the-buck, or even high-bang – I just thought it was cool.  So I would implement it.  Bad Scott, no biscuit.

What I proposed was that when a developer has a favorite feature, instead of just trying to squeeze it in, the developer should figure out how to make it cost less, until it had the highest bang for the buck.  Each initial cost estimate is a planning-poker estimate.  By spending cycles on design, a developer can figure out a cheaper way to implement it.  And that moves the story to the left on the chart.

Your challenge, visually, if you want to bump reporting up in the planning backlog, looks like the following:

[larger version]

You, as a member of the implementation team, have to come up with a design for reporting that is roughly one-third the cost that was originally estimated.  Do that, and it gets bumped up in the queue.  [And yes, I realize that very few developers get excited about reporting.]

The product manager’s job is to make sure you get all the dots in the right place vertically.

The implementation team puts the dots in the right place horizontally.

Everyone embraces the ability to change the graph.  The product manager moves the dots up and down as she learns more about the needs of the market.  The implementation team moves them to the left (and sometimes to the right) as they design better solutions.

Quoting Luke again – “Our experience is that successful Agile Product Managers have an almost natural, intuitive feel for prioritizing backlog items to drive profitable growth. Fortunately, this natural ability is greatly enhanced when they make the link between the backlog and their ability to drive profit explicit.”

This feels intuitive to me.  What about you?

You’ve got a giant backlog of user stories and product capabilities.  How do you determine which stories to implement right now?  By the estimated value of each story?  Pick the ones the developers want to build next?  How about picking the stories that maximize the ROI of the sprint?  To do that, you need to estimate both value and cost.  While remaining agile.

ROI Refresher

In our earlier Definition of ROI: Return on Investment article, we provide an explanation and example of calculating ROI.  In short, ROI is the acronym for return on investment.  How much return do you get, as a percentage of what you have to invest.  If you invest $100 to get $120, your return is $20 (the profit).  Your investment is $100.  Your ROI is 20% (20/100).  Another way to think about it is bang for the buck.

Prioritizing by ROI versus Prioritizing by Value

You can prioritize based on value – “Do the most valuable thing first.”  And that is a good, but suboptimal approach.  We even suggested it as “the best” prioritization technique in our prioritization article from almost three years ago.  Since then, by continuing to focus on software product success, I’ve learned to believe in a better way.

Just over a year ago, we showed how prioritizing by ROI delivers value faster.  The reason this works is that each sprint (or timebox) has a fixed capacity for work, so you want to cram as much value into that box as possible – not just do the most valuable thing first.  Here are a couple images from the previous article that show the impact of using this approach.

Identified stories, from highest value to lowest value (V = Value, W = Work (or cost)).

If you can schedule 30 units of work in a sprint, your first sprint will deliver 19 units of value, and your second sprint will deliver an additional 9 units of value.  The thirs sprint delivers the remaining 15 units of value.  Why more value in the third sprint than the second?  Because you didn’t sort by ROI, you sorted by value – but were constrained by cost.  When you sort by ROI, you get the same tasks, in the following order:

With this sorting, your first sprint delivers 25 units of value, your second sprint delivers 9 units, and your final sprint delivers an additional 9 units of value.  There are more details in the original value-maximization article.

This is critical to executing a market-driven strategy that will dominate your competitors.  You not only have to stay tapped in to the market needs, but you have to deliver faster than the other guys, or your distinctive insights will be wasted.

Political Prioritization

Really?  Yes.  The first risk to the success of a project is that it gets canceled.  Only the projects that don’t get killed even have a chance to be right, and therefore maximize value for your customer (or company).  That means you need to prioritize in a way that satisfies your stakeholders.  After attending last year’s IBRF, I wrote the following article as an interpretation (and slight extension) of Roger Burlton’s very good presentation about process improvement.  When you’re tasked with improving a company’s processes, the first question you have to ask is “which ones should we improve first?”

From that article:

This analysis focuses on principal stakeholders. The goal of this analysis is to encourage your principal stakeholders, or sponsors, to prioritize the most valuable processes first. Not all stakeholders are created equal, so you have to weight the relative importance of each stakeholder. You can weight them politically, by influence, or by whatever factor is most likely to get buy-in from the executives.

Stakeholder Value Matrix

The end result is a prioritized list of processes to improve, based upon which ones cause the combination of most pain (current state) and most gain (when improved) across your stakeholders, based on maximizing the utility of the group of stakeholders.

Visually, the preceding diagram shows the end results of aggregating the stakeholder inputs in terms of pain and gain.  A couple utility curves are overlaid (arrow shows increasing utility) to show what to do first.  The 1,2,5 processes are clustered together in the “highest utility” or “most value” range.  This approach would focus on those processes first.

Persona Prioritization

When developing software, you should primarily be user-focused.  [Note: this is somewhat of a religious debate, I guess we worship at the chapel of UX.]  Luckily, most of the time, stakeholder goals and user goals are not in conflict.  However, to sell your solution, you need to make sure you are addressing both buyer goals and user goals.  Sometimes they are the same, like with consumer products, and sometimes they are not, like many enterprise software products.

As a product manager, you have to know when to listen to, and when to ignore the squeeky wheels.  If you’re in a start-up doing its second product, solving a new problem for a new market segment, you’re dealing with founder’s dilemma.  That founder has a bunch of stakeholder goals for you, and the juice to make sure you address them.  If you’re trying to get analyst’s attention [good article by April Dunford at Rocket Watcher], you may feel pressured to prioritize “check the box” features that may be important only to buyers and analysts, without actually adding value for the users.

Of course, you can’t ignore analysts and buyers and internal stakeholders.  If your product gets cancelled before you get to market, you’re done.  If analysts criticize or ignore your product (for some markets), you lose a lot of sales.  And if buyers don’t “think they want it”, they won’t buy.  You never get a chance to demonstrate value to the users.

But focusing solely on those folks means you won’t have a product that people love, and you won’t generate word-of-mouth, customer loyalty, or value for your customers.

So any solution needs to account for the needs of the users.  Organizing users into personas, and making strategic decisions about which ones are important will help.  Include the other people (buyers, etc) but use a persona-centric model for describing what you’re doing – just to make sure the users are at the center of your decisions.

Intermission

So far, we’ve argued that prioritization should be by ROI, and while accounting for other people, should be user focused.  Actually, nothing above is sprint-specific, the same concepts apply to any product planning and development approach.

In part 2, we’ll look at defining user stories and user persona.  We’ll look at the value of each story relative to cost, and show a couple low-overhead ways to easily visualize this info – both driving scheduling and motivating the team to improve.

Agile development methodologies succeed because they help development teams be as effective as possible.  Development teams do not, however, work in complete isolation.  The company they work for has a strategy.  The company manages a portfolio of products, and targets a particular product at specific market problems.  Within that context, an agile team can thrive.  What’s the best way to provide that context?

Agile Development in Context

Mike Cohn of Mountain Goat Software gave a presentation to the bayXP group in March 2007 on agile estimation and planning (video and pdf at link).  As part of setting the stage for his planning presentation, he describes the software development ecosystem as an onion.  So did I, coincidentally, in 2006.  The gist of both onions is that software development is implementation, in the context of design, driven by requirements, formed to address market opportunities.  Mike’s onion provides specific insights into the execution approach of an agile team, so let’s frame this conversation using his terms (but a new visual).

• A company has a strategy.  [Example: "Organize the world's information..."]
• A company has a portfolio of products that is intended to provide a mechanism by which the company can achieve its strategy.  [Example: Gmail, Chrome, Gears, Reader, Docs, etc.]
• Each product (or service) the company creates is an intentional part of the portfolio, targeted at specific markets or market segments, with an intention to solve specific problems.  [Example: Gears allows people to consume online content when offline.]
• A product is delivered through a series of releases. [Example: Chrome release 0.2.149.30.]
• The work that goes into a release, when practicing incremental development, may be decomposed into multiple iterations.  [Example: Chrome iteration 0.2.149.29, not released, but built and tested]
• In scrum, the completion of tasks within an iteration are managed daily.  [Example: Today, I will add the 'check for updates' to the 'About Chrome' popup.]

Many people talk about the agile process as if it encompassed the entire perspective shown above.  It doesn’t.  When you talk about the software development lifecycle from the strategy level down, you’re really talking about business strategy.  Agile development happens in the context of a business strategy, a product portfolio designed to achieve those strategic goals, and the product in that portfolio that is being developed.

Saeed Khan puts it pretty well in his first article about agile / scrum:

Keep in mind, Agile/Scrum is a DEVELOPMENT methodology. It is a great model for developers and engineers and other R&D team members to work and communicate more efficiently. There are very clear benefits to this model. It provides greater visibility into current work status, work remaining, can identify development hurdles earlier and can communicate them outward more easily.

I agree with Saeed.  In the diagram above, the layers that represent “what we do” have black text and borders (Strategy, Portfolio, and Product).  The layers that represent “how we do it” have white text and borders (Release, Iteration, Daily).  In Mike Cohn’s presentation on agile planning, he specifically calls out that agile planning happens in this (inner) scope.

Managing a product backlog (in scrum) is the place where things blur a little.  Determining what goes into the product backlog is “what we do”, prioritizing those product backlog items is “when do we do it”, and fitting them into individual releases (timeboxes and rolling-wave planning) is “how we do it.”  As agile teams stress, communication here is the key.

The true challenge that companies face is to provide agile development teams with the context needed to develop software.

Providing Context to Agile Teams

Product management is primarily a strategic activity, combining market insights () with company strategy to design a product portfolio, and to determine which problems a particular product should solve, for a particular market segment.  This leads to a focus on buyer personas and user personas.

Establishing and maintaining the connection between market insights and agile development teams will develop a distinctive competence for your company.  One key is to connect stakeholder goals with implementation activities.  This involves translation from the language of business to the language of developers.

An effective bridge across that communication divide has to be visceral and very straightforward.  Many agile team members rail against anything that looks like overhead, and the manifesto even codifies this disposition – “working software over comprehensive documentation.”

Our magic decoder ring must be simple, explicit, and light-weight.  Sounds like a job for the Ishikawa diagram.

Ishikawa Diagrams for Agile Product Management

The Ishikawa diagram, also known as a cause-and-effect diagram or as a fishbone diagram, can be used to describe and decompose market problems.  Consider the following near-real-world example:

You’re developing a product for sales reps.  The key to your product’s success is user adoption, and you believe the way to get that adoption is by helping sales reps to maximize their compensation.  Sales reps are generally managed via commission-based compensation models.  You establish “Maximize Sales Compensation” as a goal for your software (for these users, in this market segment).  You then acknowledge that there are a series of “smaller” problems that have to be solved before sales reps actually can maximize their compensation.  An Ishikawa diagram of your results would look like the following (consider only the main branches):

[click for larger version]

For some problems (and some teams!) this may be enough information to provide the context to develop a product backlog.  And your agile team will move forward into managing their own execution from the product backlog stage.  For larger or more complex problems (such as this example), you will need more detailed communication before diving into user stories / use cases.

The same Ishikawa diagram, with more detail, looks like the following:

[click for larger version]

For the largest and most complex problems, this is still not enough.  You can take each major branch of the Ishikawa diagram and create a child Ishikawa diagram.  However, from an agile standpoint (as in “staying close to your market”), you don’t want to do all of that detailed analysis up front.  Once you’ve prioritized the main branches in your main Ishikawa diagram, you will want to go to the next level of detail only for the first branch.  You want to make sure that you are delivering “working software” – not “comprehensive documentation.”  Delay your detailed analysis to the last practical moment.

Assuming you chose “Improve Predictability of Sales” as the first market problem to address with your product.  And within that choice, you are going to tackle “Align Solutions to Customer Problems” first.  Your child Ishikawa diagram could look like the following:

[click for larger version]

At this point, you would start writing user stories (or defining use cases) around recording customer problems, searching for ‘comparable problems’, predicting the problems a customer might face (before your first sales call), etc.  Those user stories will then get mapped to releases and iterations, and their implementation will be managed through the daily standups.

Outbound Communication of Agile Delivery

This problem-decomposition approach was presented top-down, specifically around providing the needed context to an agile development team to guide their design and implementation activities, giving them the opportunity to intentionally solve valuable problems, in alignment with the company’s strategy.

This same approach can be leveraged in outbound communication of what the team will deliver (and when).  You can easily construct a product roadmap that is actually an “agile problem roadmap.” [Ed: can I trademark that?  Probably not, since Enthiosys already does it, but without the word problem.]  In the short term, talk about specific problems (“Align Solutions to Customer Problems”) that you are solving.  In the longer range plan, talk about the next level of problems (“Improve Predictability of Sales”).  The team is not committing to a widget or feature.  The team is committing to providing a solution to a particular problem in a given release.

When you commit to a particular feature, you inhibit your ability to change as you learn.  And that’s bad.  You need to be able (after each iteration) to say “This problem is still valuable, but our previous idea about how to solve it turned out to be a bad idea.”  If you communicate at the feature level, you’ve added overhead to your process – you now have to manage expectations and update your communications, EVERY time you change designs.

You introduce another problem – these Ishikawa diagrams are so easy to read, and you’re now managing your roadmap based on problems being solved in a given iteration/release – should you tell everyone?  Many product managers sidestep the “Do we make our roadmap public?” question because they don’t create an easy to consume roadmap.  With this approach, you do.  So you have to decide if it needs to be a secret.

Zero-Overhead Planning

Early in this article, I said “agile team members rail against anything that looks like overhead.”  Creating Ishikawa diagrams is zero-overhead.  Or nearly so.  99% of the work that is displayed through the Ishikawa is work that you have to do anyway, to have an intentional approach to product creation.  The only overhead that is introduced is in the creation of the Ishikawa diagram.  If your thoughts aren’t already organized this way, you’re in trouble.  It takes almost no time to create the diagram that reflects what you should already be thinking.

And that qualifies as low-overhead.  And high value.  That should win over any resistance from the team.

Conclusion

As a product manager, you have to synthesize market problems, and develop a product vision to solve those problems that is aligned with your strategy.  As someone who is “part of” or “working with” (whichever matches your situation) an agile development team, you need a way to provide context to your implementation team.  That context can easily be conveyed with an Ishikawa diagram, with almost no incremental effort.  Your team can easily consume the diagram, and it gives them the freedom to explore different solution designs.  It also enables you to communicate your plans with the rest of the company (and externally, if desired).

Your strategy should be driven by the needs of the market.  Becoming market-driven is critical to intentional product success.  But it is not enough to understand your market.  You have to sustain your understanding, and take advantage of it, competitively.

Markets Evolve Over Time

We all acknowledge that markets are not completely static.  If they were, there would be no impetus for innovation.  Customers change, their environment changes, and the competitive landscape changes.  All of these changes cause a market to change.  Even if a given market were static, you don’t have perfect information about it.  Your understanding of that market increases over time.

The market is an abstract concept, and you have to make decisions about something tangible.  What is tangible is your understanding of the market.  And you make decisions based on your understanding of the market. You can visualize the market in a way that may cause you to rethink (or solidify) your approach to solving market problems.

In the chart above, we are showing that there is some amount of information (think of information as an understanding that we haven’t developed yet) about a market.  It represents the potential of what could be understood about the market.  Over time, the amount that can be understood increases.  Also note that there is already a non-zero amount of “understanding” at the start of the chart.  The market did not spontaneously spring forth from an oyster the moment you decided to look at it.

You Affect Your Markets

There is also an important dynamic to consider – you affect your markets by introducing solutions.

Whenever someone introduces an innovative solution to a market problem, the market changes.  Solving that problem exposes another problem.  Or it may introduce another problem.

• When cars replaced horses, they introduced atmospheric polution problems.  Before that, we only had to worry about horse waste.
• When airplanes solved the problem of traveling long distances in a short amount of time, more people began traveling further.  And those people discovered a need (desire) to stay connected (phone, internet, etc) while en-route.
• When it became convenient to carry music around with you on a portable player, the problem of carrying all of your music around with you was discovered / created.

You can argue that these problems were introduced because of innovative solutions, or that the problems were latent, and were only discovered because of the innovations.  It doesn’t matter.  What matters is that these problems were previously unaddressable, and now solutions to these problems have value.

Your Knowledge of Your Markets

Using the diagram above as a baseline of what can be known, and overlaying your knowledge looks like the following:

At the moment when you decide to understand a market, you don’t know anything about it.  Your knowledge rapidly approaches what “can be known”, and assuming you have perfect research, elicitation, and synthesis skills, you eventually understand all that can be understood about the needs of the market.

So much advice has been written about being market focused, that it is easy to think that this is all you need.  As soon as you understand “everything” you define requirements and start creating products.  Being market focused is extremely important.  But you have to sustain that focus.

Competition in Your Market

In the diagram above, you see the dynamics of your market.  You develop an understanding of your market, a competitor delivers an innovative solution to a problem, and you have to play catch-up.  Note – this is only talking about playing catch-up in your understanding of the market.  You also need to continue to develop new solutions for the market in order to capitalize on your understanding.

The next diagram shows what this will look like when there is active competition in the market.

The diagram above shows three disruptive events.  You innovate, someone else innovates, and you innovate again.  Each time someone else innovates, they have an edge on understanding the market.  They just solved a problem, uncovering new problems that can be solved, and you have to gain that knowledge too – it wasn’t available (or didn’t exist) previously.

Competitive Advantage

Each time you innovate, you establish a temporary competitive advantage.

When you introduce a novel solution to a problem, the market uncovers new problems.  Presumably, you have already thought about the next steps.  You have already engaged the market (through prototyping and other elicitation activities) to get feedback on your solution.  Hopefully, as part of that exercise, you’ve also explored “what’s next” and incorporated that into your plans.  This is the advantage you have created.  If you don’t explore “what’s next,” you waste that opportunity.

The opportunity won’t last forever.  Your competition will see your solution, talk to your customers, and otherwise explore “what’s next.”  It will take time, but they will catch up.  Over the long term, you benefit from exploiting a series of these opportunities.  Look at the iPod and the Zune.  Apple has delivered a series of disruptive changes, continually building on what they have learned.  Microsoft is playing catch-up with the Zune.  Each version of the Zune shares a lot of design cues and features with earlier iPods.  To Microsoft’s credit, they are trying to innovate too – like with the “squirt” technology that lets you share a song temporarily with another Zune user.  Either this is not a valuable problem, or the solution is not effective – because it has not taken off (in buzz, market share, or general clamoring for an iPod-based equivalent).

Fast Follower Competition

Some competitors intentionally act as second movers.  Instead of focusing their efforts on discovering problems or developing innovative solutions, they focus on playing catch-up very very well.

A fast-follower reduces (but does not eliminate) your temporary advantage.  At the same time, the fast follower creates their own advantage relative to every other competitor in the market.  This can be a very effective strategy, especially when there are multiple innovators in a single market.  The fast follower can follow the best ideas of each innovator, possibly even ending up with a better overall product than any of the innovators (who are slow followers of other companies).

Microsoft is clearly a follower of Mozilla when it comes to browsers.  The tabbed navigation concept introduced in Firefox was a game changer, at least for the tech-savvy who need to juggle multiple web pages at the same time.  Personally, I was thrilled to move from multiple Internet Explorer windows to a single Firefox window with multiple tabs.  IE7 has that capability now too.  I don’t know the browser market well enough to know if I would characterize Microsoft as a fast follower, but my guess is no.

After the post-World War 2 reconstruction in Japan, the Japanese automakers definitely acted as fast followers.  They did it with assistance from the US, and even moved past the US automakers by choosing to listen to Deming (a guru on efficiency and quality) instead of ignoring him like the US big 3 (automakers) did.  And it did indeed pay off for them – Toyota is poised to unseat GM as the number one automaker in the US for 2008.  There are certainly other factors at play, but the Japanese companies would never have had a chance if they had not been competitive in the first place.

Business Agility

Business agility is one of the hotter buzz-phrases these days.  The business-rules-automation market is thriving on the desire of businesses to become more agile.  Why does agility matter?  Because it can make you dramatically more competitive.

Business Agility is not the same as agile development!

Business Agility is a measure of the ability of a business to adapt to the changing needs of the market.  To adapt quickly, your company has to accomplish two things:

• Quickly identify and understand the changes in your market.
• Quickly deliver new and improved solutions that address the changing needs of your markets.

[How to quickly execute is covered in other articles in the business rules (including their impact on agility) and agile development categories on Tyner Blain.]

In the diagram above, you (the red curve on the top) are innovating repeatedly.  You are also adapting to the changes in your market from other innovations (and other sources of change, not shown).  You are practicing agile product management.  Your competition (the green curve on the bottom) is not.  As this trend continues, you see that your exploitable advantage becomes a sustained advantage.  You will have an ever-increasing advantage as you stay tapped into your market.  If you are executing (to deliver product) and communicating (to educate), you will be able to leverage your insights into a position of thought leadership.  [Note: "thought leader" is a title that can not be self-annointed, it has to be earned and perceived within your market / community.]

The end result is that you will be consistently aware of unserved market needs that you can serve before your competitors can.  That translates into increased demand for your products, which you can use to grow share, grow profits, etc.

That’s why business agility matters.  It isn’t cost reduction that is important, its top-line growth.

Agile Product Management

Staying tapped into your market like this is a strategic component of agile product management.  While continuously staying tapped-in (or Tuned-In), you regularly interact with your internal stakeholders to make agile development processes work.  Enthiosys has a great introduction to agile product management (free download with registration), if you’re getting frustrated with the many “empty presentations” about agile product management, then definitely check that one out – it has meat.  Relative to their onion, the topics in this article map to the portfolio and product layers.

If you aren’t already convinced of the value of a tight market focus, consider the following diagram, contrasting the impact of agile product management and traditional, waterfall product management.

• The red curve on the top (same as previous slides) represents an agile product manager staying tapped into her market.
• The grey curve in the middle represents a product manager staying tapped into the market, but not as tightly.
• The green curve on the bottom shows what happens when your organization is trapped in a waterfall delivery model.

The green curve, instead of reflecting understanding, reflects the understanding against which the team executes.  When you lock in or “freeze” the requirements, then begin a sequential development process, you stop taking advantage of market insights.  You essentially decouple your implementation team from the market – “we know enough already.”  So even though your product manager may be learning more (the grey curve), you aren’t taking advantage of that knowledge, so it is adds no value.

As an agile product manager, working with an agile implementation team, you will run circles around your waterfall competition.  Not only will you establish thought leadership, but you will be creating a distinctive competence for your company.  Your ability to understand the market, and quickly respond to changes in the market with valuable solutions will differentiate your company.

You also effectively change the dynamics of your sales over time.  Your accelerated insights allow you to release products (or capabilities) earlier.  Here’s a diagram from an earlier article on the ROI of agile that highlights the impact of this:

If we take the most conservative approach to modeling sales with an agile process, the graph would look like the following:

The sales volume curve is shifted to the left without changing its shape. The exact same growth curve applies to the product (this is the conservative assumption). The decline in sales continues to decline. The difference is that our previous time horizon (which remains fixed) now includes additional sales.

Product Life Cycle and the ROI of Agile Development

Agile Without Product Management

There are people who suggest that product management has no place in an agile environment.  Those people believe that markets can’t be understood until they are served.  They will argue that customers “don’t know what they want” based upon the feedback they get from prototypes.  Customers change their minds.  Yup.  But it isn’t that the customers don’t know what they want, nor is it that markets don’t have shared needs/problems/goals/requirements – they do.  Providing solutions to those problems drives next-level thinking, and the identification of new and different problems.

If you don’t have product management, you can only succeed through luck.  Throw stuff against the wall and see what sticks.  If something sticks, you win.  This is better than a waterfall model that ignores the market (for long periods of time where release plans are “set in stone”).  But it falls well short of driving a very efficient, adaptable implementation team directly towards identifiable market needs.

Adam Bullied wrote a really good article about not losing motivation in the face of challenges. His closing quote spun us off on a philosophical tangent about being “good enough.”

Good Advice

I’ve enjoyed several great conversations with Adam over the past couple years. I thank this blog as the catalyst for introduction to him and other really sharp folks, many of whom generously contribute to the discussion that launch themselves from some of our articles. Thanks to all of you!

Adam’s article wrapped up into three general ideas for me:

1. Good general advice (don’t get discouraged by external events).
2. Good product management advice (focus on the problem).
3. Pragmatic execution advice (be good enough).

On the first point – just go read Adam’s article. You’ll like his writing, and you’ll find a new blog to read regularly (if somehow you aren’t already).

On the second, Adam says the following (the links are ours):

You need to just do a few things really well. In fact, things I’ve already mentioned:

1. Ensure you are solving a problem
2. Align things from top to bottom
3. Execute — quickly and with confidence

This “top-down” stuff I speak of is from the vision / problem identification, to the roadmap, to the requirements, to each release being pushed out the door.

Don’t Get Discouraged, Adam Bullied

Good Enough (For Now)

Adam’s third point, about being good enough, I believe, is an encouragement to make progress, and move the ball forward in the face of adversity.

Perhaps it’s my own character flaw, but my first instinct was to think of his comment out of context. I’ve always believed that “good enough” is the enemy of great. “Good enough” can be interpreted as “do less than you can.” That’s not what I think Adam is saying, although that’s the thought that popped into my head at first. Adam’s point is really a good one – don’t let the fact that you can’t make something perfect today prevent you from making it better today. Tomorrow you can make it better still. Add up enough tomorrows…

Maybe this distinction is why I like the underpinnings of agile (iterative) development. Find the most important thing you can do today and do it. Tomorrow, you will be smarter, having done something already and learned from it. You’re in a position to better understand importance. Use that learning to do the most important thing you can think of – even in the unlikely event that the most important thing you can do is refactor what you just did the day before. Over time, things get better.

Good enough for now means do the best thing you know how to do today. Don’t hesitate because you suspect there is something even better you could do, if you could only think of it.

Maybe this nuance is not communicated well by some proponents of agile development. Many smart people rail against the hyperbole of big-A Agile, and throw the baby out with the bathwater and discard small-a agile.

Present yourself with two possible approaches to deciding where you will live for the next fifty years. The first approach is to decide now (but you have a month to do research and make your decision), and no matter what, you have to live there for fifty years. The second approach is to decide now (and your answer must be given in the morning), but if you decide after a year that you want to live somewhere else, you can move. And every year, you get to re-assess and stay or move.

I like this better than the classic “build a house” analogy, because it represents both the cost of change and the impermanence of decisions in a way that is more aligned with software development. It also allows for some other analogies. If you know that you may decide to move again in a year, you’ll make different investments in your new abode. You may choose to live minimally to reduce the cost of moving again. You may become an expert at moving. And you can easily balance the cost of any particular move with the perceived benefit of making the move. “Not worth it?” stay where you are. As you learn more about where you live (and where you might live), you develop a better appreciation of what is important to you. My guess is that sometime well before the fifty year mark, you would have settled in on the “perfect” home.

Now what are the odds that the perfect home after several iterations of change is the exact same home you would pick with a month of research and no experiences?

Each home is good enough for now, and likely to be better than the last home (after all, you’re smarter each time you move than the time before). And you stop moving when the opportunities to improve fall short of the cost of making changes.

Is your product successful because you were lucky, or because you were methodical and intentional?

Do you want to build a plan where you are dependent on good fortune, or do you want to make your own “luck?” Both approaches work, but only one makes sense as an intention. Slide 3 of your presentation to a venture capitalist should not say “And then we get lucky!”

Product Success Is Not Easy

Saeed Khan wrote a critique recently, in On Product Management, of an article by Phil Meyers on the Tuned In blog. Phil’s article is an analysis of the pending re-organization at Starbucks, and the one quote that Saeed keyed in on was:

At the end of the day, its simple. Create a product or service that your buyers want to buy and the rest takes care of itself.

Saeed’s point is that it is not that easy. A lot of hard work goes into creating a successful product. And Saeed’s right.

Maybe Phil’s point is that the executive should not worry about the details, and trust in his team to do all the hard work. But he doesn’t really come out and say that, so we can’t really back him up on that front. Let’s give him the benefit of the doubt anyway. There’s another point that Phil makes that is potentially disturbing:

Looking at metrics like average same day sales and products per square foot lead you down some strange paths. Schultz even admitted as much in a letter from the board about a year ago in which he worried about the company ‘losing its core’.

Yes, abandoning your goals to pursue your metrics is bad. But don’t abandon your metrics to pursue your goals – unless all you want to do is get lucky.

You might argue that a company like Animoto got lucky when their product spread virally within Facebook and their user base jumped from 25,000 to 700,000 users. But if you listen to the interview that Amber MacArthur did with co-founder Brad Jefferson, you will realize that it was only when they tweaked their product offering – a response to empirical analysis of product adoption metrics – did their success explode. I would argue that they made their luck by being intentional.

Empirical Processes

When you can perfectly model your business analytically, you can measure the inputs and know (with certainty) the outputs. As a college engineering student, I learned this. Real world processes can never be perfectly modeled analytically. As a professional engineer, I learned this too. Real world processes are empirical. The secret to great engineering is to apply analytics to those empirical processes to create disruptive innovation, and combine it with empirical controls that help you statistically predict the likely outputs. The answer is simply that neither analytics nor empiricism alone can help you achieve greatness.

Business processes are also empirical in nature. Even when you can devise an analytical model for the behavior of an isolated system, you have to acknowledge that no real world system is isolated. You have to expect unexpected inputs into the system. As Saeed points out, you have to apply analyses to make smart decisions when developing your process (or business model, or product). And what Phil appears to discount is that you also need to apply empirical measurements to your process (or business or product) to control the expected results.

Creating Successful Products Intentionally

This article proposes that there are two paths to product success. The first path is simple. Cross your fingers, then get lucky. The second path is harder. Be intentional.

1. Identify your market (and therefore your customers and competition).
2. Identify their problems, and select the ones you will solve.
3. Create a product roadmap (aka a “plan”) to solve those problems.
4. Design and implement solutions to the most valuable problems.
5. Get feedback on your solutions.
6. Incorporate your feedback into your plan (step 3) and repeat.
7. Revisit your market (step 1) and the problems you choose to solve (step 2) and repeat.

Note: Step 7 should occasionally replace step 6, so that you stay focused on your market, and not just an out-of-date snapshot of what used to be important to your customers.

1. Identify Your Market

There are a lot of ways to pick a market to focus on. You can chase demographics – there sure will be a lot of retired people in the US thanks to the baby-boomers. You can go with what you know – years of paying attention to an industry presents ample opportunities to understand the market. You can create an entirely new – blue ocean – market by solving problems people don’t even realize they have until you offer a solution. Choosing a market is the subject of many books, not just an item in a list.

Once you choose a market, you need to segment the market into groups of people who share the same problems and who value solutions to those problems similarly. You can apply market research to improve your market segmentation.

2. Select The Problems You Will Solve

You use elicitation skills to identify the problems that your customers face. And when you have to address multiple market segments, you can prioritize the problems across those market segments.

3. Create a Product Roadmap

Once you’ve prioritized the problems you are going to solve, create a product roadmap. Your product roadmap should show the problems you are solving, and the order in which you will solve them. When you define sequencing, you also must define your approach to scheduling product releases.

4. Design and Implement Solutions

There are two keys to successful execution of the plan you built with your product roadmap. First – use rolling-wave planning to define near-term details and long term vagaries. Second – make sure you have continuous integration as a key component to managing quality throughout the process, instead of checking quality at the end (or even worse – ignoring quality).

5. Get Feedback on Your Solutions

This is half of why agile (when done right) works [Can you believe the discussion over the last year on this article is up to 27 comments?!]. Feedback is not just something you get when sharing a prototype with stakeholders. Feedback is also something you must get as part an incremental release methodology.

You can even measure the ROI of your designs, and incorporate feedback at the design level.

6. Incorporate Feedback Into Your Plan

There’s no point in gathering feedback if your organization and your process are organized to resist changes to the plan. Contrary to what the Standish Group’s CHAOS study has always implied [and we've made this implicit mistake too], release schedules are not the primary measure of project success. In a fantastic article at Dr. Dobb’s Journal, Scott Ambler points out that in his survey results, almost two thirds of professionals find that doing the right thing is more important than meeting a project schedule.

Schedule: 61.3 percent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time.

Do the right thing. If the right thing involves changing the schedule, that doesn’t make it wrong. What makes this work is the fact that you are getting feedback early and often. It is a risk mitigation strategy, designed to reduce the possibility that you will create an unsuccessful product. It is not a strategy designed to keep your project on schedule no matter how mis-aligned you are to your market.

7. Revisit What You Are Doing And Why

If step 6 is small-scale course correction, this is large-scale course correction. You may discover that solving a big problem for your customers exposes a new “biggest” problem that wasn’t there before. By revisiting step 2, you can choose to tackle or ignore those newly discovered problems.

You may also discover that by leveraging your investments to date, you dramatically improve the ROI of solving problems in another valuable market segment. This is because even if solutions to those problems have the same value, solutions to those problems now have much lower costs (for you). By revisiting step 1, you give yourself the opportunity to best manage your strategy, your resources, and your plans.

Conclusion

Product Success may have an element of luck, but you should never plan to hit the lottery. Be intentional in what you will do, and a good plan, executed well and adapting to change, will get you there.