Scrum VS Kanban | The right approach for the right problem

In 1986, Author Hirotaka Takeuchi and Ikujiro Nonaka published in the famous Harvard Business Review “The New New Product Development Game”. The article recounts their research on the original manufacturing process of Canon, Honda and Fuji-Xerox. Active in three different industries, these companies had one thing in common: they were better and faster at marketing successful innovations than their competitors. The reasons for their successes have since then been understood as what is today the most famous Agile framework, scrum. 

Context

Thanks to its visual simplicity, most development teams worldwide adopt scrum as they are seeking to deliver better products within constraints. This approach is structured and designed around ceremonies. It allows teams to inspect and adapt rapidly to deliver small valuable batches of working software. Nevertheless, hidden below its apparent simplicity lies a framework that is hard to implement and often misunderstood entirely. We’ll see in this article one reason why scrum often fails to deliver on its expected promises. The likes of seeking to cutting wood with a screwdriver most likely leads to failure. Thus, using scrum to solve problems it isn’t supposed to solve will also lead to disappointment.  

When is Scrum not helpful?  

Here are a few situations in which Scrum might not be the right framework to use:

✖ When there is a complicated problem, not complex.

It is crucial to understand this difference if one wishes to apply the right approach to the right problems. With guidelines, protocols, rules, checklists and processes, you can foresee the resolution of a complicated problem. Building a house is a complicated problem, for instance. If you wish to build a house, you will know in advance that you need to draw the plans first. You will also be able to assess the nature and quantity of the material necessary to build it and which competencies you will require to put all the pieces together can be planned upfront. Finally, you will able to know how much its house will cost with great accuracy. It can be hard but it isn’t complex.

A complex problem on the other hand relies on the fact that solving it will shift its nature in itself. Disrupting an industry with a cutting-edge product is complex as you can’t plan it up front. There isn’t one way to achieve it and it relies enormously on trial and error. With its built-in short feedback loops allowing rapid iterations, the scrum framework works for complex problems. However, it can’t be useful for complicated ones.

✖ When maintenance constitutes the bulk of a team’s tasks.

It can be the case for service companies marketing CRMs for instance that the bulk of their incoming requests are purely configuration or bug fixing tasks. Scrum is based on delivering a working increment at the end of each sprint. Scrum isn’t useful in tackling tasks that can’t be packaged into a valuable piece of working software.

✖ When the development team is involved on multiple projects simultaneously.

Due to scarce resources or simply due to the nature of the job, developers can involve themselves on multiple projects. Juggling between a project to another and committing to several sprint goals within a single sprint doesn’t provide the focus or the time necessary for teams to get the benefits of the Agile framework. Nevertheless, if one had to implement it, it’s natural that work in progress would increase as well as the duration of each project.

✖ When uncertainty prevails in your context. Typically, when teams have little control over the scope.

To achieve a piece of valuable and working software in the duration of the sprint, one needs to know the content and scope of the sprint and to prepare it in advance. Teams need to have an idea on where they are heading. One could either design or prototype the idea but it needs to exist. In contexts of large uncertainties where the sprint goal could be regularly disrupted by unforeseen events, the given structure of the framework could be too restrictive, not adapted.

✖ When scrum masters or product owners lack active involvement or reliability.

The inability to deliver on commitments several times over or the inability to plan ahead for a certain period of time are situations that can diminish the benefits of scrum. Reasons for these can come from the lack of support the development team receives from both the scrum master or the product owner. Teams who aren’t shielded well or guided by a clear vision lack the focus or the ability to understand requirements properly. The scrum framework relies on the full and reliable involvement of all roles to work. A weak link can undermine the benefits of scrum and cause many frustrations. It may be best to consider approaches when you’re in a context where you can’t unroll correctly scrum.

When there is little control and certainty over the sprint goal, the team’s availability to the project and the context itself, a more flexible approach like Kanban could be useful to provide a minimum of understanding and visual on the work at hand.

Kanban is an approach to development which emphasizes visualization to improve flow by identifying and lifting bottlenecks quickly. The method was first implemented by Toyota in the 1940s to allow greater levels of customization in their cars and identify resource shortages quickly. It is today widely adopted by IT teams to track development.

How can Kanban be helpful?  

Where scrum is based on time-boxed sprints, Kanban emphasis on continuous flow and the limitation of work in progress. Unlike scrum, Kanban focuses on capacity. You recalibrate the constraints imposed on the flow depending on the size of the team. You don’t have to estimate tasks or split them into smaller standalone tasks. In fact, you can add them whenever to the board and prioritize them freely. In all, Kanban provides more flexibility.  

For IT service companies dealing with many customers an approach like Kanban becomes useful. Priority shifts from breaking tasks down and building fixed length sprints to moving tasks through one end of the board to the other as fast as possible, irrespective of the size of each task. Similarly, when chances are that the sprint goal may regularly be disrupted (a context where scrum is not adapted) the continuous cadence of Kanban can become a great fallback solution to ensure a minimum of structure for teams.

How can I follow progress and improve flow without the scrum’s practices?  

Several straightforward metrics can help teams understand how their workflow is going and how to improve it. 

Cycle time helps teams understand how long tasks stay on the board from the moment you picked them up to the moment you closed them. This metric differs from the measurement of lead time (also known as throughput). It averages how much time tasks remain on the board from the moment you created and added them to the board until you closed them.

Cycle time histograms are useful tools to predict future delivery times based on different confidence levels. This tool and associated metric replace all together the need of breaking down and estimating tasks time. You can ultimately allocate it to development or other value-added activities.

As mentioned earlier, an important point of focus in Kanban is the limitation of Work in Progress. Limiting work in progress improves efficiency on a low as you finish what you have started before starting something else.

In all, the metrics and the flow optimization capabilities brought forward by the inherent visualization of the Kanban method can be useful to teams to whom scrum isn’t the right development approach.  

Nevertheless, cherry picking what’s good to take from the scrum framework is not a bad idea, you don’t need to abandon everything entirely. Daily meetings, refinement sessions or team retrospectives can be valuable in any context outside the scrum framework depending on what the team really needs. 

Interested to get deeper into the topic of Product Ownership? 

👉 Get other insightful tips on our blog.  

 
👉 Are you a Product Owner looking for a new challenge? Join our team of experts 

👉 Or contact us to get support on your projects: corp_hello@worldofdigits.com 

By Lucas Jako