Agile Coach Online

Expert support on demand

Agile Coach Online Logo

Just In Time thinking

Just in Time (JIT) thinking is one of the biggest contrasts between traditional waterfall approaches and Agile. Grasping and embracing this is very important because this is where we get many of the advantages of agile working. It is also one of the most difficult things for people to truly engage with - especially in large organisations. Get this right and most of the rest follows.

Traditional waterfall processes are sequential:

There are inherent problems in this approach because it assumes we have all knowledge necessary at all stages, and that we can clearly communicate it. This makes flexible, appropriate and efficient delivery of the right solution harder. It is also pretty much impossible to do in practice except for the simplest cases. It originates from a time when computers were expensive and ‘people time’ was cheap - so you wanted to do as much as possible before you even went near a computer. The world has changed a lot since then.

Agile still allows us to do all the same things (it would not be much of an approach otherwise, since all the above are essentials). However, it does not assume we can do them all in sequence because it does not assume we have perfect knowledge. An agile approach lets us be much more responsive to change, more innovative, and more efficient (among other things). The steps above (and others) cease to be monolithic blocks and become activities which are spread across the entire development cycle in the most effective way.

Key to use this is using the best information we have for any decision, which means we do not fantasise that we can see the future but instead adapt and improve our work as it progresses.

This is where Just In Time thinking comes in.

A note: Just in Time working has origins in the 1960’s and is core to many successful manufacturing processes - notably in the car industry where it caused a working revolution. It has a long and successful history of effectiveness. It was not invented for agile but is a core part of being agile.

What is JIT?

Just in Time is not “doing things at the last minute”. It is “doing things at the last sensible time”. That is very different. Doing things (including making decisions) at the last sensible time means we are working with the latest information so we can make the best informed decisions. It also means we can be more responsive to the actual needs of our audiences.

Just in Time is not incompatible with planning ahead - it encourages planning ahead focused on the areas where planning ahead is necessary, which makes things clearer and simpler. For example, absolute deadlines and timescales, resource allocation and management of risks and dependencies are all areas where we need to think and plan ahead. These are cases where “the last sensible time” can be quite a lot earlier than the deadline etc. For example, if we have to meet a regulatory requirement in 12 months time, or deliver a product in 8 months, then that is perfectly acceptable. We can plan several years ahead and still work in JIT and Agile ways.

There is another essential aspect of JIT to understand - granularity (level of detail). We might think a long way ahead for some things, but not for details. With JIT we fill in the details just as we need them and at the last sensible moment. This enables us to deliver better solutions more efficiently.

{{pic - time vs. detail}}

{{Give an example}}

JIT and planning

“The last sensible time” means allowing plenty of time to deliver a solution (including managing uncertainties and contingencies). We need to look ahead and work out what are the real deadlines and deliverables we must achieve. Do not confuse this with the deadlines/deliverables from traditional approaches which are a management technique to handle work packages and progress in traditional models - that is a different thing that we no longer find valuable or necessary. The role they served is handled in a different way.

There are different levels with different planning horizons/timelines and different (to some extent) people involved in each level of planning.

{{Highest to lowest - link to hierarchies of work (not org)}} {{2d diagram}}

High level

High level planning is essential in any organisation of a reasonable size. This is not incompatible with JIT or Agile thinking. The main difference is that we do not plan a long way ahead and in detail. We can plan a long way ahead, or in detail, but not both - we do not have enough real data to do both at once.

Planning long-term (such as 1-2 years) is a reasonable expectation at the highest levels.

These are just the highlights of this planning level. Find out more {{here}}.

Detail level

Planning in detail for delivery is a different thing, with different objectives, participants and timescales. Because there is more detail, the timelines from planning to delivery are much shorter. This enables us to be much more responsive to what we have learnt from developing the solution so far and from feedback from our users and stakeholders.

Planning at this level normally spans a period from 1-4 weeks. Typically it involves:

Not all work can be planned. See the information on unplanned work {{link}}.

What we mean by ‘delivered’ work depends on our perspective {{link}}.

Find out more about {{JIT and Agile Planning - add link}} here.

JIT and solution delivery

Solution delivery and detail planning are closely related. Team level backlogs become very important here.

As described above, the high level plan of work will be broken down into levels of detail as becomes needed or relevant for the shorter term, detailed plans. The team(s) who will deliver the solution will do this. The result of this is a backlog of work items for each team. These items relate to the plan, but are not a simple representation of it. They may include work items such as research to do, alternative approaches, experiments and hypotheses which facilitate delivering the best solution in the best way. Many of these activities may not turn into actual deliverable work, but they ensure we deliver the best solutions.

Breaking down the plan to the appropriate level of detail puts things on the backlog, but that is not a commitment to deliver them. It indicats that we will think about and explore them.

Things on the backlog need work to refine them and get them ready to develop and deliver. This is also a Just in Time process. {{}}

Find out more about {{JIT and Agile backlogs}} here.

Unplanned work

Expect the unexpected. OK, that is glib and unhelpful.

The point is that most agile teams do not work (entirely) in a project-based and plan driven manner. If we embrace agile then a team works through the entire life-cycle of their product from conception to retirement.

Some of the work is unplanned. This includes support activities, fixing issues (and maybe feature improvements, depending on how you organise work). These can appear at any time from a variety of sources.

Work like this is very much a Just in Time thing. We capture them as requests for work.

In all cases we must:

What does delivery mean?

In the perfect agile world, delivery means the users of the solution are using it.

That is rarely the case in reality, and it is counter-productive to use this definition because it inhibits understanding how we work and how we deliver effective solutions. It is much more helpful to break the idea down a bit further (especially in large organisations).

Given the typical workflows of large organisations, we can (and should) distinguish:

Value is added by separating these things. It helps is understand what out users need and where there are issues and bottlenecks in the process.

JIT and progress tracking

Progress tracking is a measure of what has been achieved compared to the plan. It is an error to try to track progress in all detail at all levels. Each audience is interested in different levels and needs different information. JIT means tracking just what we need to know and not confusing or over-complicating the situation with anything else.

At the highest level the questions are simple:

That is all that we really need to know at this level. With Agile, we do not need to know all the details - teams working on the details will let us know if there are impediments to progress that they cannot handle. Do not be tempted to try and micro-manage. Trust the teams {{link}} to tell you if something needs to be fixed. They will let you know at the earliest relevant time - that is where JIT progress tracking comes in.

Expect to get updates frequently. This is not about getting reports from intermediate ‘middle managers’ with their interpretation of things. Live updates via dashboards based on actual data are where we aim to be with agile, but they should only contain the detail needed for JIT updating and intervention. Doing this well requires educating senior management teams about interpreting this data and separating information from requests for action.

At the detailed level we use very short timelines (typically weeks). We monitor planned vs. delivered work, identify any issues that inhibit or prevent progress, look at any changes to the effort we need to expend or the resources available to deliver as we expect. Much of the time we can adjust priorities and resources to deal with this - a very responsive and efficient process. There are occasions when we cannot resolve things at this level. If that happens, we need to identify the issue, the relevant information and the impacted stakeholders. Then we raise this to the next level of management as something we cannot deal with. This is the basis of another key agile idea in organisations - Management by Exception {{link}}

Tell me more

{{To do - links to more MEC details and other resources}}