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?
Hi, this is Gary. Welcome to Development That Pays.
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, sprints 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:
- sprint planning, and
- packaging for release
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:
1. An effective transition from Backlog to Development
2. A hard limit on Work in Progress.- the number of items bing worked on at any one
time
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.