Scrum vs. Kanban - "You Talk. We Work."

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.

A New Team

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.

The Split

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.

A New Flavour

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.

Natural Experiment

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 on a little forensic investigation

It’s going to take more than one episode to do it. But in this episode, we have juat enough tom to take a 20,000 feet view of the two teams and their processes.

Team Scrum

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 for release 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.

Team Scrum - Evidence

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

Team Kanban

Moving on to Team Kanban.

As with Team Scrum, there’s a Backlog, an Agile Board - they called it a Kanban board - and a 'Done Pile'.

But theres 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.

Team Kanban - Evidence

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 stand-up.

And they are packaging and releasing. And doing so 2 to 3 times more frequently than Team Scrum.

Wrap-up

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.