Is Starting with Kanban Really Easier than Scrum?

Is starting with Kanban really easier than with Scrum?

Kanban is often described as a way to achieve evolutionary change in an organization, creating less fear and resistance than more “revolutionary” approaches such as Scrum. Kanban indeed respects current processes. For example, in its first steps it does not impose role and responsibility changes, but encourages continuous small incremental and evolutionary improvements to your current system.

But is it really an easier way to launch a change process? Always? The last few Agile implementations I was involved with that used Kanban as a starting point made me contemplate this topic. Here are some of my thoughts.

Implementing Kanban seems to be simple technically. Just visualize your current process, build the Kanban board and describe your process as a pull system. Kanban does not prescribe specific practices, but the team is expected to apply lean thinking tools such as limit the WIP, focus on flow, optimize the whole, stop the line and fix (focus on quality), find bottlenecks, protect the team from external interruptions, etc. This requires high maturity from the team.

Unfortunately, in many cases, teams find themselves struggling at the starting point, especially when attempting to apply the “limit the WIP” step. This can be extremely difficult and requires good collaboration and shared responsibility between the development team and the PO in order to allow balancing demand and throughput. When this collaboration is not mature, teams tend to get stuck and find it hard to move forward, which leads to frustration and increases resistance to the change.

Shape the path - Script the way

Scrum’s prescriptive nature is more suitable for such immature teams as it “scripts the way” (from “Switch” by Chip Heath & Dan Heath) and provides best practices and definitions of the processes to be followed (daily standup, planning, demo, retrospective, clear definition of the PO/team responsibilities).

Scrum provides a practical framework that makes the mindset shift easier, as teams can rely on the framework in this “SHU” phase (“Shu-Ha=Ri see: https://web.archive.org/web/*/https://alistair.cockburn.us/shu-ha-ri/). The clear definition of the PO role vis-a-vis the team provides the needed collaboration and WIP is limited implicitly by defining the sprint’s backlog, which I believe teams find more natural to grasp.

Small work units

Another point to consider is the need to break features into small pieces or user stories. This is a huge challenge that teams usually struggle with from day 1 in both Kanban and Scrum. This is fundamental to improving the flow in the system, thus reducing cycle time in Kanban, and creates the building blocks of the product backlog and sprint backlog in Scrum. I find that Scrum guides you more safely and clearly in this task than Kanban, as the framework and practices for creating stories are explicitly built into the Scrum process.

Questions like: who is the owner of the stories? When should the stories be ready? What is a good story? Who approves the results and when? The team has built–in answers when it uses Scrum as a starting point.

The energy for change

It is also very important to consider the “energy” that the organization needs to have in order to change. Agile practically requires the organization to “reinvent” itself and, in many cases, the beginning of the process is an excellent opportunity to do just that. At that time, the right levels of energy exist, with the “buzz” created by training and management’s attention, as well as the willingness and courage to make a dramatic move.

Scrum suits this “let’s make a revolution” mindset much more than Kanban, which requires stamina, patience and long term thinking. Most teams don’t have the time and patience for ongoing improvement cycles – they want results now. They are willing to risk, speculate and go along with revolutionary ideas rather than patiently wait for evolution.

Early success

Being able to achieve small wins early in the process provides a lot of “back wind” to the process. Scrum’s sweeping nature allows identifying these small wins quicker, thus injecting positive energy into the process at a much needed stage. The adoption of cross functional teams and creation of a rhythm in the organization, with demos and retrospectives quickly gives a sense of progress. It is important to pick low hanging fruits and produce results quickly.

I found that in many cases, if a momentum for revolution exists both in management and teams, Scrum’s constraints are much better for keeping the teams focused and accountable. Once you reach a point where you have a backlog with well defined stories and you are mature enough to go to the next leap, it is time to implement Kanban in order to optimize the whole and focus on the flow of value across the system, improving your cycle time from start to end.

So, should we start with Kanban or Scrum?

The only right answer is: it depends. It depends on the organization’s state, the scale of necessary changes, the desired outcomes and the problems and pains that triggered the Agile initiative.

What I attempt to do in this post is challenge the widespread myth that Kanban is always the easiest way to start. I have found that, when management is on board with the right mindset, starting with Scrum can be safer and easier. The Retrospectives in Scrum provide the evolutionary mechanism Kanban advocates that allow the organization to continue and make small incremental changes and continuously improve beneficial aspects and weed out harmful attributes

Start with Kanban or Scrum but, since you are interested in this journey, it is important to start! Begin, keeping in mind why you started and what you are trying to achieve .We don’t want to waste our time with too much upfront planning anyway, after we begin the journey, the steps we should take to move forward will unfold.

“The Road goes ever on and on

Down from the door where it began.

Now far ahead the Road has gone,

And I must follow, if I can,

Pursuing it with eager feet,

Until it joins some larger way

Where many paths and errands meet.

And whither then? I cannot say.”…

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.