Just In Time
(JIT)
This is a reference resource intended to be linked to in order to provide just a little more insight in an easily digestible format. This is not intended to introduce the concept as a standalone article.
This page refers to the Just In Time concept in the workplace of Knowledge Workers.
Just In Time, or JIT, is a Lean concept, originating in the Manufacturing world. It initially referred to an inventory management method in which goods are received from suppliers only as they are needed. This is primarily to reduce inventory holding costs and increase inventory turnover.
This philosophy has since been adopted into many fields with the term 'inventory' referring to both physical entities and conceptual entities such as knowledge. The associated 'inventory costs' are typically inefficient human performance (from too much context switching or simply forgetting the details of a complex thing - Learning-Forgetting curve) or from effort being expended on accruing 'inventory' instead of more beneficial activities.
Just in Time (JIT) Thinking - Planning - Doing
...in Agile Product Development.
This doesn't mean that planning isn't required, and it doesn't suggest leaving things to the last minute. But it does propose identifying those things that require time to understand and those that don't. It's ok to defer making decisions. In fact, the decisions that can wait, should wait. You'll certainly know more in the future than you do now and as such you are likely to make a better decision in the future.
If you have to make decisions today, just be aware of where you are on the Cone of Uncertainty (see below).
Not too late
Deferring decisions and deferring thinking is not the same however. Time to think, to process information and to allow your brain to access memories is vital to improve the levels of creative problem solving. Read more about The Neuroscience of Creativity. Time to think before making decisions is therefore something that should be built into Just In Time processes.
And of course, don't defer thinking such that the actions and activities required after a decision take more time to complete than is available. We consider this further below, in The Cone of Uncertainty section. And of course there are numerous other costs associated with unnecessary delays in decision making.
Not too soon
But equally, having too many things to think about is counter productive. You can consider too much Work in Process (WIP) as having too many things to think about.
A DEEP Product Backlog, effective Product Backlog Management and The Three Amigos are great examples of JIT Planning in agile.
The Product Backlog
Scrum's Product Backlog epitomises this principle. The Product Backlog includes high level descriptions of all the capabilities required in the product, but does not need to have everything in detail. Details are provided "just in time", in the Backlog Preparation activity (Refinement) and the Sprint Planning meeting. But how much time is Just In Time? Well, this will vary based on many factors.
Pull Systems
Scrum and Kanban are both pull scheduling systems, which corresponds to the JIT (Just In Time) inventory management principle. This means that the team chooses when and how much work to commit to, they “pull” work when they are ready, rather than having it “pushed” in from the outside. Just like a printer pulls in the next page only when it is ready to print on it. If you try to push the paper in faster than it can handle, it will jam.
The Cone of Uncertainty and the 'Just In Time' principle
The cone of uncertainty is a graphic depiction of the increasing accuracy that is possible for estimates as the details of a project become more known over time. Dr. Eliyahu Goldratt conceived the Theory of Constraints (TOC) methodology in the early 1980s that postulates that every process has a constraint (bottleneck) and focusing improvement efforts on that constraint is the fastest and most effective path to improved profitability.
Knowledge is the Bottleneck
...thus it's vital to recognise when there is (or may be) critical missing information and to consider when and how this knowledge acquisition can happen. Read More...
We will always know more tomorrow than we do today
Activities and phrases such as Discovery, Ideation and Research are all about acquiring knowledge. Whilst it makes complete sense to prioritise this up front, it's often the case that this is then seen as being the only time when significant learning is required. We discuss this in Setting up for Success.
Where as in fact, there is a constant balancing act throughout projects and product builds between focussing efforts on building things or on learning things.
Spikes and 'Proof of Concepts' (PoCs) exist to create knowledge, to answer a question that provides you with the information that will allow you to proceed with more certainty.
There will be times throughout development when 'Discovery' needs to happen. This is Just In Time thinking.
Just in Time Software Architecture
Henrik Kniberg's diagram summarises the point perfectly. The concept of The Walking Skeleton is a great example of Just In Time, not too early and not too late.
