When will it be ready?

Whether you are in IT or else, director or manager, the perpetual question is the same : when will I be able to benefit from the work I asked for?

Imagine any life situation : knowing the answer is not a luxury, it will often influence your decision and actions in regard to this deadline. What would you say if your contractor answered you that your bathroom would be ready when it would be ready? Or if the waiter in a restaurant candidly answered that you would be served in about two hours, if there were no emergencies? Or else, if you were being told that the haircut you asked for corresponded to 13 complexity points and should be in the next sprint, if nothing changed and the team decided to put it in the backlog?

You see me coming, it’s obvious : the person asking the question is expecting a clear answer, expressed in a unit of time that is familiar to her, and that we respect that commitment. The complexity of the world has changed, our work becomes less predictable, but the expectations stay the same : predict the end date of the development.

Related post : Getting rid of the 3 Ms or how Agile tackles the problem of Muda, Mura, and Muri?

With the advent of Agility, empiricism is recommended to maximize value. By working on reduced parts of the elements with high added value for the clients, we make sure to maximize the potential return on investment (or minimize potential losses). The nature of the work to be done and the details of the solution not being known in advance, it’s impossible to promise with certainty when something precise will be ready.

So how answer this timeless expectation to know when something will be finished without compromising the bases of Agility?

Inspired by the Lean philosophy, the Kanban method relies on Little’s law, the theory of constraints and the Queueing theory. In short, the Kanban approach states that for optimizing the execution of an activity chain (work process), it’s necessary to limit the size of the queues between steps. The best way to limit it is to make explicit the maximum number of items in progress in a process and not to accept new items as long as there is no capacity to deliver those already in progress.

A simple representation of this principle is a road bridge. During rush hour, more cars try to get on the bridge than the exit capacity, consequently creating a traffic jam (representation of Little’s law). Furthermore, if the cars are moving at 50 km/h rather than 100 km/h on an exit lane of the bridge (because of potholes for example), the capacity of the bridge is being limited by the traffic’s weakest link (representation of the theory of constraints).

Yes, more cars are ultimately going to pass, but the time taken by each car to cross the bridge is proportional to the number of cars trying to pass at the same time. Transposed in the professional world, the more work items we have in progress, the more it takes time to finish each of them.

The Kanban process is a soft way to bring a continuous improvement reflex in organizations. Its founding principles are following two axes : change management and service delivery.

Change management :

• Start from where you’re at;
• Practice continuous improvement by evolutive change;
• Encourage the leadership’s actions on all levels, from the individual to the management.

Service delivery :

• Understand and focus on the needs and expectations of the clients;
• Manage the work process and let people self-organize around it;
• Reflect frequently on the efficiency of the organizational rules and on how to improve them.

There is no miracle formula, but the implementation of a Kanban often goes through five important steps :

1. Visualize the workflow

Making the current work process visible and examining it is an unavoidable starting point. It’s recommended to do it with the team, with the people who are part of the targeted process, to address the three principles of change management.

2. Limit the “in progress”

An essential element that is a guarantee of success (or in its absence, of failure) for a Kanban initiative is the explicit limitation of the items in progress in the system. The definition, the follow-up, the respect and the continuous improvement of this aspect will allow the team to make the process more fluid and optimize the efficiency of the work.

3. Make the rules explicit

A Kanban (visual representation of a work process) often comes with a set of operating rules. It’s recommended to make them explicit in order to support the process. Examples of rules often included are, on the one hand, the definition of how an element enters the process (Who prioritizes? Which entry conditions need to be included?) and on the other hand, the definition of the exit criteria (ex. Definition of done in Scrum).

4. Measure the flow

The Kanban process recommends bringing improvements based on the basic measurements of the flow, like the cycle time, the amount of “in progress” items and the exit capability of the system. The operationalization of a Kanban involves the systematic gathering and usage of this data by the production team. Often, after a certain operating time, the team has a history that allows to answer the “When will it be ready?” question more precisely.

5. Continuously improve

Whether your Kanban is efficient the first time (lucky!) or to be revised often, you need to implement a continuous improvement mechanism. It will be important to continuously follow the performance of your Kanban system, to adjust its settings (steps of the process, limits of work in progress, explicit rules) and measure the result. Whether it’s in the form of a retrospective, a kata (Lean Toyota) or another materialization of Deming’s PDCA cycle, engagement toward systematic improvement of the process is what will allow the Kanban to evolve with the reality of the work.

Traditionally seen from the point of view of operations (repetitive process, more predictable so easier standardize and measure), the Kanban process can apply as much on the level of the development of the new product. In theory, any work process could lead to a Kanban system. If it’s true that your team is working on dozens of projects at the same time, that it often stops what it’s doing to do something “more urgent”, that the work priority is closely linked to who is yelling the most and that team members feel exhausted, there are chances the Kanban process could bring you benefits on all levels.