The Kanban, key tool of Just A Time, has been adapted for use as a project management tool.
Kanban is the tool of the Agility the least normative. He is very open and the only ones « constraints » are the visualization of the work and the limit of the WIP. Much less binding than the dozens of rules of the method RUP and a little less than the SCRUM which requires among other things, the establishment of multidisciplinary team, 3 roles (Product Owner, Master SCRUM, SCRUM Team), the obligation of iterations…
Step 1 – Divide the work cycle
The first step is to create a standard for progressing actions. We can choose the steps Design, Test, Validation … Nevertheless, Most of the time, we will find thecycle PDCA :
- Plan – To do : List of actions to perform.
- Do – Ongoing : All the tasks we are doing.
- Check – To check : A set of completed tasks that we are monitoring and verifying.
- Act – Finished : Tasks that are OK and that we have delivered to the client.
It will be necessary to detail the criteria to go from one step to another :
- Plan : The purpose of the task and the acceptance criteria are clear.
- Do : The action is correctly performed and we are 90% sure that it will be validated.
- Check : Our internal tests are OK and the client has validated.
- Act : The elements are delivered and integrated to the rest of the project.
Step 2 – Set up the WIP limit
In the same way as for a Kanban « traditional », this one will use the principle of pulled flow. The adaptation of this principle to project management, sees the implementation of a task limit in each phase of development.
- The SCRUM method limits the amount outstanding to the SPRINT as a whole, since we ask to realize a certain number of Story Points during the SPRINT.
- The Kanban method limits the amount of work in progress in the Workflow, thus indicating that we can not move all at once, but progressively advance.
Note that this limit applies to the User Story and not to the number of tasks that result from the User Story (Story point). Moreover, only the last stage has no WIP.
Using WIP only makes sense if we have consistent User Story sizes. Indeed, if we put a limit to 3 User Story in C but that we have 2 with a size of 1 and 1 of a size of 100, we risk to have a strong variability in our process and we lose the interest of its use. To avoid this, we can :
- redraw the largest User Story into several User Story.
- set WIP limit in terms of Story Point and not User Story.
What is the good WIP ?
There is no rule defining the good value of the WIP. Everything is a matter of adjustment. Some examples :
What to do ?
Do : 1
Check : 1
The work is progressing very fast and the kanban card passes quickly into the check phase. But the Check phase is longer. So, the teams in charge of Do wait until the Check card goes to Act.
Increase the WIP of the Check phase or put more staff to carry out the Check and thus get closer to the system One Piece Flow.
Do : 8
Check : 2
The Check phase can not be done because the control equipment has failed. The teams of the Do phase advance until they have 8 Kanban completed that they can not transmit. They then react to help repair the equipment.
We could then reduce the WIP of the Do phase. This could have allowed us to solve the problem sooner so is getting a better overall lead time.
Step 3 – Put the cards
Then, we will put the Kanban on the board (It is expected a space of about 1m high and 2m long on a wall). Initially, all our cards will be in the Plan phase, the number being equal to the WIP limit we have set for the moment.
As the project progresses, the Kanban will advance on the board. To know which is the next kanban to treat, we will therefore define rules of operation. here are some examples :
- Use the principle of FIFO first in, first out, based on the dates on the cards.
- Take a Story related to a new feature rather than the one related to maintenance.
- Story having the biggest size first.
Step 4 – Measure the Cycle Time
For each User Story, we will determine the average Lead Time which represents the delay that it put between its entry in the Plan phase and its exit from the Act phase. This indicator is directly related to Velocity :
- The cycle lead represents the average time to complete a task.
- Velocity is the number of tasks per unit of time
- In other words, if our cycle time is 3 days, our velocity for 2 weeks of work (10 days) will be 3.33. Conversely, if a team has a velocity of 15 tasks in 10 days, our cycle time will be 0.66.
The challenge is to calculate an average time of realization predictable and commit ourselves to delivery times.
It is recommended to recalculate the average cycle time each time a card finishes the Act phase. This makes it possible to have the most up to date data possible and to improve our responsiveness in case of problems.
Step 5 – Iterate to improve
The heart of Kanban is to continually improve. At various times we will perform iterations to improve our processes. This phase is not structured in the same way as the SCRUM method, but is however widely included in the philosophy.
Several ways are possible to improve the process :
- Reduce Cycle Time : we can study the average time of completion and analyze why some have been longer than others.
- Identify bottlenecks : It is possible that several times during the project, phase DO is full while CHECK phase is empty for example. The Do phase is our bottleneck, which prevents us from making work more fluid.
At a minimum, the Kanban card must contain the following elements :
Date of entry into the Plan phase
Release date of the Act phase
A short description of the User Story and the associated tasks so the size of it.
The Kanban manager for the phase in question. Indeed, it is possible that the person for the Check phase is not the same as the person in the Do phase.
The Kanban method is very flexible. It’s up to the team to build his Kanban. If for example you want to respect the FIFO between each of the phases, then you will have to add on the map the dates for each of them (principle adapted if the treatment times are similar).
Kanban, a tool for planning assistance
One of the great interests of the Kanban tool in helping planning is to be able to visualize the different levels of priorities. For this, the tool proposes to add logos on each card according to its status.
The table below gives an example of logo and specific case. Of course, you can adapt it to your context.
Indicates the priority level of the Story. This is not his priority at the project level overall, but in relation to ongoing tasks.
Indicates that what was to be done is done and that the map can be taken by the next phase team when it is ready..
Indicates that there is a lock point on this action. The person who puts this logo must indicate why the kanban is blocked. The reasons can be very diverse: we expect information from a supplier, the kanban is not well defined and requires a review…
You can also put different Kanban card colors according to the type of tasks to be performed. For example, for tasks related to new projects, they can be put on a blue card and tasks related to problems on old projects on a green card. It will be easier to create the rules of decisions with for example : all 2 blue cards, I take a green.
H. Kniberg, M. Skarin (2010) – Kanban et Scrum – Tirer le meilleur des deux
J. W. Reeves (1992) – What is software design ?
M. Poppendieck et T. Poppendieck (2007) – Implementing Lean Software Developement
T. Ohno (1978) – Toyota Seisan Houshiki