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:

• Capture requirements
• Write specifications/plans
• Develop solution according to specifications/plans
• Test
• Deploy to users
• Revise

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.

• Divide things into reasonable time units (e.g. quarters of the year)
• Get the right people involved in the planning (stakeholders, team members, people managing constraints such as security, standards and resources)
• Identify real deadlines (not ones made up for progress management)
• Do 1 or 2 levels of breakdown from top level work items to second level work items. These are about what we need to achieve, not how we do it
• Identify any obvious dependencies and risks
• Review it regularly (at least monthly if you are planning in quarters) based on new information received)
• This plan is a high level backlog - just a different way of looking at the same information

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:

• Reviewing the backlog - look at work on the backlog. Add new (possible) work, remove unnecessary items, decide which need to be refined. Prioritise any refinement so we only refine Just In Time. There is no value in spending effort on refining work we will not deliver, but sometimes we cannot decide whether we will deliver it until we have put work into refinement activities
• Refinement - choose the work we will have to deliver in the near future and work out the details. This may include: breaking it down to smaller pieces of work, capturing extra requirements, specifying parts of how it will be delivered (and making associated decisions) and assigning someone to take it forward. Every piece of work should be assigned to someone who is responsible for it progressing (which is not the same as doing it themselves) to avoid work getting missed or dropping out of the process
• Prioritisation, effort and Commitment - once work is sufficiently refined to ensure we have enough data (and not before) we can set priorities and estimate effort. This cannot be done until we have enough data. When we have the prioritisation and effort agreed and in place, we can make a commitment to doing the work. With JIT planning we probably only commit to a couple of weeks ahead, but we will have more than that to choose from so we can work more efficiently
• Hypothetical commitment - assigning work to some time in the future (e.g. future sprints). This is not a commitment, but signals an intention based on current information. It is a “best guess” but subject to revision and refinement
• Sharing and feedback - these decisions and commitments should be visible to everyone. This does not mean they can change them, but ensures the work is visible and people can question them (through appropriate channels) if they have issues with them. A team should be proactive in ensuring that any impacted parties are aware of these things and can provide feedback (though that does not mean taking action on the feedback, just accepting and evaluating it)

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:

• Control the channels through which unplanned work arrives. Random requests to anyone on the team is not acceptable. We must capture and manage requests like all other work
• Set up mechanisms to triage new work - with appropriate response times and feedback to the person requesting this
• Triage all requests - decide whether we handle them, delegate them or ignore them. If we will handle them then we need to estimate the impact, effort and priority
• Bring accepted, unplanned work into the plan. We cannot predict the work asked for, but (with experience) we can estimate how much of our effort needs to be expended upon it - so we might go 80% planned and 20% unplanned, for example

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:

• Committing to work and completing it by the team who are tasked to create the solution (including in-team testing)
• Testing and approving a solution for release - including user acceptance and other testing outside the development team
• Deploying a solution to the end users

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:

• Will I get the solution delivered when I expect it?
• If not, why? Is there something I can do to get back on track? How urgent is that?

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}}