Kanban Emerges as Key Role Player in Agile
Dillon Weyer – Agile Consultant, IQbusiness
Kanban has emerged as a key role player in the world of project management. According to Version One’s 2014 9th Annual State of Agile survey, Kanban now accounts for 5% of the Agile Methodologies used worldwide. This is a significant stride, considering that Kanban failed to feature in the 2010 survey.
In SA the popularity of Kanban has increased – not only at a team level, but also at a portfolio level – having become more applicable to knowledge work, rather than manufacturing.
However, a conflict in the understanding and application of Kanban pervades, and compromises its usefulness. Kanban is a lot more than just a board with post-it notes, highlighting a list of tasks for completion. It’s an approach to enhance understanding around the flow of work in a system – helping to identify areas of tardiness. And if used optimally, Kanban is a powerful tool for maximising workflow.
Kanban stems from lean manufacturing in the Toyota Product System that was developed by Taiichi Ohno. Toyota adopted this system to reduce inventory – identified as one of the seven wastes. And Kanban has been instrumental in reducing the amount of inventory held based on the just-in–time fulfilment or manufacturing, which is guided by customer demand. A card alerts the operator when stock reaches a level for re-order. This principle is applied to the entire value system – from the customer determining what the demand is, right up to the manufacturer of all the individual components.
In 2005, David Anderson applied the principle of the ‘pull system’ to knowledge work (which is inventory, in this case). Here, work from a previous step in the process would only be started once the next step was ready to ‘pull’ more work. Later, Anderson applied ‘work in progress’ limits to each step in the process, which reduced the amount of work in progress/ inventory. This later progressed onto visualising the work items on a board.
Though, most teams find benefit in visualising work on a board first, this remains just one element of Kanban – leaving a host of other benefits untapped. Therefore, the application of work in progress limits, as well as the introduction of a ‘pull system’ are critical. This way, the identification of glitches like bottlenecks in the system will also become easier – enabling swift improvements to the system.
The reduction of work in progress is the most seamless way to increase the throughput of work in a system. Though, seemingly counter-intuitive, this will help stop the ‘pushing’ of work, and enable waiting for it to be ‘pulled’. And this is when the benefits relative to the principles of Kanban become a reality. Put simply, if work isn’t ‘pulled’, no new work should be started. And those who are unable to start new work can then simply help with items gathered in the bottleneck – which could present them with the opportunity to learn a new skill. This, in turn, aligns with what Agile encourages: cross-functional teams.
And from a people change management perspective, the application of Kanban comes with very little disruption to teams/ organisations. Initially, you start where you are, without any changes to the process, roles or structures. However, a commitment to incremental and evolutionary change is mandatory.
Furthermore, Kanban can be applied at any level in an organisation – from team to portfolio level. But it’s recommended that you start as high up in the hierarchy as possible. This is because focusing at a team level only, limits the benefits to only a local level – resulting in sub-optimisation within the organisation. And, just like we want individuals in a team to pull work, we also want teams to pull work from other teams. The same applies to work in progress. Reducing the number of projects in progress will increase the number of projects completed in a shorter period of time.
Most teams undergoing an Agile transformation start with Scrum – the most popular and most understood. However, we often find that they don’t own the end-to-end value stream to deliver a potentially shippable product increment (PSI) that Scrum requires at the end of an iteration. This is because most organisations still have inherent silos, and multiple hand-offs occur to ensure that a piece of value comes out the end of the system. Again, this typically leads to local optimisation for the team, but undesired global sub-optimisation. But, rather than introduce a face-off between Kanban and Scrum, we merely recommend the application of the ‘Start where you are principle’, and over time – when you are optimising the system with incremental improvements – through structural change, and changes to approach and flow of work, the team will itself deliver the end-to-end value.