Episode 15 - 09 Dec 2015
Download your FREE Cheat Sheet: http://bit.ly/scrum-vs-kanban-cheatsheet
Team Kanban seem to have the upper hand: they are working more development hours, and are releasing 2 to 3 times more often than Team Scrum. But is Team Kanban performing well?
In the move from Scrum to Kanban, a few things were... lost in translation.
PS - Remember to grab your FREE Scrum vs Kanban Cheat Sheet
Last time, I told the tale of an Scrum team that split into two.
One team continued with the Scrum.
The other team abandoned Scrum in favour of Kanban.
(If you missed the last episode, I'd encourage you to check it out. There should be a link somewhere around this video.)
Did Team Kanban set the world on fire. Or did it crash and burn?
We learned a few interesting from our 20,000 foot view of the two teams.
As good forensic investigators, we should take a few of notes:
We know that Team Scrum works in two week sprints. Team Kanban works in a continuous fashion.
Team Scrum has a formal Sprint Planning session.
Team Kanban must have some process to choose items from the backlog... but we don't have any details.
Team Scrum does Retrospectives. We're not sure if Team Kanban has anything similar.
Between Sprint Planning and the Retrospective, team scrum loses around half a day of development time a fortnight.
The two week period doesn't mean anything to Team Kanban, so let's convert the number of days into percentages.
One last piece of data to record:
Team Scrum releases once every two weeks; Team Kanban releases 2 to 3 times in the same period.
I had a couple of great questions come in after the last video - both of them relating to Team Scrum.
"Why is your Scrum Sprint length 2 weeks?"
(The sense of the question being why was the sprint length as long 2 weeks.)
I can tell you that from the team felt they were "cutting edge" for having a Sprint of just two weeks. At the time, sprits of 3 or 4 weeks were not uncommon.
Any suggestion of moving to a one week sprint would have been strenuously resisted, because it would have meant doubling the frequency of the the two things we hated most:
Which leads on nicely to the second question...
"Why does your Scrum Team wait for 2 weeks before releasing software?"
This is such a great question.
I say that, because it's a question that would have never occurred to Team Scrum.
For us, a Sprint was something that started with Sprint Planning and ended with a Release.
The Release was part of the very definition of Scrum!
How's that for a limiting belief!
Looking at the two lists, it's clear that Team Kanban is doing more work.
It's also releasing more often.
But is it performing are well as the evidence suggests?
No photographs from the time have survived, but we have been able to piece together a couple of images from eye witness accounts.
Exhibit 1 is Team Scrum's board.
Nothing out of the ordinary here. Given the position of the cards, I'd guess we're looking at the state of the board from somewhere close to the end of a sprint.
Exhibit 2 is Team Kanban's board.
Blimey. A bit crowded, it's it?
And if I zoom out a little bit... there.
Have you ever seen anything like it?
Your eyes don't deceive you: the column of cards goes all the way to the floor.
(And it's not that we've caught it on a bad day. the board looked like this for at least a year.)
If I tell you that Team Kanban had four developers, you'll start to get an idea of the scale of the problem.
There must be 20 cards in this column.
Even if we assume that half of them are blocked, it still means that each developer is working on multiple tickets at the same time - never a good thing.
What's gone wrong here?
Team Kanban are missing two things that are essential to the success of an Agile team:
With so many blocked cards on the board, it's clear that they are not doing a good job of transitioning from backlog to development.
And it looks like they're on a quest to maximise their Work In Progress!
Team Scrum, on the other hand, are doing a good job in both areas. Not because they have a particular focus on these areas:
It just that more on a natural consequence of the principles and practice of Scrum:
An effective transition from Backlog to Development is a natural consequence of Sprint Planning.
An item is taken from the backlog and the team estimates its size (i.e. the time taken to complete it). There'll be discussion between the Product Owner and the dev team.
Both will have a better understanding of what's required and what's involved. This increases the chances of the item getting across the board without being blocked.
Minimal work in progress is an natural consequence of the Sprint itself:
By having maximum of "one sprint's worth" of cards on the board, the WIP doesn't have the opportunity to grow.
If there's a conclusion to be drawn, it's this: Scrum done well beats Kanban done badly.
Which begs the question: what about Kanban done well?
One of our teams is about to have its world turned upside down. I'll tell you all about that in the next episode.
Watch "Scrum vs. Kanban - "Kanban Chaos"" on YouTube.