The pop-culture concept of a silver bullet – a simple solution to a hard problem – is a dangerous idea. It can be used to over-promise, and doom a team to under-delivery. When an executive, too far removed from what makes creating products hard thinks of “agile” as a silver bullet it becomes difficult to manage expectations.
Potential
The business practice of agility (small a) – specifically when an organization, and not just a technology team, adopts the practice – has a lot of potential. It is precisely that potential which inspires not-yet-informed executives to learn about how agile could help them.
People tend to forget the caveats of how and why agile can work – and just assume it will work.
Even if agile is a silver bullet, you still need a gun, and you still need to learn how to shoot. There’s hard work involved.
In discussions with colleagues over the past week, I pulled together the following four assertions of potential – each of which requires hard work.
Agile gives you…
- The potential to quickly improve your choice of what to build– but only if you listen to market signals suggesting change, and only if you then take action to change.
- The potential to deliver more efficiently – but only if you invest to decouple smaller units of work, and only if you do not fill the system to capacity.
- The potential to provide better predictions – but only if you invest in estimation skills, and only if you culturally make a distinction between prediction and commitment.
- The potential to deliver higher quality products – but only if you collect customer feedback on your solution approach, and only if you effectuate appropriate changes.
Quickly Improve Your Choice of What To Build
- The potential to quickly improve your choice of what to build- but only if you listen to market signals suggesting change, and only if you then take action to change.
In The Design of Design, Fred Brooks (of Mythical Man-Month fame) writes about the conflict of empiricism versus rationalism; sensing what you need to be doing as you go, versus deciding in advance based on existing knowledge.
If you decide in advance which problems are important to solve, then you will get roughly the same amount of value out of your solution regardless of what process you use.
[tweetherder]When you fail to change which problems you solve, for whom, you fail to realize the true value of agile – business agility[/tweetherder].
Products fail primarily because they don’t solve customer problems. The agile process gives you frequent opportunities to validate the hypotheses on which your product strategy is built.
Waterfall is a process optimized to best execute against the original plan, it makes changing difficult. Agile is a process minimizing the difficulty of changing by delaying decisions until the last responsible moment. The process allows you as much time as possible to get smarter about what you want to do – and you only benefit when you acquire the knowledge and then do something about it.
Deliver More Efficiently
- The potential to deliver more efficiently – but only if you invest to decouple smaller units of work, and only if you do not fill the system to capacity.
In teaching us how cost of delay works, Don Reinertsen explores queueing theory and its impact on system performance. There are a few building blocks – but when you combine them, you understand how to optimize the efficiency of any system’s ability to deliver outcomes (not outputs).
- For any deliverable which realizes value, delaying it delays the value. In Market Driven Competitive Advantage, we looked at how we can accelerate the rate at which we gain understanding about our market through an agile cadence (more appropriate to the value of making changes), and also demonstrated that moving faster than competitors accelerates value realization.
In Reinertsen’s cost-of-delay model, he would describe the green hashed area under the curve as an increase in captured life cycle profits. Delaying the release of your product introduces the cost associated with shifting this curve in the other direction: your delay, relative to competition, comes at a cost. Delaying the delivery of a solution has a cost that increases as delay increases. - In stochastic systems, such as software development, the amount of time required to implement any particular feature (supporting a capability, and therefore the solution of a valuable problem) varies. The pacing with which requests are made (choices about problems to solve) also varies. The math of queueing theory states that the closer you get to 100% utilization of resources, the longer the delay in the queue for any particular item. Because delay equates to cost (1), the closer you get to 100% utilization of your team, the greater the cost of delaying work.
- To get the same amount of work through a given system faster, you increase the capacity of (and ongoing costs of) the system. You then minimize the combined costs of “excess capacity” and delayed value (2). Avoid delay costs by avoiding 100% utilization of resources / capacity in the system.
- You also reduce the queue length – the delay described in (2) – by reducing the variation in size of work items, although this is a secondary effect relative to the impact of utilization. Make items roughly consistent in size to reduce the cost of delay, all other things being equal.
When you have tightly coupled systems or teams, then you are in a situation of competing for shared resources. Imagine a simple scenario – both a website team and a mobile app team rely on the same API team to contribute to delivering valuable solutions, perhaps for different groups of customers, solving different problems. One or both teams will have to delay the realization of value (and therefore life-cycle profits) because they are competing for shared resources (in the API team). Changing the architecture, or team skills and permissions to remove the dependencies would eliminate or reduce the cost of delay.
An iterative system of delivery, like agile, enables you to deliver to market faster – to outmaneuver your competition and capture a greater share of the profits – but only if you can actually deliver product faster. If the backlog is so large that it delays work significantly, it undermines the value proposition of realizing benefits in parallel with ongoing development of your product.
An analysis of the economics of SaaS product models demonstrates the acceleration of value realization for your customer. The dynamic of the system is similar for acceleration of delivery.
Provide Better Predictions
- The potential to provide better predictions – but only if you invest in estimation skills, and only if you culturally make a distinction between prediction and commitment.
Prediction is important, not to satisfy the whims of micro-managers, but to inform the context in which more broad-reaching decisions are being made. Compartmentalization and decomposition are key aspects of scaling an organization to solve large problems.
Agile prediction requires a shift to framing prediction in terms of outcomes and not activities, but that’s a topic for another article. Regardless of what you’re predicting, there’s a critical change required to be able to predict.
A single decision maker cannot make all of the small decisions which need to be made every day about every product a company is creating. Which design approach to use, which open source library to leverage in implementation, upon which individual customer to schedule the first sales call, etc.
Every capability being created or improved in the product or in the company is being created in order to help a customer solve a particular problem, or to help the company be more effective. All of those investments are competing for limited resources – time, money, people’s energy. To determine the best allocation of resources, you have to make cost-benefit and prioritization decisions, at one level of abstraction higher than the work itself.
To do this, you have to be able to estimate with confidence. Confidence in the accuracy of your estimates, confidence in your security when providing estimates – particularly knowing your estimates are interpreted as estimates and not commitments.
Holding people accountable for their estimates changes how they estimate. People bias towards safety, not accuracy. Regardless of what process you use, you will be undermined in your attempt to predict results when you are unable to trust the underlying estimates.
Deliver Higher Quality Products
- The potential to deliver higher quality products – but only if you collect customer feedback on your solution approach, and only if you effectuate appropriate changes.
Quality should be defined from the outside in, just like your product. When you define quality as “how many bugs there are” you are thinking too small. Counting bugs is a myopic focus on craftsmanship of the people doing the building – it only reflects if they made mistakes in execution. This is important, but by far not the most important aspect.
Fitness function is a much more important reflection of quality – and the one your customers will predominantly use. Does the product contribute to solving the problem your customer is trying to solve? It really is that simple.
If your product is not useful for your customer, they don’t care if it is bug free.
Where the agile process enables higher quality – better fitness function – is through the iterative cadence. Most people see – and act on – the cadence of development and delivery. It is the most visible aspect of the cadence, however the value is only enabled by having progressively ‘better’ product – the value is realized through getting and incorporating feedback to the product, on the fly.
In every process, you make assumptions about how to effectively solve the problem. In a non-agile process, you completely build the product before you find out if your guess was correct. An agile process allows you to discover earlier, and make changes. If you don’t do the problem-solution-fit discovery work, you will not realize this value.
Conclusion
Agile enables significant value realization – it does not deliver value without additional work. [tweetherder]If agile is a silver bullet, you still need a gun, and you need to learn how to shoot.[/tweetherder]
Replacing a long upfront planning cycle is valuable when you invest to get smarter, and then act to change based on what you learned. Listening is key – both to changing focus and to discovering the need to improve the quality of your solutions. By managing the size and amount of work items, you make the system of delivery more efficient. With cultural and skill changes, you make it possible to predict accurately.
Trustworthy predictions about accelerated, effective value delivery enable are a competitive advantages – which you can leverage in distinct product strategies.
Extra sales in Reinertsen’s cost delay model, is where the solid line is above the dotted line. There are no extra sales at the point indcated on the chart.
Thanks for the great callout! I had to re-think what I drew, and see if I agreed. I really appreciate the comment.
The area where the solid line is above the dotted line reflects _earlier_ sales, not extra sales. This is also valuable (accelerating revenue has some minor financial benefit, primarily around the reporting period of the revenue and managing cash flow). However, the “extra” sales are really calculated at the tail end of the forecasted sales model.
The idea is that there is a cut-off in potential revenue which is driven by the market’s timing, not the product’s timing. The implicit assumption is that there would be no (material) sales to the right of the graph. The dotted-line function fails to capture all of the available revenue because it “started late” and the amount it failed to capture is the same size and shape as the hashed green area – which can now be captured because of an earlier participation in the market.
Let me know if that doesn’t make sense textually, and I can draw something with better annotation.
My BIG concern is creating SECURE software. Any development methodology that tries to develop software even faster, should be suspect.