This blog entry describes how a solid understanding of Just-In-Time (JIT) can give great insights into the differences between Waterfall and Agile methods.  I want to acknowledge the Poppendieck’s work for giving me the insights I am sharing today. Any failings, are mine, however. I highly recommend their latest Implementing Lean Software Development: From Concept to Cash.  It incorporates not only their earlier Lean Software Development Principles, but also the thoughts of Taichi Ohno and Womack and Jones – two consistent, but different ways of looking at what Lean is. 

Anyway, my thoughts:

Many companies have misunderstood the purpose of JIT.  In manufacturing, a result of JIT is lower inventories.  Low inventories reduce cost and waste for many reasons.  However, this is only a third of the story - and definitely not where to start. 

Just-In-Time requires that processes be somewhat stable and consistent. By stable, I mean systemic errors have been reduced and consistent results are being achieved. Of course, at the start of a Lean initiative, this is very unlikely. The purpose of JIT at this point is to make explicit the problems in the process. Lean tells us to focus on removing systemic problems to improve production.  Some systemic problems that are hidden with high inventory levels are:

1. Unreliable levels of input of raw materials
2. Machines coming on and off line
3. Not knowing which goods to produce

There is a parallel between standard manufacturing and JIT in the same way there is a parallel between Waterfall software process and iterative development.  In Waterfall, we take all of our “raw materials” (requirements) and start processing them in big batches. Resources required by the team (DBAs, analysts, testers) are available at different intervals, so we batch process our work (analysis, design, code, test) to accommodate for this.  We aren’t really sure what to create (customers are always changing their minds, it seems) so we attempt to build all of the requirements initially presented.  This is not unlike a sequence of large machines doing one type of work, each producing huge outputs being held in queues for the following machines. It makes each step most effective, but actually results in lower productivity.  Optimization of sub-processes typically leads to sub-optimization of the whole.

JIT forces us to solve these problems by working on smaller batches.  Lean and queuing theory tells us smaller batches allow for greater efficiency and, as we’ll see, effectiveness as well, due to lower waste. One of the first ways to work on smaller batches is to create a team with all of the resources it needs and have it focus on only one project at a time (and complete stories at a time on that).  This is the foundafftional step of most Agile teams and is often the significant source of improvement of beginning Scrum teams.

JIT has other advantages.  It not only uncovers problems in the process, it also uncovers problems in production.  For example, when inventories are low, errors in production are discovered much sooner because the product being worked on hits the next stage of production much sooner where it will often be detected.  Software developers will manifest savings of this type as well.  If developers can feed testers with the code they have just produced, errors will be detected quicker and the developers will better recall what they just worked on.  Test-Driven-Development (where developers write their own tests) is an extreme case of this – and works even better.  Furthermore, if finished code can be deployed to customers (or at least demonstrated) quickly, we can get feedback from them and know if we are producing things of value.

Thus, JIT provides guidance for software development. One can look at Agile methods as a implementation of JIT principles.  One doesn't do full analysis of a story until just before building it.  Analysis, design, code, test occurs just before it is needed. It should be used to make explicit impediments to our process.  It encourages us to build things in smaller batches.  And, it provides the foundation for quick feedback from the customer.  All good things.

Technorati Tags: Lean Lean-Agile

tag with del.icio.us