When SCRUM becomes a harsh mistress

Crushing waves | Source: Pixabay

Summary

In this post, I share my thoughts and recent experiences with Scrum and Kanban. While the first one is my default choice, the latter turned out to be revolutionary for my team at the startup I'm currently developing. Why? What are the benefits? When Kanban can yield better results than Scrum? Read on to find out!

Introduction

I've been using Scrum for many years. I've been in all possible roles: team member (developer), product owner, and scrum master. I've seen great and miserable implementations of Scrum. I've even experienced it in scale - from basic Nexus to full-bloom SAFe (Scaled Agile Framework).

It is for sure my default choice when it comes to agile methodologies. It's a great framework that helps teams to deliver value iteratively and incrementally. As a de facto standard, nobody questions it anymore. It's just there, and it works. Or does it?

The challenge

We're a team of six (to be precise, including the PO) building an innovative product. As we originate from a corporate environment, our technology stack is rather advanced: Kubernetes, Java, and React to name a few, yet we're a startup that needs to deliver value fast.

Our team is small, we're cross-functional, and we're building a product. We need to deliver value continuously. Sounds like a Scrum Guide definition of a Development Team. For all the reasons above, I had no doubts that Scrum is the way to go.

How wrong I was... By their nature startups are a bit unpredictable, require a lot of experimentation, and are very dynamic. Sometimes you need to pivot, sometimes you need to support a customer, and sometimes you need to fix a bug or simply extend the runway by doing a consulting gig. All of these things are ad-hoc and usually don't fit into any schedule.

In the long run, all such variable tasks should be reflected in the velocity of the team. However, in the short run, they can be a real pain in the ... neck. The team may constantly be in the state of "not meeting the sprint goal" and "not delivering value". This is not a good place to be. Why is that happening? Let's take a look at an example.

Example

Let's imagine a team similar to mine.

Team's parameters:

• velocity: 30 story points per sprint
• sprint length: 2 weeks
• average story size: 3 story points
• team composition:
  • 1 backend developer
  • 1 Ops engineer
  • 2 frontend developers
  • 1 UX designer
• the team knows each other well and has been working together for a while

That gives:

• 3 SP per day
• 6 SP per sprint per person

So far so good. In theory, the team should be very predictable and over a known period should be able to deliver a known amount of value. Let's take a closer look at some historical data:

Sprint	Delivered	Planned
1	12	30
2	48	30
3	15	30
4	33	30
5	12	30

What we observe is that the team is very unstable and delivers almost random amounts of value. From the mathematical point of view, the standard deviation reaches 16.02, which is over 50% of the average velocity. That's a lot!

Warning! Maths ahead!

Standard deviation (or $\sigma$) is a statistical measure of how dispersed the data is around the mean. Formally:

$$\sigma = \sqrt{\frac{1}{N}\sum_{i=1}^{N}(x_i - \mu)^2}$$

where: $\sigma$ is the standard deviation, $x_i$ is each data point in the set, $\mu$ is the mean, and $N$ is the total number of data points.

What might be the reason for such a high standard deviation? Let's take a look at what happened during the sprints:

• Sprint 1
  • the only Ops developer was on vacation and he's the only one who can do code reviews of the backend code
  • UI was blocked by UX
  • PO was unavailable for a few days
• Sprint 2
  • everything went smoothly
  • pending reviews were done quickly
  • UI was unblocked
• Sprint 3
  • the only Ops developer was on vacation again
  • UX was needed for a customer consultation
  • UI was blocked by UX
• Sprint 4
  • UI/UX was at a conference
  • backend & Ops were working uninterrupted -- they usually estimate higher, yet deliver quicker than the team's average
• Sprint 5
  • several bugs were found in the production
  • the sprint was shorter due to the holidays
  • one of the frontend developers was sick

As you can see, there are many dependencies between the team members. The team is cross-functional, but each of the members has a different skill set. The team is also small, so there's no redundancy. If one of the members is unavailable, the whole team is affected.

People also estimate differently. In fact that leads to a situation where there are sub-teams within the team and even the exercise of planning a single sprint has lots of variables that must be counted. Nightmare!

To add insult to injury, it often happens that some people run out of work, while others are overloaded. In tools like Jira, this is visible as a scope changes during the sprint. This is a clear sign that the team is not stable and the planning is not accurate.

Adding redundancy to the team or splitting the team into smaller ones is not an option.

Are we doomed? Is there a way out of this mess?

Kanban to the rescue

When I asked myself these questions, I realized that we're not the first team that has this struggle. While looking for a solution I ran into a YouTube video by Eric Brechner: Agile Project Management with Kanban (if you're considering Kanban it is a must-watch!) where he demonstrates Kanban in a tool-agnostic way.

It was like an epiphany! It became clear to me that with Kanban we can cut the planning overhead and focus on the work. Long-term predictability probably won't be any better than with Scrum, but at least we'll be able to deliver value continuously. Let's take a look at the pros and cons of Kanban:

• Pros
  • no planning overhead - we have scheduled meetings (short ones!) to review the board, but that's it
  • no sprint goals - the current task is the priority
  • no problem with the scope changes - we can add or remove tasks at any time
  • estimations are optional - we can use them, but we don't have to, our rule of thumb is to split tasks into smaller ones if we anticipate they may take longer than 2 days
  • we can sync in subgroups, mini-refinements are possible ad hoc
  • when priorities change, we can react quickly - it is as simple as shuffling the cards on the board
• Cons
  • no sprint goals - we need to be careful not to lose focus, it is easy to get task-driven and lose the big picture
  • long-term predictability is difficult, but hey, with Scum it wasn't any better, on the other hand usually this is not a problem for startups, the most important thing is to deliver value continuously and be able to tell what comes in next
  • it took a bit of time to get used to new boards and new rules

From my observations, we have gained extra velocity. I estimate the increase to be around 15-20% judging by the number of tasks we deliver every 2 weeks.

We decided to keep the reviews and retrospectives to give insights into the progress to all stakeholders and stay on top of the process. Impediments and problems are discussed and addressed as we have done so far. For the time being, we're not using any metrics not to overcomplicate the process.

The team is also much more happy and relaxed. The feeling of being constantly behind the schedule is gone. We can focus on the work and deliver value. We're also more flexible and can react quickly to changing priorities.

Summary

Will we stick to Kanban? I don't know. For now, it works, and we're happy with it. We'll see how it goes in the future, especially when the team grows and we will be able to add some redundancy and split into smaller, specialized teams.

As long as throughput is more important than the ability to plan long-term, Kanban is a great choice. It is also a great choice for teams that are not stable and have a lot of dependencies between the team members or are frequently distracted. In such cases, Kanban can be a real game-changer.

What are your experiences with Kanban? Do you prefer it over Scrum? Have you made a transition from Kanban back to Scrum? What was your motivation? Let me know in the comments below!