Scrum or Kanban The undisputed heavyweights of Agile. 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 Well, that's exactly what happened In the building right behind me And I had front row seat for the whole thing. My name is Gary Straughan Welcome to Development That Pays And welcome to the site of the 1908 Summer
Olympics. A stadium once stood on this very spot. All that remains is a plaque on the wall I didn’t notice the plaque when I walked across this courtyard To join a 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. All the artefacts. All the rituals. But my attention wasn't on that "Agile stuff" It was all I could do to keep up with the other developers And so it was for a year or so And then something happened to shine a spotlight on “that Agile Stuff”. 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. What the other team was doing was 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 see 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 - never a good thing. 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: 1. An effective transition from Backlog to Development 2. A limit on Work in Progress - the number of
items being worked on at any one time 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 - 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 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 free Mini-course It's called the Scrum vs Kanban Mini-Course And it's yours to jump into today Somewhere around this video you'll find a link Click the link... and Lesson One will be with you 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.
