Episode 116 - 21 Feb 2017
The recipe for a perfect Natural Experiment:
Sounds unlikely?
Well that's exactly what happened to my first Agile team. And I had a front row seat for the whole thing.
Scrum or Kanban
Which is better?
How could you find out?
What if you could take an agile team
Chop it right down the middle
Have one half do Scrum Have the other half do Kanban
And sit back and observe the result.
Well, that's exactly what happened
In the building right BEHIND me
And I had FRONT row seat for the whole thing.
~~~~~
And if your interested in scrum or Kanban
And ESPECIALLY if your interested in both
Stick around until the end and I'll tell you how to get your hands on a
free mini course. The Scrum vs Kanban mini course.
My name is Gary Straughan
Welcome to development that pays
And welcome to the site on the 1908 Summer Olympics.
A stadium once stood on this very spot. But now that all remains is this plaque.
A plaque I didn’t notice on my first day with this… err… major broadcaster.
I was about to join a team that I was told “did agile”
And I could see from the get go that they weren’t doing it by halves.
There’d clearly been lots of training. They had all kinds of tools. They were doing all kinds of 'rituals'.
But at the time, my attention was elsewhere.
I’d never worked with so many talented developers. So I had my head down/… focussing on the code. On trying to keep up.
It wasn’t until I’d been there about a year that something happened
To shine a spotlight on “that Agile Stuff”.
The department reorganised.
My team was split in two.
Although reporting lines changed, the seating plan didn’t.
There was one outward indication of change:
where there had been one agile board, there were now two.
And we did two stand-ups every day:
ours at 10:00am, theirs at 10:15.
Ever-observant, it took me a couple of weeks to notice that
the other team was doing a different 'flavour' of Agile.
I hadn’t realised that there was more than one flavour of Agile.
What my team was doing was, called Scrum.
The other team was doing something called Kanban.
Kanban? Really?
This was a word I knew from way back.
But I knew it in the context of manufacturing.
I couldn’t immediately see how it applied to the process used by my former teammates.
So I talked to the Lead Developer of 'Team Kanban' about it.
'What the difference between Scrum and Kanban?' I asked
He was ready with an immediate answer:
'You Guys Talk About Work. We Do Work.'
Ouch!
In that moment, I learned an important lesson about Agile:
It can be an emotive issue.
Beliefs can be deep-seated.
The Team Kanban Lead Dev clearly thought that Kanban was better than Scrum.
I held the opposite view.
My view was both strongly held
and completely without evidential foundation.
I’m a little older now. And, I hope, a little wiser.
I can now see that the team split was a perfect “Natural Experiment”.
You know the kind of thing:
“Take two identical twins. Separate them at birth. Feed one Scrum. Feed the other Kanban.
Observe the result.”
So I hope you’ll join me on a little forensic investigation
Starting with a 20,000 view of each team's processes.
My team - let’s call it "Team Scrum" - worked in two week Sprints.
At the beginning of s Sprint, we’d take ourselves off to a quiet part of the building for a Sprint Planning session.
The Product Owner would select items from the backlog,
and we’d play “Planning Poker” to estimate the size each item.
We’d continue until we had roughly one “Sprint’s worth” of cards.
Sprint Planning over, each developer would pick up a card and set to work.
Every morning there’d be a stand-up - 10 am on the dot.
And so it would go on day after day,
with the cards gradually making their way across the board.
By the about the Tuesday of the second week,
we’d expect all of the cards to have moved at least one step.
It was then a race - a "Sprint" - to get everything tested and ready for release on Friday.
We didn’t always succeed in getting everything across the board.
Any item that failed to make it would be “recycled” into the next Sprint.
On the Friday morning, everything in the release column would be packaged for release.
Oh, and one last thing to round out the Sprint: a Retrospective.
A chance for the team to get together to reflect on what well,
to discuss what could be improved
and to commit to one or two action items for the following Sprint.
Taking stock of the evidence:
There’s a Product Backlog The Agile Board And a Done Pile.
There’s a Two week Sprint with a sprint planning session at the beginning.
Each day after that, a Daily Scrum Meeting. (aka a Stand-up)
At the end of the process, all those cards that have made it to the final column
are packaged for release.
And on the afternoon of the last day of the Sprint: a Retrospective.
Moving on to the other team: “Team Kanban”.
As with Team Scrum, there’s a Backlog, an Agile Board
they called it a Kanban board -
and a 'Done Pile'.
But there’s no Sprint.
Instead of a group of cards making their way across the board in a specific time period,
cards flow across the board continuously.
With no specific release day, it’s up to the team to decide when to package for a release.
They’d typically wait for a fairly significant feature to be be finished and tested before packaging.
In practice that meant releasing once or twice a week - 2 to 3 times more often than Team Agile.
Taking stock of the evidence:
There’s a Product Backlog, a Kanban Board and a Done Pile.
No Sprint. No Sprint Planning. No two week period. No Retrospective.
There is a Daily Standup.
And they are packaging and releasing.
And doing so 2 to 3 times more often than Team Scrum.
So much for 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.
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 as 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
What's gone wrong here?
It seems to me that in the move from scrum to knaban,
something has got lost in translation.
Actually, two things:
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!
What's interesting is that Team Scrum is doing a good job in both areas.
And not because it has a particular focus on these areas:
it's happening as a natural consequence of the principles and practice of Scrum:
An effective transition from Backlog to Development is a natural consequence of Sprint Planning.
And a limit on work in progress is a natural consequence of working in Sprints
An item is taken from the backlog and the team estimates its size
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 and natural consequence of the Sprint itself:
By having just "one Sprint's worth" of cards on the board, the WIP doesn't have the opportunity to grow.
Can we draw any conclusions from what we've seen so far?
I'd suggest the following:
Scrum done well beats Kanban done badly.
Which begs the question:
what about Kanban done well?
One of our teams is about to find out. In a most unexpected way.
It was a dark time for Team Scrum.
Our super-awesome project manager left the company.
News came in that an external "Agile Coach" was going to be “parachuted in”.
Someone looked him up online.
Very high profile. Very expensive And very, very… KANBAN!
As I said earlier, people who “do Agile” often have strongly held views about how things should be done.
And our ongoing grudge match with Team Kanban had only served to entrench our view
that Scrum was awesome and Kanban was rubbish.
So we were ready for this so-called "Agile Coach".
We expected him to be pushy and directive. And we intended to push back. Hard.
As it turned out our new Agile Coach - let’s call him The Agile One -
was neither pushy nor directive.
At our first meeting he said that he had a new (Agile) board that he’d like us to try.
But only if we wanted to to.
He unrolled the A2 paper that he’s brought with him.
The key to it, he, explained, it that each column is wide enough for a single post-it note.
And high enough for five. That's it.
“This is important. By limiting the number of cards in each column,
we make sure that things get across the board as quickly as possible.”
A couple of team members raised concern whether a PostIt would stick long enough
,… and whether it might be necessary to bring some BluTak into play.
I smiled to myself.
If our “resistance” centred around the relative adhesive properties of Postits and BluTak,
the Agile One had already won.
And so our Kanban journey began.
The paper board - together with our winning combination of PostIts AND BluTak
We had learned our first lesson.
At the time of his arrival, several cards on our board were blocked.
The Agile One asked about one of them.
"We're waiting for so-and-so to get back to us” I said.
“What can we do to move that along?”, asked The Agile One
“ I’ll email him today”. I replied.
WRONG ANSWER!
“Where’s his office?”
“In the next building.”
"Let's go and talk to him."
“When?"
"Right now”
And off we walked off together.
And we found the person. And we had a relaxed conversation.
The Agile One asked questions. And what was blocked became unblocked.
Effortlessly.
None of us could match The Agile One’s ability to make problems disappear,
but we did - in time - learn the value of talking to people face to face to get issues unblocked.
And - in the case of new cards - to make sure that they didn’t get blocked in the first place.
That was our second lesson.
Little did we know, there wouldn’t be a third.
At least, not from the Agile One.
One morning, The Agile One brought a guest to stand-up.
It transpired that The Agile One was moving on to bigger and better things.
The new person was his replacement.
If The Agile One was a little bit Obi Wan Kenobi, the New Guy was more Yoda:
a little bit annoying, and very into "basic training”.
Where the teaching of The Agile One had been effortless,
with the New Guy it was more the school of hard knocks.
He didn't waste any time:
"Release more often, you must”.
We explained that releasing in this place was a painful process:
time consuming and prone to error.
New Guy let us know that it was his belief that if you're not good at something,
you should do it more often.
The last thing we wanted to hear. And the first thing we needed to learn.
It wasn't long before we were releasing more often than any other team in the company.
And doing so with the lowest failure rate.
We had learned our third le…
Actually… that wasn’t the third lesson.
At least, it wasn’t ALL of the third lesson.
New Guy also forced us - against our will - to do regular Demos to stakeholders.
And then there were his views on test failure.
The man had a eagle eye.
The moment he saw a card moving to the left,
he’d want to know why, and he’d wanted to know RIGHT NOW.
Jeeez, has this guy never heard of the cost of context switching?
I’m sure he had. But he wanted us to feel the pain of card “moving left”.
You see, what he was teaching us
was the importance of moving to the right.
THAT was our third lesson.
It’s time for the final analysis.
A clear win for Kanban? Or does Scrum deserve Olympic Gold.
I’ll give you my thoughts in a moment.
But first the small matter of the Mini-course I mentioned at the beginning.
If you’re interested in Scrum and Kanban then I have a real treat for you.
I’ve put together a Mini-course , the Scrum vs Kanban Mini-course.
That covers the basics of Agile and Scrum and Kanban.
The price it right - it’s free - and it’s ready and waiting for you
You’ll find a link on or around this video.
Click the link, follow the instructions and dive into the first lesson today
Since walking out of this building for the last time - some years ago -
I’ve had the pleasure - and sometimes the pain - to work
In a whole range teams. Some using Scrum. Some using Kanban.
I’ve seen both done well. And both done… REALLY REALLY badly.
For me, the question has ceased to be “which is better?”
The question is, which is best suited to this team… to this situation.
I hold them in equal regard…
But perhaps you… have a preference? A favourite?
Let me know in the comments below.
Thank you very much for watching
If you enjoyed this episode, please click to like,
Share it with your network.
And hit the logo - right here - for a new episode every Wednesday.
Watch "Scrum vs Kanban - An Olympic Battle!" on YouTube.