I’ve been using Scrum since the beginning of my career. This was the framework that I was taught in college as the best to manage software development. When I started working, I loved it all: daily meetings, planning, retrospectives, sprints, etc. After all, I was applying what I learned.
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.
Why? Couldn’t some tasks wait for next week? Was the delivery of every task before the weekend that critical? No, it wasn’t. We did it because “Carry-overs are bad.”
Scrum Is Not Agile Enough
I came to the conclusion that Scrum placed too much emphasis on process — or at least people paid to much attention to it:
- Delivering a story on the last day of a sprint was OK. But the next Monday, it was a carry-over.
- 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.
- The most used metric to evaluate success is commitment vs. done, which compares the stories that you committed at the beginning of the sprint and what stories you accomplished (I won’t even bother to mention what problems this can bring).
Scrum was not guiding us anymore. It was limiting us.
With all the points mentioned above, the team started to feel frustrated, and it affected the quality of the work produced. People cared more about delivering in time than delivering with the desired level of quality.
At this point, we started to research other possible agile frameworks that would be a better fit for our work method.
We found Kanban.
What Is Kanban?
Kanban is a work management framework that was first introduced by the Toyota Production System back in the ’40s. At this time, Toyota used a visual board with three columns: Requested, In Progress, Done. This framework allowed Toyota to allocate resources better when there was a bottleneck in some areas in the production line.
Kanban was then adapted to the technology industry when people saw the benefits it could bring to the speed of delivery.
Scrum vs. Kanban
In recent years, Scrum and Kanban have been fighting for the position of the leading agile framework. Despite Scrum being the current #1 agile framework, Kanban is becoming more adopted over the years. But how do these two frameworks compare?
Having Scrum as a base:
- Kanban has no timeboxed iterations (sprints).
- Kanban does not require story estimation.
- Kanbandoes not have the concept of commitment. Items enter the flow as they need to be done.
- Kanbanprovides several metrics that measure the time that a story takes on the board.
- Kanban does not require a Scrum Master (obviously).
Kanban offers more flexibility to the team. Stories flow more freely than they would in Scrum. But with great freedom comes great responsibility. Despite not having a commitment every two weeks, other metrics must be used to evaluate the team’s performance, such as cycle time and throughput.
It’s All About Metrics
You can’t measure your success (or lack thereof) without having metrics that allow you to assess your progress.
The Scrum metrics
Scrum uses these metrics and graphs:
- Velocity: the number of story points delivered each sprint
- Commitment vs. Done: the percentage of stories that were committed and delivered
- Burndown chart: a graph that shows the evolution of the stories of a given sprint
These metrics hardly help you to improve your workflow.
Velocitydoesn’t measure the speed of delivery. It counts the number of story points that were delivered. If a story ends up taking longer than estimated, this metric would no longer mean anything.
Commitment vs. Done should never be a metric. It compares what was delivered vs. what was committed. Needless to say, this can bring people to close and reopen tasks for them to be “Done.”
The burndown chart is something that I personally never paid too much attention to — mainly because it often looked like this:
Why does this happen? You begin with an empty board and start, let’s say, three stories in parallel. These stories are likely moving forward all at the same time, which means that you’ll see these massive drops in the burndown chart. Furthermore, if you have one tester who is supposed to test all the stories, you will have a bottleneck.
The Kanban metrics
From my perspective, metrics are the strongest points of Kanban. It has a pool of different metrics that allow you to better understand what is going on with your team, such as:
- Throughput: the number of stories that are delivered within a given timespan
- Cycle time: The number of days it takes to deliver a story after it is started. This uses confidence intervals. The most common to look at is 85% confidence.
- Cumulative flow diagram: Allows you to have a visual look at how the stories flow in your board. It should look like a combed whale.
There is a plug-in for Jira that provides all these metrics out of the box. It is called ActionableAgile for Jira — Agile Metrics. You can explore your team’s metrics using the same software you use to manage your work.
We Adapted It to Our Team
Pure Kanban does not require you to do several activities that are necessary for Scrum. However, it gives you the flexibility to do them if you foresee value in adding them to your workflow.
Retrospective meetings are one of the most important meetings for a team. It’s where you can look to what you’ve accomplished, what didn’t go so well, and how you can improve. It’s a safe place where you can expose your problems and congratulate those who have done an excellent job.
Despite not being something required in Kanban (in Scrum, it is done at the end of each sprint), we saw value in it and kept it. In fact, we started to do them weekly instead of every two weeks, allowing us to have a quicker response when some problem arises. We also use these meetings to have a look over the team’s metrics and check for problems and bottlenecks.
Another optional activity that we chose to keep was the story estimation during the refinements. In Scrum, estimates are used to have a better understanding of what fits in a sprint. Since Kanban has no sprints, you would guess that this had no use.
Wrong!
Estimating a story helps to make sure that everyone has the same idea of what is to be done in a story. If someone votes 8 and other people vote 3, it’s clear that the story needs further discussion. Someone could be accounting for a problem that others are not aware of or the other way around, where someone includes extra work that is not to be considered in that story.
To estimate stimulates discussion.
When this happens, it’s clear that not everyone has a clear understanding of what needs to be done.
Another frequent scenario is when the whole team votes for high value (typically, everything above 8). A high value means uncertainty. There is either too much to do or the task has a high level of complexity that makes people uncomfortable. The best practice, in this case, is to split the story into smaller stories with more explicit objectives.
Final Thoughts
Scrum will always have a place in our hearts as the first widespread agile methodology. But as companies are turning to continuous deployment, having a timeboxed sprint no longer makes sense.
There will always be some specific projects where Scrum is the way to go. As companies become more agile over time, though, Kanban will rise to replace Scrum as the most used agile framework.
Original article published at medium.com. Read full article here