Apr 102012

Quite a few clients report that agile is anti-innovation. The developers have a vested interest in developing whatever they can produce within the allowable time. They are rewarded for maintaining the velocity of the project, not for their innovative solutions. Note that innovation, as we use the term here, means fresh thinking. We do not mean that innovation is the same as invention — it’s not. Innovation is thinking differently about the business problem with the intention of finding more beneficial things for the business to do.

User stories that are not based on real business stories will struggle to be innovative. The user story describes what happens at the interface and is mostly what the product owner thinks the user wants to do with the software. But without some innovative thinking, it is all too easy to provide just some incremental improvement and let it go at that. Let’s look at an example of a user story that was written without any real concern for innovation or the real need that the story is meant to satisfy: “As a bank account holder, I want to check my balance online.”

At first, this might seem a reasonable and obvious story. However, it can be made a lot better. Some authors suggest that the “so that” part can be omitted. We suggest very strongly that you always include the reason in your stories. While the Agile Manifesto favors working code over documentation — and there is a lot to be said for that — there is nevertheless a need for the development team to leave behind a guideline of its thinking. Without justifying the requirement — that means including the “so that” — future maintenance teams are deprived of a valuable clue as to why a particular requirement was included in the software product and, hence, what would be the effect of changing it.

Our first question is, “Why does the account owner want to check the balance?” Let’s revisit the story and this time look at the reason given for the requirement: “As a bank account holder, I want to check my balance online so that I can access my daily balance 24 hours a day.”

This is not exactly a good reason for checking the balance. The “24 hours a day” is slightly more enlightening but doesn’t really do more than tell us that the account owner might have nocturnal habits. Why does the account owner wish to check the balance? It is not something we do for fun, so there probably is some business reason behind it. We just don’t yet know what that is. Let’s make some conjectures.

Suppose the reason for the frequent checking is that the account owner is on a tight budget and is concerned about becoming overdrawn. If so, the owner of the product, presumably a bank, has the opportunity here to be more effective and at the same time provide a better service. Instead of the account owner having to repeatedly check his or her balance to see that it’s not going into the red, it would be better to build a feature that notifies the account owner if the normal monthly payments such as rent, electricity, school fees, and so on, will reduce the account balance to zero or beyond: “As a bank account holder I want to be informed if my monthly balance is projected to go to zero or below so that I can arrange for an overdraft.”

Furthermore, we suggest that it is far more useful for the account owner to be periodically informed of the amount of discretionary money in the account: “As a bank account holder I want to be informed of my projected balance after all regular monthly payments have been deducted so that I know how much I can safely spend.”

Having a feature that lets the account owner check the balance online is the simplest feature to have. However, we suspect that without any kind of business thinking, or innovative thinking, it would probably turn out to be a feature that did not solve the real problem. If other banks solve the real problem (i.e., they understand the real needs of their customers and offer this service to attract more customers), then the original story could hardly be said to providing real business value.

When a business analyst investigates a business story, he or she is consciously trying to encourage innovation by first making abstractions that uncover the real business problem. Figure 7 illustrates the skill of looking at the same business story from several different points of view and thereby discovering undreamed of innovations that could make a significant difference to the business.

Figure 1
Figure 1 — The Brown Cow model illustrates four points of view that help to uncover the real business problem and identify useful innovations.

In the bottom-left quadrant of the Brown Cow model 6 the viewpoint focuses on how things are done now. This is commonly what business people ask for — a little bit more of what we already have. In the bottom-right quadrant the viewpoint focuses on how things could work in the future. Once again, it is likely that someone who has a requirement will express it in these terms. In other words, like our nurses in the previous example, rather than asking for what they really need, they ask for a solution.

As part of his or her analytical skills, the business analyst also learns to explore the problem in a solution-neutral fashion. We refer to this as the ability to “think above the line.” The line in this case is the horizontal line that separates the top and bottom quadrants of the model — the abstract thinking about the real problem from the technological view of the solutions.

The top-left quadrant focuses on what we do now, independent from how it is done now or how it might be done in the future. This view uncovers the essence of the problem: the business rules and the business data that has to be there independent of any solution. Above the line, the business analyst exposes the real business requirements by stripping away all solution-oriented aspects and thereby coming up with a policy-only statement of what the business is really doing. The top-right quadrant of the model is where the business innovation happens. It is here that the business analyst can make suggestions about improving business rules or using existing business data to be able to make better business decisions.

Innovative business value discovered by this sort of innovative thinking are then included in the business stories. These are innovations that could never be discovered by focusing on a software interface.


James Robertson

James Robertson is a Senior Consultant with Cutter Consortium's Agile Product & Project Management practice. He currently advises companies on how to adapt modern software development techniques to fit specific projects and how to effectively transfer the new technologies to the software developers within the organization.

Suzanne Robertson

Suzanne Robertson is a Senior Consultant with Cutter Consortium's Agile Product & Project Management practice and is a principal and founder of the Atlantic Systems Guild. Ms. Robertson is co-author of Requirements-Led Project Management (Addison Wesley, 2005) a book that provides project managers with guidance on how to use the work done by requirements analysts as input to steering projects.


  14 Responses to “Keeping the Innovation in Agile”

  1. Another helpful technique is Service Design. It takes a user-centered approach, focusing on the customer’s journey and their jobs-to-be-done rather than on the application. This approach, along with service design’s roots in design thinking, make it useful in identifying and communicating customer needs, and opportunities to innovate to better meet those needs. Also, by addressing the entire customer journey, service design considers offsite user interactions such as phone and email that may otherwise be forgotten.

  2. I think it boils down to the debate of “Designed Solution” vs. “Emergent Solution”. It can be argued that after the user starts using “check my balance online” facility they will come up with the requirement which is discussed here. In other words these features will “emerge” over a period of time. But, the problem is such evolution is a slow process!

    Same logic can be extended to architecture of the product!


  3. “so that..”

    Excellent, something very simple yet very powerful…

    David Wright

  4. Well said. Thanks so much for the brown cow, which is very useful way of thinking. Maybe it should be a holy cow.
    About the user story format, each of the parts and are all indispensable. Actually I’ve run a course a few times on using user stories to kick start incremental innovation, where I encourage teams+PO to use the “so that” part to keep the goal of the user story in sight and think of ideas/means to the end (goal).

  5. Good blog. Pre-Agile I found the technique I liked as the Product Owner (actually wore CTO/VP Eng/Product Marketing hats in my little company) was what we termed “Practical Software” (before I’d heard of Agile) where we maintained the design docs in a requirements management system. Would update things there to start, developers would work from that, and QA test. The results: an accurate final As Built Specs! We varied that for brand new projects requiring innovation. We’d throw out the concept, developers and everyone work together to talk about options. Sometimes developers even wrote the spec if it was more of a tool than a business concept. I was always diligent that any innovation or other changes occurring during the cycle were updated in our Requirement Management tool so it could be the “Bible”. It was ALWAYS updated BEFORE QA could start testing to be sure we were all in-sync. Those Requirements Specs were invaluable through the years, release after release, for the Call Center to give quick feedback to customers about the requirements were and why the code did what it did, Invaluable for developers & QA to research the business needs behind the code. And gave me a nice readable doc to understand, years later, every aspect of our product (even when it got so big I didn’t even remember every nuance). Invaluable when making changes or adding new modules.

    Now I’m consulting on an Agile project. What I’m finding is with the story management tools, you lose the context. It isn’t organized in a way I can see the requirements in the same spec as my old write-ups and tell if it’s all consistent. Working with Agile stories throughout the release cycle seems disconnected.

    My “aha moment” was that stories ARE developer tasks ARE requirements as the evolve during the product life cycle. You start with a story, it gets re-factored, assigned to developers. While they work on it, split it out, update it, change it with new ideas – it should stay organized in it’s spec so the developers work on “tasks” but the product owners can look at everything like a readable doc.

    We built a tool to do that. As you enter a new task, that’s the task title. As the release progresses, POs update the description with the specification the developers are building to. When done you have the organized specifications in a doc automatically. Would love your feedback on if you think that’s as great a concept as I do !

    I think that will be an aid to innovation – it’s working for me as we build our new tool.

  6. This is an issue related to Software Engineering (to be more specific, it is ‘Requirements Specification’ issue). In Scrum parlance, it is an aspect to be addressed primarily by Product Owner (or a team of Product Owners, Business Analysts in large projects) and Scrum Master.

    We do have several weak links in the way we specify requirements.

    Sometimes, one may decide to keep ‘check the balance’ user story because competitors are offering it or a small group of users in some corner of the world needs it. Meanwhile, when this user story is not necessary because it not going to be used or has a similar (and better) feature, it is wise to avoid it.

    More info on ‘Requirements Specifications: The Weak Links’ at


  7. There now an alternative where interpretaion gap is closed – the business anaysts now builds business applications as code wiriting no longer required.

    Just this week Naomi Bloom a renowned consultant, analyst and thought leader with a strong HRM focus posted a must read article on Agile, Models-Driven Definitional Development – see http://infullbloom.us/?p=3222
    Some quotes that should encourage you to look into it for your clients the limit on innovation becomes imagination!
    “Writing less code to achieve great business applications was my focus in that 1984 article, and it remains so today. Being able to do this is critical if we’re going to realize the full potential of information technology”
    “….how those models can become applications without any code being written or even generated.
    “…object models become the functionality of the applications with a minimum of human intervention, whose business functionality is therefore built and modified only at the models level. Such an approach can be very flexible initially and over time, easy and fast to implement, and inexpensive for both the vendor/provider and customer to acquire and maintain”
    “If I’m right, you’ll want to be on the agile, models-driven, definitional development side of the moat thus created, whether you’re an HR leader, working in the HRM software vendor community, or an investor in that community.”

    Later in a tweet Naomi said “It really matters how your vendors build their software, not just what they build” and Michael Krigsman a leading analyst tweeted referring to the article “Pointing to the technical foundation of future”.

    This is now happening and the speed of development with in built agility all developed in business language will bring huge benefits to business. Yes legacy is a big issue but use this new capability to modernise use of legacy.

  8. If we think Agile from manufacturing perspective, it’s all about velocity which matters. If you are manufacturing a product like car which is repeatable enough, only thing which you need to worry about speeding the product generation process while improving the product itself by keeping out ‘muda’.

    The problem or I should say, good thing is – software world is not manufacturing industry. It’s not only about speeding the product generation but more and more about questioning the product itself. “Simplest thing which works” is not about taking out innovation but forces you to think and be innovative to check the actual thing which is required. So Agile is not only about efficiency (velocity) but a lot about effectiveness too. The team always questions to remove the flab (eliminate waste). Here when I talk about the team, it’s not only BA, it’s everybody (developers and testers) who first of all question a lot if the user-story is really needed and if needed what’s the simplest way to achieve it. When you continuously question and aim for cutting out the flab of the application, you are not aiming on improving velocity (story points done) but cutting the product backlog itself. And in the agreed product backlog, continuously working on providing things in effective manner.

    That’s the reason why Agile focuses on being fully functional instead of fully featured.

    Another important part is – how to achieve business value. If you talk about business value, at the end it either turns out in dollars or provides long term benefit. The way user-story is defined, people often get into the trap of cause-effect circle. “I want …so that..” can all be cause-effect which certainly doesn’t question or lead you towards actual business value. However asking a lot of WHYs can lead you towards actual business value. If it’s not leading you towards that, you may need to remove that user-story. The basic of asking a lot why questions has been taken from http://en.wikipedia.org/wiki/5_Whys, however here we don’t limit to only 5 why but can have a full mindmap leading us towards multiple permutation-combinations and towards actual business value.

  9. “These are innovations that could never be discovered by focusing on a software interface.”

    Sometimes the best innovations come from putting yourself in the shoes of the user. What would make this software better for the person using it? What features can be added/eliminated/streamlined?

  10. avatar

    I’d like the authors elaborate on “We do not mean that innovation is the same as invention — it’s not”.

    • Géry, but that we meant that invention is coming up with something completely new — the wheel, the lightbulb, touch-sensitive glass, etc. Innovation is fresh thinking. That is, thinking about the problem differently and deriving a better, more elegant, more beneficial solution. For example, in Sydney where I am at the moment, the public transport people came up with the innovation of selling a ticket that could be used interchangeably on all three transport modes – trains, buses, ferries. Prior to this time you needed separate tickets. Obvious? Yes (after the fact), but still innovative in that is required looking at the problem freshly (and from the traveler’s POV). The Nespresso machine and it’s brightly colored capsules is innovative – it represents a new and different way of selling coffee. It did not need any invention to bring it about.

      The reason for the distinction is simply that people are afraid that if they have to become inventors, they will fail. However, any of us can be innovative. — James

      • Géry, I saw another example last night. It was an invention when the first South Sea islanders added an outrigger to make their canoes stable. It was an innovation when someone used that idea and came up with the catamaran. A further innovation when the designer of the Sydney ferries decided that the ferries would be better if they used a twin-hull (catamaran) design.

        I hope this helps clarify.

  11. A critical aspect of agile development is exploring intersection of business use cases and technical use cases. I have been developing software “agile” way for last 35 years or so. Innovation is essential element in that exploration. Today we see lot of inexperienced programmers doing “agile” development. This limits scope for both productivity and innovation.

  12. I recommend listening to this radio interview http://bit.ly/ckeutZ As Naomi Bloom points out coding is expensive to build and maintain. So why are we coding? As she point out definitional objects model development has arrived that eliminates coding. Also see this good debate http://www.ebizq.net/blogs/ebizq_forum/2012/08/will-bpm-eventually-replace-traditional-programming-as-a-way-for-businesses-to-rapidly-deploy-it-sol.php
    Not only is it rapid and “agile” it encourages innovative thinking from users – real empowerment.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>