Tom Breur
11 August 2013
Clients want their results fast. Preston Smith & Don Reinertsen (1991) make an excellent case for speeding up product development (“Developing Products in Half the Time”) and exactly the same reasoning applies to software development.
In Lean software development, we like the notion of “deciding at the last responsible moment”, to mitigate project risks. Choosing means loosing, because alternative options are left behind. Until you choose, commit to a particular design decision, you can gather valuable information, to resolve uncertainty or ambiguity.
Most of the reasons for driving down cycle time have to do with delivering value earlier, a noble goal. When you release sooner, the effective life of information products gets extended. More value. Earlier. Nicely in line with the Agile manifesto. It sets you apart, gives stakeholders an impression of technical excellence.
But much less obvious is the ‘side effect’ this faster cycle time has. If you know you can deliver quick, then you can afford to start development of a system component a little later (and still be ready “on time”). This lag enables you to learn new, valuable information that might reduce ambiguity.
Any capability (like decreased cycle time) that allows you to postpone decisions, will further your goal of deciding at the “last responsible moment.” And you cannot go wrong on a decision that hasn’t been made, yet.
No comments:
Post a Comment