Scrum vs. Kanban - 'Kanban Chaos'

Team Kanban seemed to be working EFFICIENTLY. But are they working EFFECTIVELY? (Spoiler: No.)

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

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

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


Out of Team Scrum came Team Kanban. Did my ex-team mates go on to great things? Or have they thrown the Agile baby out with the bathwater?

Team Kanban has bought itself some time by dropping a couple of Agile rituals. But it's also dropped... Kanban!

Key take-aways:
- Team Scrum worked in two week Sprints
- Team Kanban worked in a continuous fashion

LINKS

-------------------
15. Scrum vs. Kanban - "Kanban Chaos"
# #DevelopmentThatPays

Last time, I told the tale of an Scrum team that split into two. One team continued with the Scrum. The other team abandoned Scrum in favour of Kanban. (If you missed the last episode, I'd encourage you to check it out. There should be a link somewhere around this video.) Did Team Kanban set the world on fire. Or did it crash and burn Taking notes --------- We learned a few interesting from 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. Q&A -- I had a couple of great questions come in after the last video - both of them relating to Team Scrum. "Why is your Scrum Sprint length 2 weeks " (The sense of the question being why was the sprint length as long 2 weeks.) I can tell you that from the team felt they were "cutting edge" for having a Sprint of just two weeks. At the time, sprits of 3 or 4 weeks were not uncommon. Any suggestion of moving to a one week sprint would have been strenuously resisted, because it would have meant doubling the frequency of the the two things we hated most: sprint planning, and packaging for release Which leads on nicely to the second question... "Why does your Scrum Team wait for 2 weeks before releasing software " This is such a great question. I say that, because it's a question that would have never occurred to Team Scrum. For us, a Sprint was something that started with Sprint Planning and ended with a Release. The Release was part of the very definition of Scrum! How's that for a limiting belief! Is Team Kanban Effective ---- 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 are 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. Kanban Fail ---- What's gone wrong here Team Kanban are missing two things that are essential to the success of an Agile team: An effective transition from Backlog to Development A hard limit on Work in Progress.- the number of items bing 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 bac

[kitdenerley]

If you're not setting realistic WIP limits then you're not really doing Kanban, you're just putting stickers on a board. Scrum doesn't stop developers from working on multiple tickets other than by the total number of stories selected for the sprint. Great presentation btw

[GregoryRayDorff]

WIP limits is what makes Kanban successful. Realize that.

[agustingambaretto]

Gary, very informative videos. And the way you set it up has made me go through the whole set of videos in one go. I dont work for soft development, but for concept development in big capital investment projects in the oil and gas. Oil and gas is one of the most retrograded industries. I am looking forward to see how can I apply this type of methology in the way we work. Thanks

[nishiprasad]

Thank you for this educative video but i have a question related to KANBAN -
How do u ensure that the team Kanban is doing priority work and its adding to the revenue for organisation. who will ensure in Kanban team that right and priority work is picked up?

[oweisman]

Shouldn't work percentage be lowered for the Kanban team? They are releasing twice as often, and surely in most organizations that incurs a pretty hefty penalty that does not involve "actual" work getting done (no items are taken care of).

[hicdee]

Why did you not compare Scrum done well vs Kanban done well? Why didn't you measure the lead times of tickets from when they are in progress to when they are in production? If both teams have the ability to continuously deliver working software at any given time, then Scrum or Kanban they are as equally as good as each other.

I still believe the maturity (understanding the Agile and XP principles) of the team is key to the success of Kanban. A mature team would respect the WIP and swarm to keep things moving. That Kanban board screams immature team who are not taking each other to task to ensure they stay within the WIP. Where is the Scrum Master who should be challenging the team on why they are ignoring the WIP?

[luckyshotjpg]

You're meant to put limits on what's allowed in certain columns if it's truly Kanban to limit bottlenecking. This video is misleading.