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

Leave a Reply

Your email address will not be published. Required fields are marked *