It is essential that teams understand what the business value of the stories they are working on is. We must always remember that the software we are developing is useless, in and of itself. What is useful is what it enables – either by our customers (if we are a product company) or by our own staff using it (if we are in IT). Stories always need to be pieces of the business solutions – either providing it or creating the infrastructure to provide it. We call the visibility of this relationship between stories and the business value they create "Line of Sight." It is important for 3 critical reasons. With line of sight:

• Teams are more likely to stay focused on what really needs to be built
• Teams can ensure all of the pieces are completed in the right manner
• Management can better understand what teams are working on

See More Insights on Epics Vs Minimum Viable Features for more insights on the first item. The second item results from a critical difference of this top-down approach with a bottom up focused on stories. I'll illustrate this by recounting a conversation I had with the director of development of a medical instrumentation firm who was considering agile methods but was highly skeptical of them. He said something on the order of – "In our business we have to validate that all of the requirements are done and have to show an audit of how they were, in fact, accomplished. I don't see how you can do this if you are working from stories." The last sentence was actually a challenge to me to show him how to do this. My response, however, surprised him – "I don't see how to do it from stories either. That'd be like trying to figure out if you had all of the pieces of a dismantled picture puzzle by looking at its pieces. What we, at Net Objectives, do is come from the entire picture, the features, and split them into manageable pieces. Each split can be audited if you like. By carefully segmenting the work you can be assured you have the entire puzzle. It's like starting with the entire puzzle together, and taking it apart. As long as you don't lose any pieces, you'll know that you have them all (and you can count them as you go so you don't lose any!).

This perspective change is critical. Many teams struggle because the common Scrum literature (our currently most popular Agile process) talks about stories as the holder of requirements. But mindset differences typically result in large behavioral differences (see Differences in Beliefs Results in Differences in Approach).

Our book, Lean-Agile Software Development: Achieving Enterprise and Team Agility is as much about shifting perspectives as it is about critical practices and principles. The chapters "The Big Picture", "Lean Portfolio Management" (online) and "Lean-Agile Release Planning" provide additional insights on what was discussed in this blog. If you are having trouble scaling your agile methods to your enterprise, I highly suggest reading this book as it recounts how we've been able to do this successfully and repeatedly.

Technorati Tags: Lean Managing Lean-Agile

tag with del.icio.us