Episode 100 - 27 Sep 2017
This is a story of Two Agile Teams.
More correctly, it’s the tale of one Agile Team that split into two Agile Teams.
What makes the story interesting is that it was more than just an organisational separation.
It was an Agile separation:
Will it all end in tears?
Remember to grab your FREE [Scrum vs Kanban(http://www.developmentthatpays.com/cheatsheets/scrum-kanban)
This is a Tale of Two Agile Teams.
More correctly, it’s the tale of one Agile Team that split into two Agile Teams.
It was more than an organisational separation.
It was an Agile separation.
It was 2012 when I first walked into the offices of the BBC.
The same time and the building as these guys…
Never saw them. Which is strange.
The software team I joined was one, I was told, that 'did Agile'.
At the time, I knew very little about 'Agile'.
But 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'.
We’ll get into the specifics of how the team worked in a minute.
Fast forward a year and 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.
Oh, 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 went to talk to the Lead Developer of 'Team Kanban'.
'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 - aka a Daily Scrum - 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:
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:
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 - never a good thing.
What's gone wrong here?
It seems to me that in the move from scrum to kanban, 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 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 Development 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.
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 PostiIs and BluTak - taught us to to keep our work in progress under control.
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 know.
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 failures.
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.
Earlier this year I gave a talk. You know, in front of a room full of people.
It was on the subject of Agile, and it concerned an Agile team that, you know, split in two...
In preparing for the talk, I tried to classify the Agile teams I'd been a part of.
I came up with a hierarchy of sorts:
The Agile Team that I joined in 2012 was still wet behind the ears. There was no deep understanding of Agile, but it was good at following to the agile rules.
It was a perfect example of Mechanical Agile.
Mechanical or not, it worked. It was effective. More effective than any non-Agile team I've worked with.
Under the tutelage of The Agile One and New Guy, my team achieved Competence. And was on the road to Enlightenment.
Which leaves us with Team Kanban.
The members of Team Kanban thought they'd found a way to eliminate the waste that they saw in Scrum.
But they removed more that they'd intended.
They ended up with something that was less than Agile.
They ended up with something... superficial.
They ended up with something... that didn't work.
That's my story of my "Agile Awakening"
And now, I love to hear yours.
Especially if you've experienced more than one "flavour" of agile.
Tell me all about it in the comments below.
Watch "Scrum vs Kanban: Two Agile Teams Go Head-to-Head" on YouTube.