Exploring the Kanban methodology

Before COVID-19, I took some time out of the office to learn more about Agile project management methodologies, in particular zooming in on Kanban. Below are some of my key takeaways.

What is Kanban?

Kanban is an agile methodology which prioritises small changes ‘Kaizen’ over large overhauls. The idea is that evolutionary change is often more acceptable (for the people doing the job as well as those at higher levels), less risky and faster to implement than radical change ‘Kaikaku’. 

There are four principles to Kanban:

1. Understand: begin with what you do now, and understand how it works
2. Agree: agree at a company wide level that you’re going to pursue incremental, evolutionary change
3. Respect: (initially) respect current roles, responsibilities and job titles
4. Encourage: encourage acts of leadership at all levels, including all team members from senior management to the individual workers

The Kanban Method places importance on the visualisation of the tasks in hand. This visualisation, using a board and Kanban cards allows all team members to view the workflow, invisible work, and business risks.  Using the board, and the Kanban core practices the Kanban method aims to improve delivery and provide flexibility. This allows for a company to respond effectively to business environment and customer demands. 

The Kanban method originated in the manufacturing systems in Japan following WW2, the method was originally formalised by Toyota. The word ‘Kanban’ has a two-fold meaning. In Japanese ‘Signal Card’ and in Chinese ‘Visual Board’ – as both the cards, and the board are key tenets in Kanban it’s great that the word itself so neatly describes it! 

From its origins in physical manufacturing it was further developed for use in the software development world, beginning at Microsoft. It’s implementation was seen as a development of the SCRUM methodology in order to use data to improve workflow further. 

As Kanban sits under the umbrella of ‘Agile’ there are lots of similar methods out there.  Having come to it as a Kanban novice, I approached the course as a means to find out more about Agile methodologies. In doing so I can fully see how Kanban is an effective development beyond SCRUM, especially for application in a company like ClarityDX. 

How does Kanban compare to other project management methodologies?

At a top level, the most overwhelming difference with other methodologies, is that Kanban doesn’t have to be iterative and allows for more flexibility.  Within SCRUM there is very little movement for change once a direction has been set within the sprint. As such, the team has to follow the directives set in the sprint for at least two weeks without being able to reset and change priorities.  Kanban simplifies it. A daily stand up reviews the whole board and allows for easy re-prioritisation of the tasks. By releasing work regularly, re-prioritising tasks and discussion on an on-going basis, Kanban allows teams greater flexibility and improves delivery.  

This flexibility is crucial for us due to the varying number of projects we have on an on-going basis, and the discovery, design, development, and deployment workflow. As we already run a system which prioritises frequent delivery and the flexibility to change priorities on an on-going basis the implementation of Kanban methodologies is a natural fit. 

What are the core practices crucial to Kanban implementation?

Within Kanban there are Core Practices crucial to its implementation:

• Visualise: show work and it’s flow through the use of the Kanban Board
• Limit Work in Progress: teams can only work on a specific amount of work at a time – enforcing WIP limits enables teams to finish items more quickly by prioritising the elements they can work on
• Manage the flow: using the board and the WIP limits allows you to manage the flow of work and isolate areas which may need more resource/identify blockers.  Using this data to improve the system overall and make the necessary Kaizen changes
• Make policies explicit: making sure everyone knows the policies the team are working too means that work will be consistent and no one will put unnecessary pressure on the team. These policies include: WIP limit, the pull criteria (the criteria followed to allow new work in the board), the classes of service (shared agreements for completion of work) 
• Establish feedback loops: ensuring feedback comes in at the correct point and without delaying delivery but establishing loops at the appropriate times
• Improve collaboratively and evolve experimentally: by using the data collected from the board, WIP limit etc. you are able to run ‘safe-to-fail’ experiments all looking forward to improving the system as a whole continually

There are some fairly in-depth monitoring, maths, and uses of data which are crucial to the successful implementation of Kanban. They include; queue theory, service delivery reviews, risk reviews, variability reviews, flow efficiency charts, lead time distribution charts and run charts.  These were all very interesting and you could see clearly how they could be used to interpret data and improve systems. However, the elements which most interested me were those which had a more human and immediately tangible application. 

These were imposing WIP limits and effectively managing the flow of work. There are really interesting and simple ways to illustrate both these ideas and practices.  This was one of my favourites – the Flip coin game.

The flip coin game

If you’d like to try this at home you will need:

• A team of 4 workers, 4 managers and a CEO 
• 20 1p coins
• 4 stopwatches 

Pair each worker with a manager, the manager stands behind the worker with a stopwatch.  There are three rounds to this game.

1. Worker one begins flipping all 20 coins in one batch. When all 20 coins have been flipped the next worker begins to flip the 20 coins. This continues until all workers have flipped all coins in turn. The manager times how long their worker takes to flip all twenty coins individually. At the end of the round all managers provide each time to the CEO who has also timed the full process from start to finish.
   
2. Worker one begins flipping all 20 coins in batches of 5. When a batch of 5 have been flipped they can be passed on to the next worker in the chain who can then begin flipping. This continues until all workers have flipped all coins.  The manager still times how long it takes for their worker to flip all 20 coins and at the end of the round all managers provide each time to the CEO who has also timed the full process from start to finish.
   
3. Worker one begins by flipping all 20 coins in batches of 1. When coin number 1 has been flipped they can pass it to the next worker to flip. This continues until all workers have flipped all coins.  The manager still times how long it takes for their worker to flip all 20 coins and at the end of the round all managers provide each time to the CEO who has also timed the full process from start to finish.

Now, when we ran this in my workshop the results looked like this: 

	Worker 1 time to flip coins in batch	Worker 2 time to flip coins in batch	Worker 3 time to flip coins in batch	Worker 4 time to flip coins in batch	Total time for batch to be completed
20 coins in batch	13	13	15	15	72
5 coins in batch	13	19	19	19	34
1 coin in batch	15	23	24	24	28

From the above we can see that, although the workers’ individual time increased to complete each batch, the overall time for the final delivery was more than halved. 

The above exercise can be used to illustrate two things. The first is a comparison of waterfall, SCRUM and Kanban working systems, and the second is the flow of a website project. 

Here you can take the 20 coin batch to represent waterfall, the 5 coin batch to represent SCRUM and the 1 coin batch to represent Kanban. Then, you can use the data to show that, even though each system had the same end result – each worker had flipped all the coins – by tweaking and improving the system using the Kanban method there was a vast improvement on delivery rate. 

You can use this as an illustration of each phase of a website project.  The workers could represent design, development, and testing. By using the Kanban system to pull smaller work items through delivery rate can be greatly improved. And, we know that faster delivery, without losing quality, is generally what all our clients want! 

We’ve actually begun implementing, especially during the development window, a very basic prototype of a Kanban board which mimics the workflow set out in my table. We are now separating website tasks and modules into cards and pulling them through the development and QA process.  It has worked to help us identify development bugs sooner, and also has increased our delivery rate as the QA window at the end of the project is reduced by earlier testing. 

Classes of service

The idea of classes of service was also something which I found very interesting and directly applicable to how we manage our projects and tasks on an on-going basis. Within the Kanban board, tasks are organised into four distinct classes of service. These are:

• Standard class
• Fixed date
• Expediate 
• Intangible

Each class of service, crucially, has its own cost of delay.

Looking at these in comparison with the work we do at ClarityDX:

Standard class: a standard class item could be a feature update or change request to a website. It’d be great to get it done as soon as possible, however the cost to delay doesn’t increase massively at a certain point, it just goes up slowly. 

Fixed date: an example of this could be, the delivery of a website which has been set to correspond with an external date, for example an event, a stockmarket release, or another mandatory date, i.e. the end of the tax year. The cost of delay on this rises exponentially at the date it was due to be delivered, but there is no benefit to completing this too early so has to be scheduled mindfully. 

Expediate: an expediate task would be something like all the servers in our office going down, preventing the whole development team from working. These tasks must be cleared as soon as they arise as the cost of delay has an immediate impact which is felt until the task is completed.

Intangible: intangible tasks are those ‘nice to haves’ and ongoing improvement tasks. These are generally pulled through the system as long as a higher class item is not available (which are any of the above). These are seen as the lowest priority as the cost of delay is low.  

However, beware of these intangible tasks as they can suddenly become expedited tasks in the worst case scenario. A very current example of this could be the development of a ‘Work From Home’ system. A company could be slowly upgrading all laptops and internal systems to allow for WFH. It could do this on the basis that once an employee’s current system is broken, they will then replace it. This is fine, however, in certain circumstances – such as COVID-19 this ‘intangible’ rapidly becomes a crucial expedite’ as a whole company will be required to work from home and only part of the team will have the necessary equipment to do so. 

Luckily for us, we were well equipped to take on WFH and you can read more about our remote working policy here, and hear from the team themselves here.

At ClarityDX we do, innately, already set items in similar terms. We know when tasks need to be expedited and what our fixed date deliveries are. However, having an understanding on the cost of delay really helps provide structure to how project management decisions can be made and provide internal justification for what we do and when we do it. 

I could write about Kanban for hours, but the above represents those elements which I found most interesting! If you have any questions or want to talk to me about Kanban then drop me an email [email protected] and I’d be more than happy to geek out on project management methodologies!