my series about the 7
key principles of lean software development
, here are my comments
on Lean Principle #4 - Defer Commitment
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.
critical decisions for the latest point they can be made without
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.
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
In areas of complexity or uncertainty,
where things are very likely to change, this is especially important.
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
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
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.
try (within reason) to architect your solution so that fewer
commitments are irreversible. And defer commitment on irreversible
decisions to the latest point possible.