Lean Principles #4 - Defer Commitment
by
Join the DZone community and get the full member experience.
Join For Free
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.
Lean (proof assistant)
Published at DZone with permission of Kelly Waters, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Cucumber Selenium Tutorial: A Comprehensive Guide With Examples and Best Practices
-
5 Key Concepts for MQTT Broker in Sparkplug Specification
-
Getting Started With the YugabyteDB Managed REST API
-
10 Traits That Separate the Best Devs From the Crowd
Comments