Scrum vs Kanban: Two Agile Teams Go Head-to-Head

This is the tale of two Agile teams. It wasn't just an organisational separation: it was an AGILE separation.

= = = = = = = = = = = =

New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"

= = = = = = = = = = = =


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:

- One team continued as before - with *Scrum*
- The other team dropped Scrum in favour of *Kanban*

Will it all end in tears?

-------------------
100. Scrum vs Kanban: Two Agile Teams Go Head-to-Head
#ScrumVsKanban #AgileScrum #Kanban #DevelopmentThatPays

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. Act One 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. The Split ----- 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. 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 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. Natural Experiment ---- 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. Team Scrum ----- 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: There’s a Product Backlog, the Agile Board, and a D

[Developmentthatpays]

This one is on the long side - you have been warned!

[rcronk]

In my experience, Kanban works well for service-oriented teams like IT, or any team fixing an ongoing stream of bugs being found, or fires that need to be put out. Scrum works well for teams building features/stories as part of a product to be released. Many teams do both of these kinds of work and switch between them based on what's more efficient at the time. Kanban is useful for pre-emptive interruptions by fires. Scrum is better at keeping non-fires moving along without being starved by firefighting. Kanban is more tactical, scrum more strategic. A balance of both is a good thing. I didn't see this in the video so I figured I'd share.

[OmaticFever]

Great explanation of the different Agile methods. I can see how Agile, done correctly, doesn't make you want to end your life. My company's digital transformation was done so horribly wrong. "Blocked" was code for "go to that department's VP and make the person that I think can solve my problem work on my problem until its resolved even if he has other priorities" and their were no WIP limits. I long to work at a company with better culture.

[christerpettersson]

This video have transformed my view on agile. Three ongoing non-it projects on my workplace switched from Agile sprints (wouldn't call it Scrum), about five months ago, to Kanban, and the speed of all these projects have increased significantly. Thank you!

[eeyore]

This is the MOST entertaining video I have ever seen to explain this topic. Most of the videos/courses out there are so boring and dry, this video makes it sound like I am watching a Bond movie. :) I must admit that I shared some of the same hesitations like the storyteller when I first started Scrum. Not that I am entirely sold at all aspect of things, but now I see how I should look at things with a bit more positivity before rejecting them.

[milojeffrey]

Development that Pays, Thank you for speaking slowly and clearly. Not all Youtube educators grasp that students hearing the information for the first time need it delivered slowly and clearly. As a Yank, I find your smashing British accent most enjoyable. Your videos are fantastic. Bravo!

[BolaAdesope]

This is probably the most efficient way to drive home any concept. The theatric theme made it all fantastic. Cool stuff. Just FYI, your subscriber base just grew by one....

[HippocraticDev]

"Why's this blocked?"
"I'm waiting for so-and so to get back to me"
"What can we do about that?"
"I'll email him today"
"Where's his office?"
"Bangalore, India"
"oh ok.... send him an email then I guess"

[kevinsusko]

Thank you Gary ... very nice (and clear) description of Scrum vs Kanban. Coming from a client consulting view point, our "transition" from Scrum to Kanban was by accident (or need if you have your "lead" hat on) by keeping up with priority releases which never fit into the 2-week sprint idea. The "limited scope" of the DEV column is a what keeps the team sane but also allows a semi-structured view of what the next release will look like (quite scrum-like ... without the anticipation of Friday's meeting). Your video clearly shows that it's not a deviation from the structured Agile method (which sounds like an oxymoron) without cause but there is a way of keeping Kanban from becoming the Wild Wild West of releases. Keep the videos coming!

[lifesacardgame]

Just found this. Made me laugh and cry in equal measure because this is where I'm at. Thank you for making me feel that I am not alone!

[alanhunt]

I enjoyed the light and easy manner in which you defined the difference so people could readily understand without being to process-driven. It is enlightening to read different peoples current experience level and it's easy to see those who are still fighting the emotive struggle... My story will have to be short, but I recall a global telco when it started its transformation journey, we had multiple DevOps teams all offshore working to different sprint cycles, complicated by onshore program teams applying different sprint durations and just to add a little more fire to the story we had recently qualified CSM scrum masters i.e. (former project managers) drawing up classic DESIGN/BUILD/TEST MS schedules in the background, across 47 two week sprint iterations.. It was a wonderful experience because I believe you learn a lot more from what does not work, rather than those deliveries which perform like clockwork. :-) The scrum coaches could not resolve the issues!!

[crazydmd]

Thank you for posting an informative video that addresses an important topic.


We use Scrum but we also utilize the Kanban boards in Jira. At about 7:00 minutes, you attempt to draw a comparison between Team Scrum and Team Kanban with 95% time working vs. 100% time working, respectively, but one cannot compare these two percentages as quantitative measures since Team Scrum may be working more efficiently due to better task planning, as is the case in my experience working on both Scrum and Kanban-only teams. In Scrum, the whole team is involved in estimating the number of Fibonacci points to assign to a task and therefore a consensus-driven estimate is more accurate.


I’d also like to point out the “gamification” of the Scrum process provides a daily reward for progress made on a given task. Deducting a few more points from a task occurs daily vs. a task in a Kanban that could take an hour or several days; you’re not "rewarded" as often. The point system in Scrum enables the Scrum master to visualize team progress for a Sprint with burndown charts, and act if the team is running behind. With Kanban, you can only measure progress by the number of tasks in the Completed bin and it's not as granular a measure of progress.

[bhaibhai]

Quite interactive to inform about terms of Scrum vs Kanban..Usually we will prefer Scrum: when we have good number of stories well detailed and can start with them for couple of sprints, rest of stories still needs grooming..Also when we have to behave emperical approach in mind(considering previous sprint experience and improvise current sprint planning and progress as we do not overall vision on to reaching the closure of project)

[brutusmaximumus]

Back in the early 2000 or maybe 2001 I was tasked with creating a digital kanban workflow system for supply catalog digitization, multiple teams of people scanning, OCR'ing, categorizing, QA'ing, etc. paper catalogs into digital format. I'd never heard of kanban at the time, but one of the first things I learned and had to put in my solution was the concept of queue limits. Reading up on the history of kanban and its origin in Japanese manufacturing was the concept of eliminating bottle necks by stopping all upstream work until the bottle neck was relieved, once everything grinds to a halt and everyone is running around with their hair on fire it becomes super easy to go do what it takes to remove the bottle neck as opposed to letting it sit there and moving on to something else.

[webanyware]

Agile or Kanban, working on one task/story that reaches completion at a time is the way. Great video! Thanks

[kenechukwuujam]

Thank you so much for this lesson. I was so captivated by it. So in summary, for Scrum and Kanban, let fools contend, whichever is properly done is the best option (apologies to Alexander Pope).

[cigarsense]

I think an important dimension of choosing between Scrum & Kanban (or finding the right mixture of the two) is the element of "planability" of the work. That is, most teams I work with deal with a mixture of planned work (e.g. new feature development) and unplanned work (e.g. responding to defects, maintenance upgrades, etc). The latter I think of as unplanned because we typically won't know weeks in advance exactly what will need to be done. We only know we will have unplanned work cropping up, we'll need to respond quickly, and if we don't allow some capacity margin for it, our sprint goals are likely to fall by the wayside because of it. With these teams we can usually judge based on history how much capacity should be reserved for unplanned work, so we can avoid over-planning the sprints.

Hence understanding how work flows to your team for me is a really important aspect of choosing the right method(s) - 100% Unplanned Work => Kanban, 100% Planned Work => Scrum, Mixture of the two => "Scrumban" in which we have sprint goals in terms of specific planned work items we'll complete, and SLA for responding to unplanned work items...

[TillyPick]

I call what our U.S. based operations and offshore development team did "dirty agile" because we colored outside the lines of agile to push ahead within a very dynamic organizational and business environment. We took those liberties when changing requirements or priorities required it. All in all, we were a rather high performing team, albeit still not perfect as could be measured by the business outcomes.

[davidchung]

This must be the first work related video that I actually found interesting! Great stuff here!

[tarvinder]

I knew nothing of these topics and after watching this video I have a lot of info in my head now. Thanks.