Feeding the Agile Beast
I want to share the presentation I did in the Open Jam at Agile 2009. I got good feedback from some of the thought leaders there like David Anderson, Chris Matts, Eric Willeke, Chris Shinkle, and Mike Cottmeyer. Ok, enough name dropping. A common theme at Agile 2009 was, “Now that we are pretty good at small teams developing software, what’s next?” One of the answers is making sure the developers are working on the stuf that provides the greatest value back to the organization. A lot teams aren’t very good at this.
If your projects are anything like most of the development projects I’ve been on you are likely to run into cost and time pressure near the end. Our story might be something like, “We can’t meet your needs for the planned cost or by your expected time-frame. We have been telling you from the beginning there was uncertainty in the requirements and that development is fraught with risk. You will just have to pony up.” Customer’s don’t like this but they have come to expect teams to be late and over budget.
If you had the foresight and tools to understand how to focus on eliminating risk on the front end and then building the highest value things first, you can go to your customer with a story like this, “Even though there is a lot of uncertainty in the requirements and exactly how we would build the software, we have a working product that meets all of your most important business needs. In fact, I bet you didn’t know that over half of all the technology built is never even used in the end. We would love to continue to build out the remaining features after we get this adopted by your customer, but we bet addressing what they think is important will be more valuable than building out elaborate and potentially unused features.”
I have used this approach on about a dozen efforts and have found that it promotes far better communication between the team, product owner, and customers. It provides clarity on what needs to be build, why it needs to be built, and how we can do acceptance testing on what is built. It is also low friction to maintain if the product or project strategy changes in flight. It is a sustainable artifact that connects Ivory Tower discussions about business value and risk to the developers context.
Typical Business Analysis techniques have high transaction costs and high coordination cost while still not getting the key points across to development. We end up with lagging risk, too much rework, missing critical requirements, lack of testability, and over engineered products. This is very expensive – both in terms of what is spent to deliver to our customers and in terms of meeting the needs of the customers. Once we change the conversation from “What can we get done this week?” to “How can we optimize business value and manage risk responsibly?” we are on the right track to Feeding this Agile Beast.
Tags: Agile, Business Analysis, Business Capability, Software Development
Dennis,
WHAT, you mean work on things that the customers stated in the requirements elicitation sessions ;>)
It’ll be interesting to see how the small team aigle scales and what they have to bring along that is already being used in the large team work.
Glen,
Thanks for the comment. And yes, I mean work on the things the customer stated in the requirements elicitation sessions. In an order that gets to cash as quickly as possible while establishing a maintainable and sustainable base. As common sense as that is to someone passionate about this who has 20+ years of experience, it doesn’t happen often enough in many businesses.
This is more about helping existing organizations get to an actionable approach as it is creating brand new capabilities. Probably most of what is already being done on large team work will still be done – the cycle times, detail, and level of formality may change. Appropriate outcomes will dictate the appropriate implementation strategy.
I look forward to your feedback as we build out this model.
[...] getting faster at development is just part of the equation. As I discussed in my presentation “Feeding The Agile Beast”, you have to identify, prioritize, and scope what you are going to build so that risk is managed [...]
[...] address this in Feeding the Agile Beast. This is the domain of Business Analysis. As the Gilb’s point out, most Agile methods abstract [...]