Tradeoffs: Giving up Certainty
What is it that stops companies from really making the expected increases in cycle time and delivery speed that Agile promises? We examine a trade-offs model that helps explain what it is that companies find so hard to give up – what we’ll call the illusion of certainty – and what can help us pick the right trade-offs.
The Trade-off Model of Software Development
The necessity of trade-offs
Athletes optimise their physiques for different outcomes.
If you stand Michael Johnson next to Mo Farah, you will notice how different their body-shapes are. Johnson, an Olympic sprinter, has powerful muscles optimised for speed. Farah, an Olympic distance runner, has a long, lean body optimised for endurance. Both athletes need to make trade-offs. Farah needs to run for 10,000m and still make an explosive finish. Johnson must not develop his muscles too heavily or he will compromise his speed. Much of an athlete’s training routine is about fine-tuning those trade-offs.
Similarly, businesses use different methods of delivery depending on the goal for which they are optimising. Some businesses need to deliver software at enormous speed (sprinting). Others have to focus on throughput and are looking to balance time against cost (more of a long-distance race). The choices they make (their training regime, if you like) will be different.
Businesses could learn two very important lessons from runners.
Don’t confuse the goal with the method.
Sprinters have heavier muscles, but the relationship is not a simple linear one. Sprinters don’t go on getting faster and faster the more muscle weight they pack on. A body-builder is unlikely to be a good sprinter, for example.If you think we’re exaggerating and that no company really behaves in such a simplistic manner, consider how often companies decide to ‘do Agile’. Instead of asking what the real business objective is – faster delivery, for example – the methodology becomes the focus, often leading to disappointing results.
Understand and accept trade-offs
Sprinters are hopeless at long-distance running.
That’s not to say Usain Bolt couldn’t beat the writers of this paper at any distance you care to name – we’re fairly certain he could. But he wouldn’t beat Mo Farah.Companies who embrace one goal, may have to give up another. They can find this so painful that they refuse to do it. But of course, if they refuse to make the trade-off, then they should not be surprised to find that they don’t achieve the desired goal.
The Faster Delivery Model
This model has been developed by Emergn to examine four different flow choices for software development. The choice – just like for the athletes – depends on the goal. Our choice will dictate the kinds of tools we need to use.
Before we go on to explore it, here’s a quick health warning. This model is just that, a model, it’s not an exact depiction of the world and there are no rigid divisions between each flow choice.
The extreme top left: where extra cost leads to no appreciable gains
If our company wants to get an individual from A to B, a Ferrari will get her there fast and cost quite a lot of money. Buying three Ferraris will not get her there any faster, they will simply cost three times as much. Hiring a private jet may make a portion of travel faster, but the time spent organising a take-off and landing slot may mean there is no appreciable increase in end-to-end speed.
The extreme right: where extra time means costs begin to creep up
In trying to get our friend from A to B, our company wants to know exactly how much it will cost and how we can guarantee getting her there on time. This is not dissimilar to the way most of us act when trying to catch an airplane. We build in a large buffer of time, and we think carefully about which route is least likely to suffer from hold-ups or changes – the special train, or a taxi? Our concern with this means that not only may we spend quite a lot of money on getting there, but we will waste our own time – which has an associated cost.
What happens as cycle time decreases?
As a company travels from the far right towards the left of the graph it typically sees improvements in every area: as cycle time decreases, cost stays low for a long time, while shorter cycle times improve flexibility. At this point trade-offs are not really needed at all. But past a certain point choosing on which benefit to focus becomes more important.
This is rather like a couch potato going to the gym. At the beginning everything is going to get better – they will lose weight, get fitter, become more flexible, increase in strength… but after a while, they will need to make choices based on what they want. Are they interested in being slim? In that case lots of cardiovascular work and a limited amount of toning weights exercises will be better. Are they keen to excel at a certain sport? That will require a tailored fitness plan depending on the sport. Do they want to improve a sense of wellbeing? Yoga and Pilates might prove more effective than boxing.
The really tricky trade-offs, like those faced by major athletes, are quite a while in coming. But they do exist – and it helps companies enormously if they know the benefit they most desire at the beginning of the process. It means they can adopt tools and practices specifically for that outcome. If a company is single-mindedly focused on throughput, for example, then using an extreme form of concurrent engineering may drive costs up beyond what is acceptable.
Most companies sit towards the right of the model
Emergn’s experience is that the majority of organisations sit in the right hand area of the graph. Although these companies focus on cost control, their lack of speed often results in larger overall direct costs. They also suffer a cost of opportunity, which is rarely measured at all.
Many companies are tempted by the idea of reducing cycle time and try out the Agile methods that promise this. Yet a large proportion of such implementations fail. Why? It’s not as if board members are slamming their fists on the table and declaring, ‘we need to go slower and raise our costs!’
The reason, we suggest, is that there is an invisible weight most companies carry as they try to increase speed; an anchor to the right hand side of the model which they think is terribly important – certainty.
When we use phrases like ‘set in stone’, ‘drop dead date’ and ‘deadline’, we are signalling how rigid our approach to time is. We are judged by the schedule, with a key metric of ‘on time’ delivery. To be sure of achieving this, we build enormous buffers into our plans.
Strictly speaking, the only real deadline ought to be a certain launch window, based on a customer need – Christmas products needed in December, exam results which must be delivered in August, etc. Because the value of the product will go to zero if late, the company needs to build in plenty of buffers to ensure that they can hit it.
In software, however, the deadline is often an internal construct around which we then build dependencies. Once we have built in buffers, we tend to use them. Rather than delivering early, we stuff the schedule with low-value activities or we expend lots of time up-front creating the plan to meet the deadline.
Although we’ve added some padding, we haven’t dealt with ALL uncertainty. Most plans ignore the possibility of big disasters (like financial crises or tsunamis), and even of quite likely events (competitors coming out with a better product). Either they include an arbitrary risk buffer, or they attempt to analyse every possible risk and come up with a contingency plan for each. In the first case the buffer is meaningless, in the second so long is spent planning that by the time it is finished the plan is redundant.
Uncertainty is at the heart of IT. It is a creative, knowledge-based discipline in which problems are continually changing and where most tasks are non-repetitive. Companies ignore this at their peril. Instead of attempting to control the uncontrollable, organisations would do far better to focus on becoming faster and more flexible – which enables the to deal with uncertainty, not remove it.
Three Choices for IT delivery
A lot of companies are very interested in maximising their throughput, producing as much as possible for as low a cost as possible. Let’s be clear, maximising productivity is not the same as focusing on hitting the budget. Certainty of cost is as great a temptation as certainty of time. Plenty of IT departments are measured on whether they were ‘within budget’ rather than how valuable their work has proved. Among the many unintended consequences of such a misguided measurement is to ensure developers spend more effort on estimating than they do on coding.
Being productive is not the same as being prolific. If our developers crank out 1,000 lines of code a day, managers might be delighted! But if this code turns out full of bugs or not what the customer wanted – then it’s a waste of time and money.
In throughput, there are two key dangers. The first is that we build something perfectly but then discover the market doesn’t want it. The second is that we build something wrongly and have to redo it. In both cases the reason for our failure is that we haven’t received feedback sufficiently swiftly to be able to incorporate it.
When to choose throughput
If we wish to maximise the amount of work that we can do for a given amount of money (which can also be thought of as equivalent to a low per unit cost) then we need to know two things:
- what the customer wants
- how to build it.
Preferably we also want very low variation within the work itself as well (tasks of a standard length, difficulty and value).
These conditions are not usual in software development, which means a focus on optimum productivity against cost is rarely the solution. On the other hand if you have done something before and really do have solid feedback, then throughput may be the most responsible and profitable way to manage your flow.
There’s a clue in the name: Agile methodologies focus on a flow choice that emphasises flexibility or the ability to embrace change. The Agile Manifesto insists that we should ‘welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.’ Flexibility works by setting things up to keep choices open. This involves making decisions at ‘the last responsible minute’. The advantage is that you can easily take new information or a changed environment into account; the disadvantage is that things remain uncertain for longer. It also comes at a cost.
Advocates of flexibility point out that it often turns out to be cheaper in the long run to keep options open because early decisions are more likely to be wrong. Flexibility encourages a fast feedback loop and this should quickly cut short development in the wrong direction – such savings can offset a great deal of the cost associated with creating increased flexibility.
When to choose flexibility
It is not easy to decide where flexibility is essential and where it contributes little value – especially on subjective matters. Are last-minute changes to a web design ill-considered interference, or do they represent an essential attention to detail? We must identify where we need flexibility and innovation and where changes are likely to be unimportant for overall value. Some markets, products and elements within a product change faster than others – the UI may change frequently, for example, while the architecture that supports it remains the same. Discussing the matter up front allows us to assign a cost to change and thus to know the impact of each decision as the project progresses.
All out speed
On the far left of the graph, companies are prepared to pay high costs in order to achieve very fast cycle times. Think of an ambulance racing through the streets, ignoring traffic jams and red lights. It focuses on one thing only – getting its patient to hospital. It ignores anything off the critical path – it doesn’t stop to fill up with fuel. Nor is it concerned with economic efficiency – ambulances don’t stop to pick up a second patient en route.
In software all out speed is sometimes known as an ‘expedite request’. While having lots of extra capacity might seem like one likely expense, it is not the only one. Often projects will require concurrent engineering with solutions being worked on in parallel – depending upon the project, this can prove very expensive. Slack has to be built into the system in general to facilitate one-piece flow and ensure there are no queues, severely reducing productivity, and other projects will suffer a knock-on delay.
When to use all-out speed
While occasionally all out speed is justified by an opportunity – needing to leapfrog a competitor’s launch, for example – more often it is in response to a threat or an emergency that may already be costing the company money. Severe production defects can cause a crisis for the company’s reputation and therefore require an immediate, costly fix. Because the value or the threat is so high, time becomes the only crucial factor to which all other considerations are secondary.
Giving up certainty does not mean giving up predictability. Instead of invisible buffers hiding the progress of the project, we can see the true flow of work. By delivering in parts using small batches, the project’s progress should be clearer and the data predicting delivery dates is more robust.
Athletes continue to break records because we have become more scientific in our approach to sport. They fine-tune their performance, changing elements in diet and training and meticulously testing the results. Companies who have sped up delivery tend to use a hybrid of differing methodologies that they have developed through trial and error. They have examined the difficult trade-offs to be made, and tested possible answers until they come up with what works for their unique situation. Will I sacrifice flexibility for efficiency? Can I decouple the processes? What will persuade marketing to agree to my new uncertain schedule and just in time decision-making?
No article can tell you what trade-offs you ought to be making, because only your own organization can answer such questions. But we wish you good luck in the race...
About the Author
Paul Dolman-Darrall is an IT director known for developing people and successfully leading large global teams across various change programs for some of the largest companies in the world and contributed to strategy of government. At Emergn, in his role of Executive Vice President, he has helped launch Value, Flow, Quality (VFQ) Education, a work-based learning program to help practitioners achieve immediate business results through the application of skills in practice. The program is designed to help IT departments and business leaders who rely on technology to put in place smarter, more effective work practices to facilitate change, generate significate return on investment and inspire innovation in practice.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015