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.
Hi this is Gary. Welcome to Development That Pays.
I joined a team in 2012
It was, I was told, a team 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 company went through a fairly major reorganisation.
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
was 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 asked the Lead Developer of “Team Kanban”:
“What the difference between Scrum and Kanban?”
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, along the lines of:
“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 in a little forensic investigation
It’s going to take more than one episode to do it. But in this episode, we have just
enough tom to take a 20,000 foot view of the two teams and their processes.
Team Scrum worked on two week Sprints.
On the Monday, 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, we’d play “Planning Poker”
to estimate the size each item.
And 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 have moved
at least one step.
It’s then a race - a sprint - to get everything tested and ready by 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 and made ready for
release.
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.
Let’s take stock of the evidence we’ve gathered so far:
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 ready for release
And on the afternoon of the last day of the sprint, A Retrospective
Moving on to Team Kanban.
As with Team Scrum, there’s a Backlog, an Agile Board - they call it a Kanban board
- and a “Done Pile”.
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 - around 2 to 3 times more frequently
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. And no Retrospective.
There is a daily stand-up.
And they are packaging and releasing. And doing so 2 to 3 times more frequently than
Team Scrum.
It’s interesting data, but it’s too soon to draw any firm conclusions.
We’ll collect more evidence next time.
Talk to you then.