DevSuccess

I’ve been doing a serious amount of reading on lean software development, a variant of agile that is trying to bring lean manufacturing techniques to the world of software development.  The workflows I’ve tended to see have very much looked like the familiar split phases of requirements->architecture->design->code->test->deploy phases of waterfall.

The difference here is that waterfall wants to follow this workflow for an entire project.  It also wants to put strong walls between each of these phases, describing no interaction between phases other than through heavyweight written documentation.  This results in projects taking months or years, greatly increasing the chances that what is produced in the end is useless to the original stakeholders, even if by some chance the requirements are met.

How does lean solve the problems with waterfall?  These processes tend to reduce the scope of a waterfall workflow to a feature or story level, reducing the lead time from months/years to weeks/days, reducing the risk that the feature being developed will be out of date before it is even released.  In addition, although implementations tend to draw a distinct separation between phases, nothing in lean requires that strict division.  Lean proponents are coming up with schemes like a feature brigade which allow developers to pair between phases, facilitating the direct transfer of knowledge.

What “problems” does lean not attempt to solve?  Agile has tended to react to waterfall by taking everything it specified and reversing it, one of them being the topic of specialization.  Many agile techniques tend to value generalists, but lean doesn’t consider this a problem at all, but an advantage, because certain schedule advantages can be gained by allowing people to specialize in their strengths.  When evaluating processes, we should be careful to properly identify and correct the problem aspects as simply as possible, and not destroy potentially valuable techniques through collateral damage.