A Reflection on Just-In-Time (JIT)

April 9, 2008 — Posted by Al Shalloway

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 foundational 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.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Comments

Alan, great interpretation. In addition, I found that reading Toyota Production System, helped me develop an intuitive understanding for why the Agile methods work. Often a lot of agile literature is about the practices, and not always about the context under which they are valid.

Along these lines, I found reading Eli Goldratt's "The Goal" & "Theory of constraints" helped me gain a good understanding of why agile principles like swarming and minimizing hand-offs, is effective.

Curious to read your thoughts on that ...

We had an interview with professor Monden who is the author of Toyota Production System. He lives in Tokyo where I live now. He currently is a professor of Mejiro University still working on Toyota Production System.
Please take a look at this interview.
http://www.lean-manufacturing-japan.com/interviews/toyota_production_sys...

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban