Scrum, Kanban and the creation of value
Choose Scrum or Kanban, depending on the way you create value


Scrum and Kanban, Agile and Lean

Being Agile and using Scrum have become synonyms. But we have all noticed the Kanban boards popping up, on screens or as big segments of wall covered with stickies. You will also find information about Scrum teams moving to Kanban, JIRA makes you choose between a Scrum based or a Kanban based approach for you project, Spotify talks about Squads and SAFe is based on agile teams using either Scrum or Kanban.

Plenty of articles will explain the differences between Scrum and Kanban, e.g. Leankit and Projectmanager . The essential message is that Scrum and Kanban differ quite significantly (11 major differences) and that they come from a different mindset: Scrum is agile and Kanban is Lean.

This leads to the obvious questions: which approach is better, or under what conditions should we use which approach, or even more fundamental: how come two so different approaches can be considered equivalent.

Looking at the kind of work

Scrum is for many organization still a relatively new approach to software development project. And it works great in ‘greenfield’ development in an organization that is used to waterfall practices. We build the product in short iterations, show it to all team members and to the customer, then plan for the next Sprint, based on functionality in the form of user stories and team-based estimates and a sensible prioritization.

The first sign of trouble with Scrum is when part of the code is in production and the customers detect bugs and functional deficiencies. They arrive in the middle of a Sprint and have their own urgency. Some require immediate dropping of all other work and start bug-fixing right away, no matter how much work the solution is going to take.

We violate two major Scrum rules: the scope of a Sprint is sacred, because the team committed to it, and we forego estimation, meaning that we diminish predictability. So why do we do it?

The short answer is that fixing the bug generates more business value faster than the other work we committed to in the Sprint. Fixing the bug and fast repairing the production solution is most likely the best way of creating business value.

So Scrum looks better for work that will take some time before it can actually generate value, such as the early development phase of a project with relatively imprecise requirements. Kanban is better for work that is likely to generate value real fast (or diminish the loss of value inherent in bugs), in small chunks of work. We can estimate the value individual items will generate and prioritize accordingly. We may want to adjust a bit for the time the job will most likely take, with more focus on short jobs that will generate their value faster.

Choose your approach based on value creation

This leads us to the notion that the approach we choose for doing the work depends on the way we create the value.

In the old days we created value by first thoroughly analyzing what the customer wanted, elaborating the best technical solution, have specialists develop it and quality assurance test it. There are three things challenging this approach:

  • It is slow in delivery

  • It focuses too much on the idea that the requirements are fixed·        

  • We try to fix a single best solution up front

Agile development works in short iterations. The demonstration of the intermediate solution after each Sprint allows closer involvement of the customer, so that we do not need to elaborate the requirements up front to the same level of detail. We can learn from the early stages in product development as well, so that we can adapt the technical solution. We create a multifunctional team, so we break down the barriers between the silos and the teams deliver faster:

  • ·    Faster delivery

  • ·   Customer feedback, discovery of what the customer really needs

  •     Learning by the team, evolving to the best solution

How much of these benefits we realize will depend on the quality of the interaction with the customer, the functioning of the team and the adoption of best technical practices. If code is developed using XP (eXtreme Programming) practices, such as Test-Driven Design, Continuous Integration, Pair Programming and Refactoring, we will come up with code that can be adapted to changing requirements without deteriorating. If not, our ability to adapt to evolving requirements will be hurt.

The value we create during many Sprints, particularly in the early stages, will be that we can better detect what the customer really needs and values (and, in return, also give transparency on progress and our own ideas). This value does not however translate into direct business value, it is input for further development. Fixing an issue in a production system first will most likely generate better economic result than continuing development.

During later stages of product development and even more during the service phase of a product, there is significant economic value in fast realization of individual requests or bug fixes. Letting an important request or a bug fix wait for the next Sprint constitutes a waste of time, with an economic cost. This means that in a single product development initiative, Scrum can very well be economically the best approach during the early stages, when we are discovering value. In later stages Kanban can give a better result as product enhancements deliver business value in a more direct way.

The influence of DevOps

Scrum describes its delivery mode as ‘generating potentially shippable code’. In real life, the focus is in many places indeed the ‘potential’ part rather than the ‘shipping’ part. This cannot be avoided entirely of course: a product needs to have some minimum set of functionality and quality before it can really create value. But a lot of time is still lost at implementing the code.

Paradoxically, a low frequency of delivering code to production reinforces Scrum over Kanban. It puts the project longer in the state of building rather than delivering.

DevOps is focusing on more frequent delivery of working software, transforming the potentially shippable into real working code generating business value. The higher the degree of automation of software deployment, the more frequently we can deliver and the faster a newly developed user story can be moved to production.

Meaning that DevOps will contribute to moving the balance from Scrum to Kanban. The underlying reason is that DevOps has a clear focus on automating deployment. It creates a faster flow ‘downstream’ from development, pulling in work from development at a faster pace.

This is a more general point. The more successful we become in creating flow using lean-agile principles, the more we will focus on that flow.

Sign in to leave a comment


Productivity of Pair programming
Some myths debunked?