There’s an obvious but important tension in Lean/Agile development around when to make decisions. Between the fundamental Agile position that we should do the most important and most risky work first, and the Lean argument that we should make decisions at the last possible moment. We need to decide early and try things out, iterate to minimize risk and time to market; but we should put off decisions and avoid iterating to keep costs down.
Later is better than sooner
Lean Development says that in order to avoid waste, we should wait to make decisions as late as possible, especially when we think the stakes may be high. The later that you can make a decision, the more information that you will have on hand to inform your decision, and the more options that you will have to choose from. This means that you should be able to make better quality decisions.
Deferred decision making is built into incremental/iterative planning and management. You don’t try to anticipate everything up front. You don’t try to work out all of the details and dependencies and resourcing at the beginning. Instead, you sketch out an outline of a plan with all of the critical dependencies and milestones that you know about, then focus on what’s in front of you as you move ahead. Detailed decisions about scheduling and implementation and re-prioritization are made when you are ready to do the work, just-in-time.
Deciding later costs less
In Agile Estimating and Planning,Mike Cohn says that
“The best way to reduce the cost of change is to implement a feature as late as possible – effectively when there is no more time for change”.Because you are putting off work until later, there’s less chance that new information will come up and force you to change something that you’ve already decided on. Procrastination pays – or, at least, it saves some time and money.
You don’t want to put a lot of work into something until you know as much as you can about what you need to do, how you need to do it, or even if you really do need to do it. Build a prototype or run a technical spike first, build a first-of and maybe a second-of something and get the customer using it, get feedback and make sure you have a good idea of what you are doing before you do more typing. This is good common sense.
And there is other work that you can put off because you don’t have to worry about it – you have to do it, but you know what you need to do and you know that you can do it. You might as well wait until you have fleshed out more of the system first so that you can get it done quickly.
When should you do decide sooner rather than later?
The kind of work that you can afford to put off safely is mostly obvious. And the kind of work that you can’t put off to later is also obvious, like figuring out the basic architecture, the platforms and languages that you are going to use, the basic approach that you are going to follow, proving out your core ideas. These are decisions that you need to make early on, while there is still time to learn and while there is still time to change your mind and start again if you have to.
That’s why I was surprised by the example that Mike Cohn uses in his book:
“Adding support for internationalization today may take four weeks of effort; adding it in six months may take six weeks. So we should add it now, right? Maybe. Suppose we spend four weeks and do it now. Over the next six months, we may spend an additional three weeks changing the original implementation based on knowledge gained during that six months. In that case, we would have been better off waiting. Or what if we spend four weeks now and later discover that a simpler and faster implementation would have been adequate?”But internationalization is a cross-cutting concern. This kind of work is often much harder to take care of than you want it to be or think it will be, impacting more of the design and code than you expect. Do you really want to wait six months before you find out that you have to change all of the forms and reports that you have developed to handle LTR and RTL languages simultaneously, or properly take care of laying out Japanese and Chinese characters? I’ve spent several weeks working with internationalization experts just trying to understand and solve problems with rendering honorific marks in Arabic names (a small thing, but a deal-killer if you are working with Middle Eastern royalty).
Other cross-cutting concerns may require much more fundamental and more expensive changes to implement later, changes that are hard to get right and hard to test: data validation, security, monitoring and instrumentation, caching, logging, error handling, persistence. Understanding this upfront and supporting it from the start is much less risky and less costly than trying to “add it in later”.
When in doubt, sooner is better than later
Deciding to do something early means that you are probably going to make mistakes and you will have to throw some work away, and you’re going to have to make changes later when you get more information. All of this is waste.
When it comes to planning out details, putting off decisions to just-in-time makes sense. But when it comes to designing and implementing important parts of the system, especially technical plumbing and cross-cutting work, doing something sooner is almost always better than later. Managing risk upfront will save you more money in the end.
"Deciding to do something early means that you are probably going to make mistakes and you will have to throw some work away, and you’re going to have to make changes later when you get more information. All of this is waste."
ReplyDeleteDeciding to do something later means that you are still going to make mistakes. And when you do, you will be under a tighter deadline to fix them ad verify the fixes - leading to either more mistakes, or delays in the release.
@Joe, good point. By putting off a decision, you have less time to recover if you still make a mistake. I hadn't made this explicit, thanks for bringing it up.
ReplyDeleteHi Yves
ReplyDeleteNice post.
An important distinction to make is that it is only better to defer commitments IF THERE IS UNCERTAINTY.
When there is no uncertainty, you should build the thing as soon as possible. That allows you to more easily defer those items where there is uncertainty. If you know you need to build it and you know how you need to build it, get on with it. This will also remove uncertainty over how much effort you have remaining to build the other bits.
As to the ordering of building things. You should build stuff you know you need to build first, UNLESS there is uncertainty that you need to resolve by building something else. This is the essence of Deliberate Discovery by Liz Keogh and Dan North. Deliberate Discovery guides us to resolve uncertainty... which is effective risk management.
Chris
I agree more with Joe than Chris here:
ReplyDeleteIf there is uncertainty about the details of feature you should build a minimal version of the feature early. Uncertainty is reduced by hands on experience, not by more planning. The only thing you achieve by waiting is a situation where the customer is forced to accept a suboptimal solution since there is no time left to create a better one.
Another thing i find strange is that people always say you should start with the most difficult problems. If the team is new and the problem domain is also new wouldn't it be better to start with slightly easier tasks?
Niklas
DeleteI did not say anything about difficulty. I said that uncertainty should be used to prioritise. As you say, "Hands On" is where we encounter the real issues.
When the customer is uncertain as to what they want, you may want to resolve that uncertainty by doing something small, rather than committing a huge amount of effort on something uncertain.
I suspect we are saying the same thing rather than disagreeing.
Chris
Mr. Cohn does not understand Internationalization. And what he describes in the quote is a complete false question. Internationalization is.one of these things you want to do ASAP as there are often technical and other risks hidden in how we implement that functionality. Many practices have been.developed in the agile community to be able to tackle internationalization *without* having to spend any extra time or money.
ReplyDeletecoming back to the issue in the post, Chris's point about uncertainty is a very good indicator.of when you should delay a decision. In fact it may be the best single indicator.
Jim
ReplyDeleteSorry. I thought the post was by Yves.
Nice post anyway. :-)
Chris
Lovely conversation.
ReplyDeleteI think that part of the confusion comes from what does it mean to "delay decision".
Your title talks about minimize waste but your example is about delay decisions.
For me delay decisions in lean does not mean do nothing. For me it actually means Set based design.
With set based design, you implement multiple solutions and you select later which one is the best.
And that could seen as waste by some people, but it's not, it gives most value.
I agree that this is an interesting conversation (except for the fact that some of us got the author wrong, sorry Jim...).
ReplyDeleteA lot of the confusion seems to arise from us putting different meaning into the words we use. That is probably the case for a lot of people reading about these ideas to. Can we expect them to gain new insights when they risk misunderstanding the message in fundamental ways?
The problem with advice like "delay decisions" it that it applies in some contexts but not others.