Up to 30% off e-learning!

Click here to view all offers

Use offer code: SALE0324USA
Learn now, pay later – payment options available
Meeting in front of a Kanban board

Kanban project management with PRINCE2

Developed by Toyota in the late 1940s, the Kanban system originally aimed to improve manufacturing efficiency. Taking its name from the card system that tracks production in a factory, it has since been refined and customised by many different manufacturers. Now, this system is used in project management, featuring in the PRINCE2 Agile guidance.

What is the purpose of Kanban?

Unlike a lot of other project types, Kanban is not based off specialist activities. Instead, it’s about the project and the flow. That means team members often step outside their areas of expertise to help others. Kanban is therefore focused on the bigger picture.

How does Kanban work?

The system works by everyone referring to a Kanban board, which is made up of columns with a number of tasks in each one.

When one task is finished in one column by a team member, it is pulled into the next column by the person who will complete the next task. For example, when a task is completed under the programming column, it will be shifted to the testing column.

Importantly, people ‘pull’ work from one column into their own. Tasks aren’t ‘pushed’ from one column into the other, as work could stack up for one or a few members and create a bottleneck. Instead, Kanban’s core rules ensure a steady workflow.

What are the Kanban rules?

  1. Visualise the work – by doing so, team members have a better sense of control over the project. Kanban boards are an essential visual aid. Therefore, the project manager shouldn’t guard it for themselves. Everyone needs to keep track of it.
  2. Limit work-in-progress (WIP) – switching between tasks consumes time, which is why limiting work in progress is a key part of the Kanban system. This is why work should be pulled instead of pushed. With this method, people only take on new work when they have the capacity.
  3. Manage the flow – when someone reaches their work-in-progress (WIP) limit, it creates a bottleneck. That means others in the system cannot pull work towards them. Instead of waiting around, they will swarm to help dissolve the bottleneck – even if they are not an expert in this particular field.
  4. Make policies clear – WIP limits and solutions need to be set early so everyone knows what to do if a bottleneck occurs. This ensures that anyone new to project work or this kind of project will understand what’s expected of them.
  5. Implement feedback loops – daily stand up meetings along with showcases to customers also form an important part of the Kanban process. It’s best to use Scrum to enforce this rule. In fact, some argue that anyone practising Kanban is really doing ‘Scrumban’, since the two go hand-in-hand.
  6. Improve collaboratively, evolve experimentally – keep identifying processes which are slowed down and improve them as you see them. While swarming on blocks in the work queue is important, you can be proactive against future blocks. So use the scientific method and models like the PDCA cycle to continually improve work processes.

Using Kanban with PRINCE2 Agile

To minimise multi-tasking and help set a WIP limit, many people suggest setting the WIP limit to the number of people on the team. For example, three software developers would have a maximum of three tasks in progress, while four testers would have four tasks.

Kanban’s 4th rule, ‘make policies explicit’, is the most important one for project managers to get right. You have to implement risk management and set the scope. To enforce that, the project manager needs to set the feedback loops. Otherwise, they won’t know what’s going right or wrong in the project work.

The project manager will need to stay involved in the feedback loop too, since that’s how they distribute work packages and tasks via the Kanban board, as well as communicate with managers and stakeholders.

Bear in mind that project managers don’t need to be involved in everything. They don’t need to attend daily scrums or read documentation feedback that devs leave each other on Github, for example. It’s more about remaining in the loop. They therefore have to limit themselves only to the feedback loops which are necessary for project management.