agile [Article] Scrum vs Kanban - what flavor of Agile is king?

[Jimi Wikman]

Over the years I have seen many claims to what flavor of Agile is king. In this article we will look at Scrum and Kanban to see if we can determine which of these two flavors are the best for you and your team. I have a feeling you will be surprised at the answer, but I hope you will not be.

I recently read an article called "Scrum Is Dead. All Hail Kanban, the New King" where the author Emanuel Marques praise the Kanban flavor of Agile as his experience of Scrum have been less positive compared to Kanban. One of the responses to that article was written by Maarten Dalmijn, and he made some good points in his article on how flawed the initial article was.

To anyone who work with Scrum in multiple projects and multiple companies you probably recognize Emanuel's story. It is in no way a unique experience he has that Scrum, like many other Agile flavors, are misrepresented due to adjustments by the team or the company. Here are some examples from Emanuel's article:

Quote

After a few years, I started noticing one thing: In the last days of a sprint, everyone was rushing to deliver everything they had done in the previous two weeks to avoid carry-overs, frequently taking unnecessary risks.

A common thing that happens way too often. When you are inexperienced with Scrum, estimations and you do not set sprint goals, then this happens a lot. We see that the team is not working properly in the burndown chart as well.

This is a typical Agile burndown when using story points when you either have issues that are too big or you do not close issues properly. For a team working with story point, which I think is stupid in any case, a burndown chart is completely useless.

Quote

If you needed to do unexpected work (bugs, problems in production, etc.), it would affect your time and consequently make you fail the commitment you made in the planning meeting.

This is again inexperience in making proper estimations and because of that you did not have room for the unexpected. In all processes, methodologies and frameworks you need to be able to make proper work assessments. Agile make that easier by letting you make arbitrary measurements that are more like "guesstimates". If you fail doing that, then you are in real trouble regardless of what process methodology or framework you choose.

Emanuel's team choose to go to Kanban because of their inability to adjust their way of working away from the production line of thinking to an Agile way of thinking. What was it about Kanban that attracted them?

Quote

• Kanban has no timeboxed iterations (sprints).
• Kanban does not require story estimation.
• Kanban does not have the concept of commitment. Items enter the flow as they need to be done.
• Kanban provides several metrics that measure the time that a story takes on the board.
• Kanban does not require a Scrum Master (obviously).

So out of all the things that Kanban offer, Emanuel's team choose to focus on these. As you can see all of these are about commitment and responsibility. If you combine this with the reasons Emanuel and his team felt the need to move from Scrum to Kanban you probably can see the same thing as I can and that is that this is a team that no one has taught how to work properly.

They have been left in a work environment where things are difficult to navigate and control and as a result they feel they are unable to commit to anything. I assume this is because failure, as diffuse as that definition might be, happens frequently. They also seem to be working with a poor scrum master, possibly also inexperienced or limited in his capabilities by the work environment.

Sadly I think Emanuel and his team will soon find out that Kanban with the focus on escaping accountability and control is a bad choice. Kanban is not going to make failures go away. In fact, it will probably make things worse as the stakeholders will find the Kanban way of working, especially the bare-bones version Emanuel and his team are describing, very annoying as they have little to no control in that flow.

What does this have to do with what flavor is king?

Well this has everything to do with what flavor is king. They all are. If you use them properly. Sadly many work places implement Agile in all its forms in the wrong way. They try to make Agile work in a project based organization with an ITIL based steering structure with multiple teams on the same products.

If you add inexperience and poor coaching resources, then you are setting up all flavors of Agile to fail. With that comes frustration and stress for the teams, and they will naturally try to distance themselves from management and any form of accountability as they are destined to fail regardless off their effort.

This is referred to as a MOD project by some of us that work with process and methodology design. MOD is short for "March of doom" meaning that the project or the team are already doomed before they start due to the restrictions already placed on them. It is also in reference to how managers often refer to them MODifying the Agile way of working, which often result in a poor experience.

If you work with Scrum, Kanban, DevOps or any other flavor of Agile, that can be king for you and your team. If you use it correctly and you actually take your findings in retrospective to adjust it to fit your way of working. You can even mix them to find the optimal workflow for your team, because they all come from the same source: Agile.

You have the power to make your flavor of Agile king

This might seem strange for anyone who work in workplaces where your way of working is dictated by management, but there is hope. In all organizations you have two ways of working: The Steering and the Operational. If you can find the way to meet the steering, so they can do their job, then what happens in your team should be up to you. If you are sharing responsibilities with more teams, then you should build your way of working together with the other teams. Never work in isolation if you share responsibilities.

In order to do that you need to figure out what steering need so you can provide that. Usually this is the holy trinity of time, money and quality. Time and money comes through time reporting and proper estimations. Quality comes from requirements and testing alongside prioritization. So no matter what flavor you choose you need the following:

• A handover of translated need - you need to understand what the need is so you can take ownership.
• A Prioritization meeting - to decide what to do next.
• A common practice to make estimations - learn to make proper estimations instead of "guesstimations".
• Log time at least once per day if you have time estimates.
• Break down tasks as small as possible and close as soon as they are done if using story points.

That is usually all you need, regardless of flavor.

So go out and make whatever flavor you prefer KING today.

View full blog article