Lean Principles #4 - Defer Commitment
by Kelly Waters
Continuing with my series about the 7 key principles of lean software development, here are my comments on Lean Principle #4 - Defer Commitment.
I'm not sure I really like the name of this one. It could easily be misunderstood. It doesn't mean you should put off committing to anything indefinitely, or defer all decisions - that would obviously be a very bad idea.
What it does mean, is decide as late as possible, particularly for decisions that are irreversible, or at least will be impractical to reverse.
Timebox critical decisions for the latest point they can be made without causing problems.
Obviously it is also important not too leave decisions too late. This can delay the team and make projects difficult. But, the later you can safely leave critical decisions, the more information you will have available to make the right decision when the time comes.
Deferring irreversible decisions means you keep your options open for as long as possible. By the time the decision needs to be made, there is every chance that you will know more about which of those options is the best route to take. It also gives you time to potentially explore the different options in more depth and experiment, helping to come to the right conclusion.
In areas of complexity or uncertainty, where things are very likely to change, this is especially important.
In areas like this, as well as deciding as late as possible, you should also try to architect your solution to be flexible, in order to make fewer decisions impractical to reverse.
Another example of deciding as late as possible in agile development methods is Sprint Planning, or iteration planning. In agile, you decide what features to include in each iteration and analyse them just in time for them to be developed.
Another example of deciding as late as possible in agile development methods is Sprint Planning, or iteration planning. In agile, you decide what features to include in each iteration and analyse them just in time for them to be developed.
Keeping decisions about features and the development of those features close together helps to ensure that the right product is delivered, because it leaves less room for change.
In more traditional project management methods, in between the specification and any particular features being developed, there is a much longer period of time when change can occur. Changes in requirements, changes to the underlying system, changes in technologies, changes in people (either the product owner or the development team), changes in direction, or of course changes in the market.
Deciding too early, you run the very likely risk that something significant will have changed, meaning your end product might meet the spec, but it might still be the wrong product! This is one reason why so many projects fail.
So, try (within reason) to architect your solution so that fewer commitments are irreversible. And defer commitment on irreversible decisions to the latest point possible.
Kelly.
Photo by ryanrocketship
0 comments:
Post a Comment