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

Подписаться 74 тыс.

Просмотров 447 тыс.

50% 1

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"
→ www.developmen...
= = = = = = = = = = = =
Download your FREE CHEAT SHEET: www.developmen...
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
• Scrum vs Kanban: Two A...

Опубликовано:

26 сен 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 371

@Developmentthatpays 7 лет назад

This one is on the long side - you have been warned! Remember to grab a copy of the Scrum vs Kanban Cheat Sheet: www.developmentthatpays.com/cheatsheets/scrum-kanban

@MohammedNoureldin 5 лет назад

It is awesome, may I ask how did you draw/create the infographs in the cheatsheet? and in other video you used them with animations. How did you do all of them? They are really brilliant.

@DonutQueen4242 2 года назад

I just see ads to pay for courses. I don't see the actual sheet download anywhere. Can you help?

@rcronk 5 лет назад

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.

@Developmentthatpays 5 лет назад

This is such a great point - and one that I haven't really covered in my videos so far. It does seem to be commonly accepted that Scrum is better for "new and different" and Kanban is better for "business as usual"... but I'm not sure I agree. Certainly I've seen Kanban work well - brilliantly! - in "new and different" projects. (I concede that it's hard to imagine Scrum in a "fire-fighting"/ reactive situation.... but wonder if there are situations where Scrum might be the cure for constant fire-fighting.) Another way to decide is based on the team's experience. Your team(s) have the opportunity - and ability - to mix and match, which is awesome. But for a team that's just starting its Agile journey, the "structure" of Scrum - and the volume of support materials - might make it the better choice. Would love to hear your thoughts.

@rcronk 5 лет назад

Scrum also helps the team focus on a set of items and complete and demo those items. This gives the team a sense of accomplishment. Kanban can feel like a never ending stream of things to do without an end in sight. I just switched a DevOps team from Kanban to Scrum this past week and they are loving it. It’s giving them a sense of completion and focus they lacked before and it’s also creating pressure against the constant firefighting they have dealt with this past year. The sprint acts as a (partial) barrier against the constant squeaking wheels of firefighting and lets them do some new development - sharpening the saw. It’s been a good change for this team. Again, I think both workflows are decent. Pick the one that works best. And remember the sprint backlog is just a focused Kanban too. :)

@joelbrighton2819 5 лет назад

I've worked on both types of teams and, honestly, don't understand the "Scrum is better for new and different" philosophy. Personally, I think the most important factor is the "team" itself, specifically, the personalities and work-style preferences of the people on the team. I always feel that a team should chose a process, and then adapt and refine based on what works best for them. If that ends-up as Scrumban or some bastardised variation of an Agile process then so be it; as long as the team is working efficiently and is comfortable with the process. If anyone wants to try a more Scrum-like approach - try it. If it works great, if it doesn't revert!

@ericcartman5166 5 лет назад

I agree 100%. I've worked in both types of teams with exactly the main purpose that you mention respectively and it felt very suitable.

@marcellinnenfelser7056 5 лет назад

In my opinion it is not about Kanban or Scrum, but about the right process for the team and the work they have to do. I personally don't like the fixed sprints because I often saw that not finishing the sprint (not meeting the commitment) lead to a bad mood of the team. But this depends on the culture of the company and even the areas the team members come from. Kanban is more of a framework for your process than a real process and a way of thinking. It gives you essential rules like the WIP for every column, but also tells you to talk about rules that don't work and not about people that made mistakes. This way of thinking keeps away many personal issues people working closely in a team may have. For the record: there is no rule in Kanban that keeps you from time boxing in form of sprints or regular release cycles. You are free to do that, but you are not forced to.It offers a wide tool belt like Service Classes etc that save you from unnecessary estimation work and only estimate task with a fixed date, queue replenishment meetings to have freedom to do your work for a period of time and so on. TLDR; Learn Scrum, learn Kanban, know your tools, learn the way of thinking agile (the whole team) and let the team tailor and improve their own process.

@HippocraticDev 4 года назад

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

@robalderden5888 4 года назад

No, not email. Call, skype, webex, do whatever to be as face to face and synchronous as possible. And regularly buy a ticket.

@vivenams3559 4 года назад

@@robalderden5888 Spot on!!!!!!!!!!!!!!

@lifetheoryoptimal3297 4 года назад

We're going to India.

@techviking23 3 года назад

Haha great point! So many software teams now has part of their teams in India to lower $ costs. But rarely do they compare that $ savings to the costs of increased Cycle Time and reduced quality. Note it's not too difficult to quantify increased Cycle Time and reduced quality to $.

@BolaAdesope 5 лет назад

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

@christerpettersson7943 4 года назад

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!

@eeyore345 5 лет назад

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.

@OmaticFever 3 года назад

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.

@Developmentthatpays 3 года назад

I feel your pain! Sometimes I wish I didn't know how good things _can_ be... because most of the time they are not.

@milojeffrey6457 4 года назад

Development that Pays, Thank you for speaking slowly and clearly. Not all RU-vid 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!

@Developmentthatpays 4 года назад

Milo - thank you! Lovely comment.

@eponymousIme 3 года назад

Yes! I just left a similar comment on another of his videos. Aside from needing new info delivered more slowly than conversational speech, *articulation matters.* I subscribed to his channel based 70% on the fact that his content is easy to understand *without* the closed-captioning feature.

@lifesacardgame6454 4 года назад

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!

@alanhunt7082 5 лет назад

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

@webanyware 5 лет назад

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

@Developmentthatpays 5 лет назад

Yes, agree 100% 👍

@crazydmd 5 лет назад

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.

@Developmentthatpays 5 лет назад

Some great points here. 100% agree that "the whole team is involved in estimating... " is enormously beneficial - but not for the reason you state: the value is the discussion, and not the Fibonacci points outcome. (Indeed, I've come to see the Fibonacci points outcome as harmful.) I confess that I have never heard of "knocking points off" a task during a Sprint; I wonder how common that is ? so I can't comment on the "gamification" effect. (For me, Scrum's strongest "gamification" element is the Scrum itself. Mix in a compelling Sprint Goal and miracles can happen.) Have to ask: in what way do you "act" if the team is "running behind"?

@davidchung3136 5 лет назад

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

@Developmentthatpays 5 лет назад

Thanks David. Glad you enjoyed it!

@brutusmaximumus 5 лет назад

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.

@bhaibhai2012 5 лет назад

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)

@ivan-parra 3 года назад

I've never commented on a youtube video before, but this video is great, and the Yoda "Deliver more often, you must" joke was hilarious

@Developmentthatpays 3 года назад

Your first RU-vid comment was much appreciated! Thank you!

@tomhollins9266 5 лет назад

Excellent explanation with a Use Case feel. Well described using the WHY of each item. That is usually missing in many learning adventures. Without WHY you have Mechanical process. ISO 9001 type of process where as long as you document the mistake, you will repeat it until someone identifies it as a mistake (like New Guy and the Agile One did). Kudos to you.

@Developmentthatpays 5 лет назад

Tom - lovely comment. Much appreciated. 👍

@mogwaii 5 лет назад

Thank You! This material is incredibly easy to follow and digest. Moreso than anything I have ever seen. I even got a cheat sheet just for coming here. Best day ever!

@tarvinder91 4 года назад

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

@rhsandeep 5 лет назад

Excellent Tale. Very gripping , explained lucidly. Loved the way you introduced Release faster, Demos , Move to right ..

@Developmentthatpays 5 лет назад

Glad you liked it. It's all about moving to the right!

@kenechukwuujam1479 5 месяцев назад

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

@idselseno2306 7 лет назад

Haha! My freelance project is still on the level of 'Superficial' agile. All devs commit at least 20 hours a week and all work remotely. This has been really quite a challenge for the past months. This video really enlightens all! Keep up the golden content!

@Developmentthatpays 7 лет назад

@smalltiny 5 лет назад

I resisted this video for a while but boy was it entertaining and educative. Thanks for sharing the story!

@Developmentthatpays 5 лет назад

That's great to hear. Thank you!

@vivenams3559 4 года назад

Its amazing! I just shared it with my course mates!

@cigarsense 4 года назад

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

@ahmedabdelfattah443 5 лет назад

Great video. I worked on 2 projects, one was painful with frequent 2-weeks releases and the other with a massive work-in-progress swimlane. I never really knew that this was the particular difference between scrum and kanban till now.

@melinaaghasi8329 4 года назад

فروش دختران ایرانی توسط آقا زاده ها و سکس با آنها

@melinaaghasi8329 4 года назад

سکس با دختران ایرانی توسط شیخ های عرب

@melinaaghasi8329 4 года назад

همراه ویدیو

@melinaaghasi8329 4 года назад

در این موارد که جرات گفتن حقیقت را ندارید ، اصلا در سایت راجع به آن صحبت نکنید

@joshchapman8426 5 лет назад

This is absolutely fantastic! Looking forward to watching more content like this!

@Developmentthatpays 5 лет назад

Glad you liked it!

@jeffibuilt 5 лет назад

The terms used that you learn about kanban are things taught in scrum. "Move to the right" is the same thing as "get to done" in scrum. Installing WIPs in scrum would be a great idea but also understanding that development team should commit to getting done. The coders that run out of dev work on Wednesday of the last week of the sprint now shift to a tester to ensure our work gets completed and we meet our commitment as a team. Overall great video and informative

@Developmentthatpays 5 лет назад

Agree there's much commonality. Glad you enjoyed the video 👍

@TillyPick27 4 года назад

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.

@larelekman 5 лет назад

I really appreciate the high production value of your video. It also has some useful insights and empirical perspective (based on real-world events). Unfortunately, the video (and the promoted Cheat Sheet) also present so many misconceptions (on purpose?) about Scrum and Kanban, that it's hard to know where to begin. Anyways, thank you for sharing your experiences in an engaging format.

@gregmyerscough2919 5 лет назад

fun, light hearted presentation with all the info needed - great video :)

@joycharles9766 7 лет назад

Very creative way of explaining the two methods! It made something that might otherwise be boring, quite entertaining!

@Developmentthatpays 7 лет назад

You're right: it can be a boring subject. Glad I didn't put you to sleep :)

@arturoportable 7 лет назад

Very Happy 100th episode Gary. Thank you very much for your efforts and your awesome and useful videos. Hope we'll enjoy the 200th!! ;-)

@Developmentthatpays 7 лет назад

Wow. The 200th. I need a drink... :)

@TheEmpressAthena 5 лет назад

This was my first video and really loved it! Looking forward for more fun and educational content.

@necrifed 2 года назад

This just kill me "Release more often you must", hahahaha🤣

@Developmentthatpays 2 года назад

Glad you liked it... I am 😂

@Villafountain 5 лет назад

My team is about using Kanban and I found this video has offered very useful guide to jump start.

@Developmentthatpays 5 лет назад

Delighted to hear it - thanks for your comment!

@robtayler9740 4 года назад

great video! ive worked in a mixure of agile and kanban and as long as each task is thought out WIP is limited, and ready to move right it isnt a problem.

@Developmentthatpays 3 года назад

Those are indeed the secrets of success!

@randoveizi9595 10 месяцев назад

nothing beats teaching by storytelling.. great work!

@Developmentthatpays 8 месяцев назад

Thank you! You just made my day!

@chrisfairclough7531 5 лет назад

Thank you for producing such an entertaining view of Scrum vs Kanban. I am just starting to scratch the surface of Agile, even though I was on a project team that transitioned to Agile from basically nothing specific. I challenged the principles and gave our Agile coach a hard time, however he held his ground and pushed me enough to help me see the practical benefits to our team. According to your video, we were a Scrum team, although no one ever used that term, hence my lack of understanding. I have subscribed and look forward to exploring the other videos you have produced in an effort to expand my knowledge of and appreciation for Agile. There was just one thing that puzzled me at the end of this video. You finally referred to your team as, "My Kanban Team", and then the other team as "Team Kanban". Was this intended or did you mean to say "My Scrum Team"? I may have missed something along the way and would like to know what, so that I fully understand the conclusion. Many thanks Chris

@arunadhikari2050 5 лет назад

yeah, seeing 'my kanban team' was confusing

@taranouveau5454 3 года назад

Loving the voiceover. "No photographs exist from the time period..." V entertaining.

@Developmentthatpays 3 года назад

Hee hee. Glad you liked that bit. 😂

@mentarq 5 лет назад

kanban pic in 7:59 is totally wrong, since the most important part is missing: the Work In Progress limit

@mc_brown_bear 4 года назад

yes it is, and OP is ack-ing that in act 3

@lynxes1 5 лет назад

Excellent! Thank you so much! Funny, gripping ...and educational ! The perfect combination!

@Developmentthatpays 5 лет назад

Lovely comment. Thank you!

@this.is.lapc506 5 лет назад

One of the best training videos I have ever seen in RU-vid.

@Developmentthatpays 5 лет назад

Really glad you enjoyed it 👍

@brentonkelly3780 4 года назад

You are a good story teller Gary. Very insightful and interesting!

@Developmentthatpays 4 года назад

Thank you - that's very nice of you to say so!

@mycommerceUSA 5 лет назад

Good video. One thing that's not clear or mentioned is backlog refinement for Kanban teams. How and when are items in the Product Backlog groomed, refined and sized by the team?

@General.Videos 3 года назад

Awesome storytelling of real agile teams Sir! It’s a choice between natural consequences and a person dependency - The Agile One. A general approach is to go for the first one.

@Developmentthatpays 3 года назад

Agree 100%!

@rodrigoborcat 6 лет назад

Quick and enlightenment explanation about the main differences between those two methods, sometimes I feel tired to argue in favor of the Scrum against Kanban, guess I will have to send this video to some people. Congratulations!

@Developmentthatpays 6 лет назад

Glad you liked it. Feel free to share it far and wide :)

@Karen-2023 3 года назад

Many thanks for an amusing comparison using Charles Dickens' famous work. As I am not working, it is great to find the many educational resources on RU-vid.

@chrisjoynt1982 4 года назад

I really enjoyed your video, I work for a healthcare system delivering data solutions. We use JIRA and it is painful. I would like to start experimenting with a kanban workflow, up to this point we have been managing our work in sprints.

@leonhernandez639 4 года назад

Nice presentation and the presenter has a clear preference to favour Scrum due to his experience. And what he presents about Kanban is a poor implementation of Kanban. In Kanban, the capacity limit is set, and stories are not added into the Kanban board if there is already a bottle neck.

@Developmentthatpays 4 года назад

Interesting you should say that. If anything, my bias is in the other direction: I must have over-compensated! You're quite right: what I presented is a VERY poor implementation of kanban - "kanban in name only".

@monday6740 5 лет назад

So, as a summary: if you want things to move, go to the person's desk. It also implies that teams can't work if they are remote, especially if they never meet each other. Nothing really surprising ..

@Developmentthatpays 5 лет назад

I guess we now have "virtual" ways of "going to someone's desk".

@minwu2073 4 года назад

We worked on both for at least 2 years each, we find surprisingly Kanban is better than Scrum. It's really a case by case, the team and the product are different from case to case, so my lesson learned might not apply to others. Here is the details about how we avoid 20 items in the "Build" stage. It's the "Agile One"'s responsibility to move the items and make sure each developer is not assigned more than 3 at a time, once we have this rule in place, the flow is very smooth. Also, Kanban has the concept of timeboxing an item if it's dragging to long, that eliminate the long standing blocker as well.

@MuggsMcGinnis 5 лет назад

Is there any reason you can't run both boards for large projects? Scrum the large-scale issues and Kanban near-term work?

@HeavyAndLow 5 лет назад

Would a post-it stick long enough? LOL hilarious - nice video

@Developmentthatpays 5 лет назад

These things are important! 😂

@isamdnor89 4 года назад

@@Developmentthatpays It means, the work needs to be done before notes fell off the wall

@DanielMatthews2000 4 года назад

Great video, story, and visuals. Well done!

@Developmentthatpays 4 года назад

Thank you!

@MarkBurville 3 года назад

Brilliant video, I would also add that comparing 1. mechanical scrum to 2. mechanical kanban to 3. good kanban - "my kanban team", seems to miss a clear comparison to 4. good scrum.

@Developmentthatpays 3 года назад

Glad you enjoyed it. And you're right: the summary/comparisons should have been clearer.

@MarkBurville 3 года назад

@@Developmentthatpays thank you for your kind comment, I did not go into detail but "Brilliant" means "Brilliant", brilliant video, brilliant narrative, brilliant story, brilliant creativity. Stay Amazing Gary 🌟

@jeffrapport3914 5 лет назад

Very clearly thought out and well presented synopsis. Thanks!

@Developmentthatpays 5 лет назад

Thank you. Really glad you liked it!

@tinnguyen2219 5 лет назад

Thank you for sharing this useful data! Greatly appreciated.

@Developmentthatpays 5 лет назад

You're very welcome!

@thecrafter694 5 лет назад

Never saw such an interesting comparison. Great stuff

@Developmentthatpays 5 лет назад

Thank you! Really fglad you liked it 👍

@FranciscoVegagranmusica 6 лет назад

it`s amazing the way to be explained, I love this videos and I have turned on the ring bell and also thanks for each email received, congratulations Gary!!

@Developmentthatpays 6 лет назад

Excellent - great to have you onboard!

@tigere28m17 2 года назад

This is one of the best lessons I ever had , amazing

@Developmentthatpays Год назад

Wow. Thank you!

@lynnjackson1793 7 лет назад

Only 500 views? This deserves a wider audience.

@Developmentthatpays 7 лет назад

That's so nice of you to say so! Thank you.

@Stevensterni 5 лет назад

What I am missing within Kanban is the commitment of the team. By planning, estimating and committing to a sprint, the team is following a goal, which is comprehensible.

@Developmentthatpays 5 лет назад

Agree that the Sprint Goal is one of Scrum's more powerful aspects - for those teams that use it.

@johnlittle5295 4 года назад

Many Thanks for the easy to grasp comparison. Was curious why the "Scrum Team" was not called out and included in the "Epilogue" section? Was "Agile Team" used as a substitute name for "Scrum Team"? Curious to know your thoughts on which category/s the "Scrum Team" landed in (Superficial, Mechanical, Competent, Enlightened)?

@Developmentthatpays 4 года назад

I had to remind myself of the "family tree" of Agile Teams: - In the beginning there was an *Agile Team* [A] (which - I discovered later - was "doing Scrum") - Team [A] split into two team: *Team Scrum* [B] and *Team Kanban* [C] Given that [A] was doing Scrum all along, [B] was essentially a smaller version of [A] (having lost some of its members to [C]). So (deep breath)... When I joined [A], it was "mechanical"... and by the time I left the team (the team having morphed into [B]) I would say that it had progressed to "Competent". Great question. Thanks for asking it.

@izadoraberti11 2 года назад

the most awesome way to teach things (with drama and humour!)

@Developmentthatpays 2 года назад

Thank you! You just made my day!

@mpvsystems9302 5 лет назад

I prefer Kanban for conceptual reasons. I believe that estimating generally delivers more negative than positive value. To underestimate is to be human and it takes a lot of experience to get good at it. Poor estimates are the primary driver of technical debt. We may ask, "why" do we need to estimate the work in detail? What decisions does work size drive other than sprint fit? Artificial deadlines are thinly disguised extrinsic motivators that feed our obsession with time. Why not rely on the judgement, skill and engagement of the team to produce quality work in a timely fashion? Doe they really still need carrots and sticks?

@Developmentthatpays 5 лет назад

I tend to agree with you. On the specific point of estimating: for a long time, I tolerated the process of estimating: not because the estimates were any good (they weren't) but the process - the discussion - seemed valuable. I've changed my mind: I now consider it (the process of estimating) to do more harm than good.

@vipullal7689 3 года назад

Great delivery! Expected from someone who worked at BBC?

@Developmentthatpays 3 года назад

Very nice of you to say so!

@lucaingenito6726 5 лет назад

I was looking for a short, nice and eventually funny video to describe the difference between SCRUM and KANBAN to my next project team with which we'll have to define the best "fit for purpose" methodology for the project itself. Being an IT "system migration project" I'll have to measure with the architects and the business representatives in what way we could deliver (continuously as per KANBAN or by the end of every SPRINT as per the SCRUM). I got already an experience of running a migration with SCRUM even though other Agile coaches were telling me that Kanban (or Waterfall, so not agile) might have been more appropriate. I had to engineer a bit the resources allocation process and the deliverables but everything worked fine, also because luckily I was expert in the technology to be migrated so I could take my own choice with risks (but as said it paid back very well). In this case I'll have to rely more on the feedback from any architects and also from the business stakeholders to decide the methodology...luckily I found this very nice video with which I can kick-off the discussion before I'll go more into the details to build a matrix of PROS vs CONS for both methodology to then take the final decision (even though I kind of have that feeling of going with SCRUM). Thanks for sharing!

@Developmentthatpays 5 лет назад

Great comment... and delighted that the video may act as a jumping off point for your team discussions 👍

@tejas.the.tamhane 4 года назад

We are in 2020. This video and your explanation are still so intense :) Keep sharing the knowledge.

@Developmentthatpays 4 года назад

Tejas - Thank you - that's very much appreciated!

@lynnjackson1793 7 лет назад

I'm on the Ops side of DevOps (a statement that only makes sense if you're working in enterprise Service Management), and will point people to this video.

@Developmentthatpays 7 лет назад

Thank you for spreading the word!

@camilogyllback3752 5 лет назад

This is awesome dude! Really liked it.

@bhaibhai2012 5 лет назад

Kanban fits..when you are already done scrum and closed many sprints of product backlog..but there is leftover good amount of work pending here and there like tech debt, performance tuning issues,defects, small enhancements etc which cannot be logical group them as new user stories rather can be updated to existing stories..this defenitely needs expertise on existing project to pick things and go fast and be flexible to accept change in priorities..

@Developmentthatpays 5 лет назад

This might be a good subject to return to in the new year: is is better to start with Scrum and move to Kanban? Is it better to go directly to Kanban? Where does Scrumban fit into the picture?

@erich_l4644 4 года назад

You did a great job with this video! Great story telling!

@Developmentthatpays 4 года назад

Thank you - much appreciated!

@pianowhizz 5 лет назад

5:55: It's incorrect to imply that Kanban teams don't hold heartbeat retrospectives. I'm not sure where your belief there arises? Also both Kanban and Scrum can release after every item of work if they want to - the Scrum Guide only states a Minimum of once per Sprint. It's a very common myth that once per Sprint is expected/mandated or normal. 7:30: This is actually impossible in Kanban - Work In Progress (WIP) limits ensure maximum throughput and minimized waste (wasted time and money). This is a fundamental feature of Kanban. Lastly, Scrum does not encourage WIP limits by default. The last minute rush at the end of a Sprint works against this principle and also reduces quality (nothing rushed at the end of a Sprint is ever of sufficient quality).

@Developmentthatpays 5 лет назад

I didn't say that "kanban teams don't do retros"; I said "Team Kanban - i.e. one specific team - did not do retros".

@pianowhizz 5 лет назад

@@Developmentthatpays yes, I wrote that this 'implies' to most people that Kanban doesn't include them. You risk losing viewers by being ambiguous - especially beginners coming to learn afresh. Think of it this way, if you confused an enlightened 15-year Agile evangelist then you will definitely confuse 99% of all of your viewers.

@Developmentthatpays 5 лет назад

I agree that is the danger. I may do a follow-up video to clarify things.

@SayyedMustaheer 5 лет назад

I liked the way you explained. It was interesting and easy to understand..

@Ratanga10 5 лет назад

So easy to understand

@simeonherbert 4 года назад

I liked the video very good, sadly for me (a Kanban Guy) I felt you left out the bits that Yoda would have talked about. You missed the really exciting stuff like Queues, and the ability for cards to move at different speeds, the concept of how you select work based on Classes of services, swimlanes to manage different work types, and then we get to the metrics where it really gets exciting. I find that I have met some amazing scrum guys, who talk about how easy it is and how well the team delivers and how stuff is good, but on the other hand most good Kanban guys tell me how insightful Kanban is and how you can just take it up another level from Scrum. Overall great video and I hope I am willing to accept that both methods work for different things, Scrum is excellent when the job and technology is known and you are essentially turning the handle - I say this as you have to have more certainty to be able to select what you can do in two week. where as Kanban is more suited to a variety of work types like a service or Devops team. or new stuff - I always start my teams in Kanban and if appropriate move them to scrum once they know how long stuff takes. I never do story pointing in Kanban, just count the stories and aim for them to be "similar" in size. Thanks for doing this - really good.

@Developmentthatpays 4 года назад

Think I'm more or less on the same page as you: I have a strong preference for kanban - though you wouldn't know it from this video. Think this video will be more to your taste: ru-vid.com/group/PLngnoZX8cAn-OGRF9LTZ05gecTzx6bGrI

@jeffreyherman6824 6 лет назад

Wow, this is an AWESOME video, one of the best I've ever seen! Thank you!

@Developmentthatpays 6 лет назад

So pleased you liked it!

@benlorence7390 5 лет назад

Without intentional intervention, teams tend toward superficial.

@amrapali2314 5 лет назад

Understood in one go. Thanks a ton.

@enanoh8971 5 лет назад

Sorry to ask, in this story Scrum was better than Kanban all times even with the new agile one that have strongh kanban background??

@sbrugby1 5 лет назад

There's actually 3 teams: 2012 kanban < 2012 scrum < agile-one kanban(converted from 2012 scrum). It's kind of confusing from the video though, I had to rewatch the end.

@dchristofi 5 лет назад

Educational and at the same time entertaining!

@Developmentthatpays 5 лет назад

Thank you!

@VolkTron 3 года назад

Interesting 😃👍 This example/sorry applyies only when you have all Backlog-Items for a Sprint and a Multidisc.-Team ;)

@jaideeppal1838 9 месяцев назад

Amazing story telling!

@Developmentthatpays 8 месяцев назад

Thank you! You made my day!

@Richinator01 Год назад

Wow...... This is 💯... I understood both just in a gv

@Developmentthatpays Год назад

Excellent! 👍

@terjes64 2 года назад

The Agile One was a little bit like Obi Wan Kanban!

@Developmentthatpays Год назад

He was indeed!

@mmpp4149 4 года назад

I see development and testing. Where are analysis, detailed requirements, system design, prototyping, mapping and functional specifications? You can't skip them. This is what my team has been struggling with. We agreed that development backlog should include analyzed items (ready for coding), coding will be done in the 1st scrum week, testing in 2nd. Straight forward. All you need is to maintain the backlog making sure you have analyzed items. The real challenge is how you get from business requirement to analyzed item. How do you manage it. One story could be just simple mapping spec for report you can do in 2 days, another story could take more time, where you need to find out what data you need for process, what is the data source, what is the workaround / default you need to design if some data elements are not available at this source... it could take quite some time. How do you manage this in agile?

@Developmentthatpays 3 года назад

Sounds like you need to reduce the size of your stories (Story Slicing) so that you can get work - _including_ testing - completed in a single Sprint.

@ma-ez2sb 3 года назад

Well done! Thank you for the video very helpful

@johnjacobs1969 4 года назад

Interesting Video! I love the explanation!

@Developmentthatpays 4 года назад

Glad you liked it!

@alandmcleod5988 5 лет назад

Brilliant! So informative. THank you

@Developmentthatpays 5 лет назад

Thank you!

@felixblaoga 5 лет назад

You are hilarious. Thank you for the investigation presentation, and for the entertainment!

@Developmentthatpays 5 лет назад

Glad you enjoyed it!

@destinyalabi3820 4 года назад

Very enlightening

@Developmentthatpays 4 года назад

Thank you!

@b3nisrael 5 лет назад

Wonderful video, thank you and please keep them coming.

@Developmentthatpays 5 лет назад

Glad you liked it!

@shpresazendeli4472 3 года назад

can you do a video like this for the scrumban methodology please :) ?

@Developmentthatpays 3 года назад

How about a whole _playlist_ of *Scrumban* videos: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-7EKkxsXUPGI.html

@mc_brown_bear 4 года назад

So is the 4th lesson: it's better to be mechanical or competent with a supposedly "slower" process than be superficial or mechanical with a supposedly "faster process"?

@qays241179 6 лет назад

It’s one of the best, really appreciated

@Developmentthatpays 6 лет назад

Really glad you liked it!

@RomanRyder 7 лет назад

Wow! 100 episodes!!! Very cool video and interesting comparison.

@Developmentthatpays 7 лет назад

Thanks, Roman!

@hajdijudyt 2 года назад

Hey! I really love the concept of "Move to the right". One thing though, that's been plagueing me. In Kanban. Assumed we have set WIP limit to 'Development' column and it's maxed. There is a situation where one of the User Stories testing was completed and a bug was found - should you move the User Story "to the left" because it needs fixing? If yes, the WIP in "Developlment" is maxed, so you can't do that. OR. Do you create a separate work item for the bug, prioritize it at the top and... wait until a slot in "Development" column is freed? OR. The developer shouldn't pick up new work until their User Story is tested and Closed? If so, what do they do while waiting until the User Story gets tested? Please, put and end to this race of thoughts!

@matthewjamesdavison 5 лет назад

How did the two teams release and develop code together? Did they develop in different environments and merge the code? The same environment with code toggles? Some combination of the two (or some other approach)? Note - This question assumes the two teams develop the same product. Also, that continuous integration and fully automated testing are not yet a reality.

@Developmentthatpays 5 лет назад

Great questions: 1) The teams worked on separate projects/products. 2) There was some automated testing... but no continuous integration. The release process was very, very heavy: it was handled by a separate department, and took 2-3 days.

@matthewjamesdavison 5 лет назад

@@Developmentthatpays Thanks! Dealing with the same problems with integration and release processes. As always, automation gets put on the back burner and no one wants to simplify release processes (typical command and control).