After watching this and the "Scrum Vs. Kanban" videos I've probably learned more in these past 20-25min than I did an entire semester. Amazing what a good teacher can do with the help of some great animations. Thank you, sir.
I'm guessing they're from the designers who are always left out of any explanation of agile methodologies and who have to put up with clueless delivery managers, scrum masters, product owners, etc. who've never worked with designers before and don't know where they fit into these methodologies. :) I'm just speculating, tho.
Probably devs and the people who implement the work. I have recently been looking into these systems and been talking to various people seems like the scrum master is a bit of a voodooo subject in itself :O.
This video (thanks to some unexpected file corruption issues) took some late nights and some early mornings to put together. I hope you like it, and I look forward to reading your comments.
This was really, really good. Not a second wasted, extremely easy to follow, and feels like it's pretty much a complete "talk the talk" lesson. Perfect.
Awesome content, between this and the mini series kudos to you! All of my colleagues just received training on Agile + Scrum so it was up to me to educate myself. (since interns don't go to those cool workshops!)You definitely smoothed out the bumps in the road with the flawless story telling.
I have worked with both approaches, after coup, watching this tutorial enforces perfectly what I've learned from both of them and gives me more confidence explaining to people why it was better to use what it was decided to be used. Thanks bro
Finally I understand the key differences between these 2 Agile methodologies! This is the best video ever on this topic! Keep up this great work! Thank you!
This was an exceptional video (and I watch hundreds each week)! You were clear, fast, and precise. You have an excellent delivery demeanor. Thanks so much, I will share this with the many Teams I work with...
This is by far the best, most clear identification of Scrum & Kanban & their resulting difference, & I admire so much is because of the little span of time within which the video encapsulates all this... Beautiful work @DevelopmentThatPays team & the narrator
By far the best description I've come across thus far. I had never even studied Kanban prior to this and got it almost immediately! Great job with this one.
I work as a Product Analyst and I can confirm this video outlines everything you need to know when differing between Scrum and Kanban I watched this video with my mother and explained along the way how it all works, your examples and visuals were very helpful!
I can definitely agree on that last point. Over time your Kanban/Scrum process(es) will naturally evolve and may even borrow from both Scrum and Kanban. Excellent video!
I am not related to Product Management at all! However, I do have to recruit product owners and I have to dive a bit into the skills /experience required to place the correct questions. This was so clear and so well put together, that I honestly feel more equipped to interview these kind of positions. I additionally learned a lot about Scrum/Kanban today :) Thanks!
I bet this is the easiest demonstration of Scrum vs Kanban on YT, which was short and crisp with covering every point. Thanks a ton for the amazing video and CHEAT SHEET.
Very clear succinct description and explanation. Honestly as a certified CSM and CSPO I did not truly understand the variations between the two. I am aware of Continuous iterative integration and the like but this video made things crystal clear… THANK YOU!
I'm a huge fan of your teaching methods. If I may ask...what do you use for the animations? Learning this skill would help me teach my team and colleagues. Thank you for doing these!
+Chris Carmichael - That's nice of you to say so!. Re. the animations, I'll get around to doing a video on this at some point. In the meantime I hope this is helpful: I occasionally use Apple Motion, but 95% of the time I use Apple Keynote. And much of the animation uses Keynote's Magic Move transition. (I believe PowerPoint has a similar transition.) I make all of the transitions slow, export the entire presentation to QuickTime, then edit the visuals to the audio in Final Cut Pro.
I'm trying to understand the scrum concept for hours but got some confusion. But your 5min video saves me a lot of headaches. Concise, direct-to-the-point, and very informative. Thank you.
With a Kanban system, there should be virtually no "Backlog" a.k.a. "Buffer". That is one on the major purposes of having a continuous 1-Piece-Flow system.
One of the best videos to learn the difference between Kanban and Scrum just in 5 minutes. Thank you for creating this video and sharing with us ❤ Cheers! 🎉
where i work they say we use scrum but, rely we use both, we do daily meting, retrospective, 2 week sprint and when the TO DO list is done we pull from the back-log lol
Great video! one thing - I think scrum is not a methodology, it's a framework. And not sure if Kanban has such things as standups, as it is coming from Extreme Programming. Is it dictated by Kanban that it should be a part of the framework, like daily scrum in Scrum?
You're right, you're right: it's a framework not a methodology. I'm not sure about what Kanban dictates: Kanban isn't as "codified" as Scrum. For what it's worth, I can tell you that every Kanban team I've been a part of does a daily standup.
Best video out there I have found, and you nailed it by saying you can adapt these processes for your business needs. Too many companies force a text book approach on these systems believing it will work and can cause more problems and push people to quit their jobs. It's a framework not doctrine.
I ADORE you, I have to present a paper about those agile methodologies and this video gave the punch my dull paper needed to become a great work. Thanks.
There are several suggestions for how to pass the Asvab test Take a rest Don't get too stressed about it Look at some example exams online (I discovered these and why they work on Wilfs Exam Blueprint site )
When are demos and retrospectives usually performed during Kanban? It was mentioned that Kanban is a continuous process and doesn't have sprints, does that mean that demos and retrospectives are done everytime something is ready to be delivered to the customer?
It is trickier in kanban, as there's no natural "trigger". Holding a demos and retros at each release would be (potentially) much too frequent. It's up to the team to decide when to to hold demos and retros. (And yes, there's a danger than they won't happen often enough.)
Indeed a very useful video, thank you! I've got a question: one of the clearest differences between Kanban & Scrum is that in Kanban, Items are “pulled” directly from the Product Backlog to the Kanban Board. But in Scrum, only selected items are pulled from Product Backlog to the Sprint Backlog (intermediary) first and then pulled into the Agile Board. In Kanban, do teams ignore Prioritazation because there is no intermediary like Sprint Backlog? Isn't this bad? In Kanban, while pulling items from Product Backlog to Kanban Board how do teams decide which items should be pulled/developed first, how do they give priority to tasks? Or do they develop tasks randomly, in any way they want?
What an awesome question! Scrum teams ask the question "what are the next things we should work on?"; Kanban teams ask the question "What's the next thing we should work on?" This means that - for a kanban team - the top of the product backlog must be carefully ordered. Some teams add an additional column - between the backlog and Dev - often called "ready". It contains a limited number of ordered items. The Ready column can - and should! change at any time. Does that make sense?
@@Developmentthatpays thanks, it really does. Awesome answer. I can see that in Scrum, we are interested in taking itemS in bulk (thingS) from Backlog while in Kanban we take the most important item from the top of the Backlog. (am I right?) Another thing is: what's the difference between that "ready" column and the DONE column in Kanban Board?
You're right... although I'd say it differently. One of the problems that agile helps us with is the (very human) tendency to work on too many things at the same time. Scrum says "work on a strictly limited number of items"; Kanban says "work on just one item". The Done column is the final column; the Ready column (if present) is the first column (after the backlog). Take a look at this (section of) video for more on this: ruclips.net/video/fgT4AaKcBUA/видео.html
@@Developmentthatpays every time you are answering me I'm extracting something new and the knowledge is building up. when you said "Ready" column, you meant Ready to BE DEVELOPED (not Ready to BE RELEASED, as I wrongly understood it), am I right? Scrum says "work on a strictly limited number of items" => while Kanban's READY column is more flexible. Scrum's Sprint Backlog is something that is STRICT/CLOSED while Kanban's READY column can change at any time.. yeah?
@@abduvosidmalikov No, Ready means that the item is reviewed and is ready for team to take on when next Build or Active column is having space or limit available in queue. May try to elborate which will help whats in video - To Do - backlog or items in bag which a team needs to work. (RAW, may be not in order or sequence). As there is NO PO, so team is best to judge what to pick next (worst thing I feel (as Agile Coach) while working with KANBAN teams) Build - Here team is working on some thing, what this means that they have discussed and understood what is asked for and they know how to deliver it. Done / Completed / Closed - when the work is all completed and released for end user to test and enjoy this piece. Ready column - it fits between To Do and Build column # Ready column helps when a lead is looking on new things or backlog items brining them in sequence so that team can pick immidiate available next item in queue. So team knows that what is next thing they need to work on - similar to Scrum approach you can say. Here Lead is acting as virtual PO for team. @Development That Pays - please add/correct above if sounds going here n there :) as I am still learning Kanban coaching
Excellent video, it is a pleasure to share it... just a little question, Do you have another link to the cheet-sheet? the description link is broken :(
It's very clear: the Product Owner owns the Product Backlog. But that doesn't mean that she is all-powerful. Here's why: it's the Development Team that gets to choose the items for each Sprint (the Sprint Backlog). And the team is not obliged to pick the top-most items.
Correction at 2:40, ones the sprint backlog has been created and a requirement comes up, the product owner can discuss with the dev team if they can accommodate the requirement in the current sprint.
This is correct, that PO can present the new requirement and let team judge if they want to work in current sprint or leave it for next sprint. Alternatively, it is new, urgent and management wants it as done yesterday - then option is to replace something from current sprint to accomodate immediately. Here SM role is support team, push the new thing to next sprint or get something removed to accomodate new item. Otherwise, team will be under pressure.
Two years late to the party, but a few comments. There are a LOT of misconceptions and dangerous oversimplifications in the video. Non-exclusive listing: * the role of the Product Owner is exclusive to Scrum, although many non-Scrum team use it as well. It's NOT an "Agile" thing. * the role of an "Agile Coach" is not defined in Kanban - how the role is defined in an organization varies widely. * a key difference between Scrum and Kanban is that Scrum suggests a single team to have end to end process responsibility, whereas Kanban is neutral to the idea that there could be handovers in the process. * Some Scrum teams not only use Kanban boards, but embed Kanban as their method of delivery. Therefore, it's not "confusing" at all when they talk about having a Kanban board. * There's nothing in Scrum that forces having a single Release at Sprint End. Many Scrum teams find value in Continuous Delivery/Deployment. * Kanban's WIP limits should not only be on individual activities, but on the Value Stream. There's no value in generating WIP that doesn't get processed in a timely manner. * One of the key principles in the manifesto for agile software development is daily collaboration between developers and "the business" (i.e. customers). The initial diagram is dangerously oversimplified. If developers don't interact with customers but only deliver what they think solves the backlog item, the result is usually low quality. * The way the arrows in the initial diagram look like, this is still a PUSH process, not a PULL process. In a pull process, the arrows would be reversed. * It's not called a "ritual", it's called "event" in Scrum - and Kanban prescribes none of them. * Kanban is basically a set of principles (such as evolutionary change, customer centricity and self-organization) as well as practices (such as flow management and making policies explicit) that are entirely ignored in the video. Sorry for the harsh critique, but I feel Kanban is entirely misrepresented and the proposed differences between the two frameworks could lead teams to decide for an approach under false assumptions. Here are the key differences: Scrum = build an effective team. Kanban = create an effective delivery process. That's why you can choose none, either or both.
I'm broadly in agreement with you. The video was never intended to be a tutorial: it was more about "documenting" real-life teams... making real-life mistakes. Having said that, I'm aware that (a) the video has become popular and (b) there is a danger that people are being misled. At some point I'm going to do an "Everything wrong with..." video - and I'll borrow heavily from your comment! Thanks again.
Truly excellent and succinct. Better than any similar video I've seen on RUclips in every way, especially because it's accurate and saves time. Thank you.
Ah, good ol daily meetings, the most hated thing ever. Sadly, the systems were not designed to help developers, they were designed to help micromanage the devs.
we always have few engineers who just love hearing themselves talk, team is also very large so their domain is different from others and nobody understands what they are talking about, it's so frustrating!
@@drawmaster77 The secret to avoid this issue is to set time limits and rules in how feedback can be given. Anything that is outside can be taken offline.
If all devs are awesome, they need almost no management, and these meetings are either unnecessary or very fast. Back in the real world, that's not the case. Sadly, some devs are bad (inept, slow, lazy, whatever). Those ones need more managing - it's rarely as simple as "fire them and get better ones." Any methodology that can only work if all the team are way-above-average is seriously flawed. On average, a chunk of the team will be no better than average. Hence the need for these kind of meetings. If the team's good, they don't need or get micromanaged by a decent manager. If there's micro-managing, either the manager or the team are problematic - and it's not always the manager at fault.
Scrum isn't really a pull process because it doesn't typically prescribe pulling across activities. E.g. Code to Test. Typically when Code is complete it is pushed to a tester.
Two things: 1. It's common practice (as you point out) for devs to push to Test. That's always struck me as unfair: the devs get to pull from the backlog; why should they have all the fun? The Test team should be given the same consideration. All it takes is another column (or a buffer zone) on the Agile board . 2. If you zoom out a bit - and view the tech team as a whole - the pull becomes more evident.
You're right, you're right. When I made this video, I wasn't aware of the distinction: I've corrected this in more recent episodes - and in my Mini-course.
Agile is absolutely not a methodology as it follows no strict guidelines, it is to be used and adapted to the specific requirements of the business owner and the customer. Scrum and Kanban fall under the methodology convention as they have specific guidelines in place that distinguish them from other agile methodologies.
Well, it was developed at roughly the same time - the 1950s. But of course it can be used as a subset of Agile. The computer is a subset of "internet connected devices", yet computers existed before the internet...
This is absolutely incorrect. Agile tells you literally nothing about process its just a set of values. No matter how many times the people who wrote the manifesto say this there will always be people who don't understand it.
i'm only starting with web development and hadn't realised there were so many things to learn in a more theoretical plan. this video really helped me, thanks so much.
Short and clear explanation, no buzz, thanks. The kanban process looks more smooth, natural, logic and freedom, not just production because of production. With those management systems, I can see the management benefits however never mention something about the (code) quality aspects and the long term effects of doing it that way. Is it fast and furious or gentle and carefully, what do think costumers of it (review) and will stay the development crew motivated. If it turns out to be a factory of software no matter what the quality is, just a tool to get a secured periodically income by sending bills, I think that is not a (long term) win.
I just reviewed four videos on Kanban to show my teams interested in Kanban. One was gorgeous but bashes scrum. The other was a snooze fest and missed all the key ideas. Your video was the porridge that was just right! I think I communicate better than most, and I could NOT have done it this well, so thank you! I have only one criticism. Your definition of agile at the beginning is actually the definition of iterative, not agile. My favorite quote for this, said by my client Andres Borque: Agile = Iterative + Culture. What makes Scrum and Kanban Agile is the high trust, self-organizing, transparent, collaborative culture. Delivering smaller increments is a part of agile, but it is also a part of iterative (like RUP) even if you aren't embracing agile. Either way, thank you for a great video. I will recommend it be used with the teams at my current client. :)
Just call me Goldilocks! Great comments of the video. Your "Agile = Iterative + Culture" point is just the kind of distinction I love to dig in to. It's on the list for a future episode!
OK seriously-where has this video been the last 2 years? Amazingly simple that even I can understand :). If I had to pick a nit, I'd point out the "cheetsheat" spelling error at 4:58 but I don't want this content to be removed and so I won't mention it :) (because it has simplified Scrum and KanBan to an incredible level, everybody needs to watch it). Seriously guys, good job!!!! 4.95/5 Stars!!!
This, Sir, is GOOOOD shit! Thank you for taking the time to assemble and share with us. I share the same impressions as the guys below: there was more clarity in your less than 6 minutes videos than all the coaching workshops I've "patiently" attended. Therefore: I LIKED, SHARED and SUBSCRIBED... What?? The bell's notifications?!! Bitch please... ;) Seriously, thank you very much and by all means, keep it up!
Glad you liked the video. And you raise a good point about purity; I tend to blur the lines between the "pure" and the "not-so-pure" versions of Scrum. I may need to tighten this up a bit. Great comment.
Great video. One thing that would be great to see a video on is reasons why you might choose one over the other (unless you've made it already, I'll go look now 😁)
After watching this and the "Scrum Vs. Kanban" videos I've probably learned more in these past 20-25min than I did an entire semester.
Amazing what a good teacher can do with the help of some great animations.
Thank you, sir.
What a lovely comment. Thank you - very much appreciated.
It is indeed. Much better than the extensive reading materials. Well done! It has higher retainability. :)
+Iresh Rie Dacian - 👍
I totally agree. Thanks for posting such a wonderful video.
All this stuff is turning simple things into intrancate and complicated stuff through the use of buzzwords.
who on earth is giving this video a thumbs down? As an agile coach and scrum master, i can say it's short, sweet and very clear. great work!
Thanks, Nick. You just made my day! 👍👍👍
I'm guessing they're from the designers who are always left out of any explanation of agile methodologies and who have to put up with clueless delivery managers, scrum masters, product owners, etc. who've never worked with designers before and don't know where they fit into these methodologies. :) I'm just speculating, tho.
Probably devs and the people who implement the work. I have recently been looking into these systems and been talking to various people seems like the scrum master is a bit of a voodooo subject in itself :O.
Effing idiots are.
Did not answer my questions on why my pee goes in 12 different directions, so I was forced to give it a thumbs down.
This video (thanks to some unexpected file corruption issues) took some late nights and some early mornings to put together. I hope you like it, and I look forward to reading your comments.
You really deserved it !!!
It's excellent! Really clear! Thank you for making the effort!
absolutely fantastic video! subscribed 👍👍
Awesome video. thank you very much its really helping me in my work. again thank you.❤️❤️
Have a retrospective meeting with yourself then :D great stuff!
Incredible tutorial. I used to love SCRUM and the name Kanban was interesting to me. However the process of Kaban seems more interesting.
This was really, really good. Not a second wasted, extremely easy to follow, and feels like it's pretty much a complete "talk the talk" lesson. Perfect.
Very nice of you to say so! Much appreciated.
Awesome content, between this and the mini series kudos to you! All of my colleagues just received training on Agile + Scrum so it was up to me to educate myself. (since interns don't go to those cool workshops!)You definitely smoothed out the bumps in the road with the flawless story telling.
Thank you!
I have worked with both approaches, after coup, watching this tutorial enforces perfectly what I've learned from both of them and gives me more confidence explaining to people why it was better to use what it was decided to be used.
Thanks bro
Finally I understand the key differences between these 2 Agile methodologies! This is the best video ever on this topic! Keep up this great work! Thank you!
Natasha Elliott - Thank you so much!
Thank you for such a brief and near-perfect explanation! I can't believe you covered all the essentials of scrum in less than 4 minutes. Great work!
Glad you enjoyed it!
Your videos on Scrum and Kanban are a top quality explanation. Great content and a great job fitting all the information in a short video, thanks!
Petro, that's very nice of you to say. Thanks you so much.
This was an exceptional video (and I watch hundreds each week)! You were clear, fast, and precise. You have an excellent delivery demeanor. Thanks so much, I will share this with the many Teams I work with...
Wow, thank you! Very nice of you to say so.
2020 and this still is one of the best videos to learn agile development. Thanks for your contribution!
Wow, thanks! You made my day!
@@Developmentthatpays Still amazing in 2023, thx for the vid
@@MioYTonline - Thanks for making my day!
This is by far the best, most clear identification of Scrum & Kanban & their resulting difference, & I admire so much is because of the little span of time within which the video encapsulates all this... Beautiful work @DevelopmentThatPays team & the narrator
Thank you so much. I'm delighted you liked it!
I love how you are clear and explained everything simply
By far the best description I've come across thus far. I had never even studied Kanban prior to this and got it almost immediately! Great job with this one.
That’s awesome. Really glad you like it!
I work as a Product Analyst and I can confirm this video outlines everything you need to know when differing between Scrum and Kanban
I watched this video with my mother and explained along the way how it all works, your examples and visuals were very helpful!
Awesome comment. Thank you!
I can definitely agree on that last point. Over time your Kanban/Scrum process(es) will naturally evolve and may even borrow from both Scrum and Kanban. Excellent video!
Agreed: each has something to learn from the other.
Literally the most clear explanation! Thank you ❤️
That's the clearest explanation of both Kanban and Scrum that I've yet seen. Thank you. Liked and subscribed.
Awesome, thank you!
This is the best explanation of differences I have seen! Clear and simple. Thank you
Glad it was helpful!
Thanks for breaking it down am new to project management and this is so helpful! Already shared to my course mates 👏🏽
Excellent! Glad it was helpful 👍
I am not related to Product Management at all! However, I do have to recruit product owners and I have to dive a bit into the skills /experience required to place the correct questions. This was so clear and so well put together, that I honestly feel more equipped to interview these kind of positions. I additionally learned a lot about Scrum/Kanban today :) Thanks!
That's awesome!
Literally THE BEST explanatory video I have ever seen. Straight to the point with all information easily broken down. Terrific!
How has it taken me 2 years to find this lovely comment. THANK YOU!
I bet this is the easiest demonstration of Scrum vs Kanban on YT, which was short and crisp with covering every point. Thanks a ton for the amazing video and CHEAT SHEET.
I'm delighted that you found it to be useful 👍
Great job and teacher. I appreciate this gift you have.
What an amazing explanation. Easy and concise. Thank you for putting this info together!
You are most welcome. Glad you liked it!
This video is great, all I needed was a rough idea, now I can start learning more about this.
Very clear succinct description and explanation. Honestly as a certified CSM and CSPO I did not truly understand the variations between
the two. I am aware of Continuous iterative integration and the like but this video made things crystal clear… THANK YOU!
Cyrus Mody - That's a huge compliment. Thank you!
Cyrus Mody - That's a huge compliment. Thank you!
I'm a huge fan of your teaching methods. If I may ask...what do you use for the animations? Learning this skill would help me teach my team and colleagues.
Thank you for doing these!
+Chris Carmichael - That's nice of you to say so!. Re. the animations, I'll get around to doing a video on this at some point. In the meantime I hope this is helpful: I occasionally use Apple Motion, but 95% of the time I use Apple Keynote. And much of the animation uses Keynote's Magic Move transition. (I believe PowerPoint has a similar transition.) I make all of the transitions slow, export the entire presentation to QuickTime, then edit the visuals to the audio in Final Cut Pro.
Incredible tutorial. Wonderful. Good job.
Thanks for the explanation, as well as the attached sheet.
I'm trying to understand the scrum concept for hours but got some confusion. But your 5min video saves me a lot of headaches. Concise, direct-to-the-point, and very informative. Thank you.
Great comment! I'm glad you liked the video.
With a Kanban system, there should be virtually no "Backlog" a.k.a. "Buffer". That is one on the major purposes of having a continuous 1-Piece-Flow system.
Great pace, v clear, thank you for uploading this :-)
Thank you! Glad you enjoyed it.
Best video on this subject on the Internet. Suddenly after 20 videos on the subject I get it. Completely.
One of the best videos to learn the difference between Kanban and Scrum just in 5 minutes. Thank you for creating this video and sharing with us ❤ Cheers! 🎉
My pleasure!
Oh joy! An English voice, at LAST! Proper speech, properly structured explanation!
Why thank you. Awfully decent of you to say so :)
I really enjoyed your tutorial. Merry Christmas and a Happy 2018!
Thank you!
I thought you were Welsh though ;)
That's a North East English accent, some similarities to Welsh but different.
Good shot, thnx much, really defines well enough!!!!
Thank you!
18 January is my birthday. I wish I had watched your content when I was starting out with my business :) it is a treasure trove of great info
such a short , simplified and perfect way to summarize the differences ...Kudos to the author!
Thank you! Glad you liked it 👍
where i work they say we use scrum but, rely we use both, we do daily meting, retrospective, 2 week sprint and when the TO DO list is done we pull from the back-log lol
Scrumban
Agreed! And if the task is not completed in the sprint, we move it to the next.
Great video! one thing - I think scrum is not a methodology, it's a framework. And not sure if Kanban has such things as standups, as it is coming from Extreme Programming. Is it dictated by Kanban that it should be a part of the framework, like daily scrum in Scrum?
You're right, you're right: it's a framework not a methodology.
I'm not sure about what Kanban dictates: Kanban isn't as "codified" as Scrum. For what it's worth, I can tell you that every Kanban team I've been a part of does a daily standup.
@Flat Iron Silly question friend
Best video out there I have found, and you nailed it by saying you can adapt these processes for your business needs. Too many companies force a text book approach on these systems believing it will work and can cause more problems and push people to quit their jobs. It's a framework not doctrine.
"It's a framework not doctrine."
I ADORE you, I have to present a paper about those agile methodologies and this video gave the punch my dull paper needed to become a great work. Thanks.
What a cracking comment! Glad to help!
There are several suggestions for how to pass the Asvab test
Take a rest
Don't get too stressed about it
Look at some example exams online
(I discovered these and why they work on Wilfs Exam Blueprint site )
When are demos and retrospectives usually performed during Kanban? It was mentioned that Kanban is a continuous process and doesn't have sprints, does that mean that demos and retrospectives are done everytime something is ready to be delivered to the customer?
It is trickier in kanban, as there's no natural "trigger". Holding a demos and retros at each release would be (potentially) much too frequent. It's up to the team to decide when to to hold demos and retros. (And yes, there's a danger than they won't happen often enough.)
Indeed a very useful video, thank you!
I've got a question: one of the clearest differences between Kanban & Scrum is that in Kanban, Items are “pulled” directly from the Product Backlog to the Kanban Board. But in Scrum, only selected items are pulled from Product Backlog to the Sprint Backlog (intermediary) first and then pulled into the Agile Board.
In Kanban, do teams ignore Prioritazation because there is no intermediary like Sprint Backlog? Isn't this bad? In Kanban, while pulling items from Product Backlog to Kanban Board how do teams decide which items should be pulled/developed first, how do they give priority to tasks? Or do they develop tasks randomly, in any way they want?
What an awesome question! Scrum teams ask the question "what are the next things we should work on?"; Kanban teams ask the question "What's the next thing we should work on?"
This means that - for a kanban team - the top of the product backlog must be carefully ordered. Some teams add an additional column - between the backlog and Dev - often called "ready". It contains a limited number of ordered items. The Ready column can - and should! change at any time.
Does that make sense?
@@Developmentthatpays thanks, it really does. Awesome answer.
I can see that in Scrum, we are interested in taking itemS in bulk (thingS) from Backlog while in Kanban we take the most important item from the top of the Backlog. (am I right?)
Another thing is: what's the difference between that "ready" column and the DONE column in Kanban Board?
You're right... although I'd say it differently. One of the problems that agile helps us with is the (very human) tendency to work on too many things at the same time. Scrum says "work on a strictly limited number of items"; Kanban says "work on just one item".
The Done column is the final column; the Ready column (if present) is the first column (after the backlog). Take a look at this (section of) video for more on this: ruclips.net/video/fgT4AaKcBUA/видео.html
@@Developmentthatpays every time you are answering me I'm extracting something new and the knowledge is building up.
when you said "Ready" column, you meant Ready to BE DEVELOPED (not Ready to BE RELEASED, as I wrongly understood it), am I right?
Scrum says "work on a strictly limited number of items" => while Kanban's READY column is more flexible. Scrum's Sprint Backlog is something that is STRICT/CLOSED while Kanban's READY column can change at any time.. yeah?
@@abduvosidmalikov No, Ready means that the item is reviewed and is ready for team to take on when next Build or Active column is having space or limit available in queue.
May try to elborate which will help whats in video -
To Do - backlog or items in bag which a team needs to work. (RAW, may be not in order or sequence). As there is NO PO, so team is best to judge what to pick next (worst thing I feel (as Agile Coach) while working with KANBAN teams)
Build - Here team is working on some thing, what this means that they have discussed and understood what is asked for and they know how to deliver it.
Done / Completed / Closed - when the work is all completed and released for end user to test and enjoy this piece.
Ready column - it fits between To Do and Build column # Ready column helps when a lead is looking on new things or backlog items brining them in sequence so that team can pick immidiate available next item in queue. So team knows that what is next thing they need to work on - similar to Scrum approach you can say.
Here Lead is acting as virtual PO for team.
@Development That Pays - please add/correct above if sounds going here n there :) as I am still learning Kanban coaching
Very crisp platter in many many videos on youtube. Thanks for building such a short but valuable video.
You are most welcome! 😊
Excellent video, it is a pleasure to share it... just a little question, Do you have another link to the cheet-sheet? the description link is broken :(
Animations are helpful in memorizing these stuff.
Glad you liked the animations!
In Scrum: Is there a guideline as to who(developers) owns the items in the sprint backlog, or is that at the discretion of the development team ?
It's very clear: the Product Owner owns the Product Backlog. But that doesn't mean that she is all-powerful. Here's why: it's the Development Team that gets to choose the items for each Sprint (the Sprint Backlog). And the team is not obliged to pick the top-most items.
In my team, each developer usually is expected to pick their own stories, unless the PO or the SML has a preference
great video. in my team some people call our approach as Scrumban. But its just regular scrum with Kanban board, nothing else
Thanks a lot, Gary, wonderful explanation, accurate and concise! And that British pronunciation really rocks :)
You are very welcome. Glad you liked the video... and the accent 😀
Correction at 2:40, ones the sprint backlog has been created and a requirement comes up, the product owner can discuss with the dev team if they can accommodate the requirement in the current sprint.
You're... correct!
This is correct, that PO can present the new requirement and let team judge if they want to work in current sprint or leave it for next sprint.
Alternatively, it is new, urgent and management wants it as done yesterday - then option is to replace something from current sprint to accomodate immediately.
Here SM role is support team, push the new thing to next sprint or get something removed to accomodate new item. Otherwise, team will be under pressure.
Two years late to the party, but a few comments.
There are a LOT of misconceptions and dangerous oversimplifications in the video.
Non-exclusive listing:
* the role of the Product Owner is exclusive to Scrum, although many non-Scrum team use it as well. It's NOT an "Agile" thing.
* the role of an "Agile Coach" is not defined in Kanban - how the role is defined in an organization varies widely.
* a key difference between Scrum and Kanban is that Scrum suggests a single team to have end to end process responsibility, whereas Kanban is neutral to the idea that there could be handovers in the process.
* Some Scrum teams not only use Kanban boards, but embed Kanban as their method of delivery. Therefore, it's not "confusing" at all when they talk about having a Kanban board.
* There's nothing in Scrum that forces having a single Release at Sprint End. Many Scrum teams find value in Continuous Delivery/Deployment.
* Kanban's WIP limits should not only be on individual activities, but on the Value Stream. There's no value in generating WIP that doesn't get processed in a timely manner.
* One of the key principles in the manifesto for agile software development is daily collaboration between developers and "the business" (i.e. customers). The initial diagram is dangerously oversimplified. If developers don't interact with customers but only deliver what they think solves the backlog item, the result is usually low quality.
* The way the arrows in the initial diagram look like, this is still a PUSH process, not a PULL process. In a pull process, the arrows would be reversed.
* It's not called a "ritual", it's called "event" in Scrum - and Kanban prescribes none of them.
* Kanban is basically a set of principles (such as evolutionary change, customer centricity and self-organization) as well as practices (such as flow management and making policies explicit) that are entirely ignored in the video.
Sorry for the harsh critique, but I feel Kanban is entirely misrepresented and the proposed differences between the two frameworks could lead teams to decide for an approach under false assumptions.
Here are the key differences:
Scrum = build an effective team.
Kanban = create an effective delivery process.
That's why you can choose none, either or both.
I'm broadly in agreement with you. The video was never intended to be a tutorial: it was more about "documenting" real-life teams... making real-life mistakes.
Having said that, I'm aware that (a) the video has become popular and (b) there is a danger that people are being misled. At some point I'm going to do an "Everything wrong with..." video - and I'll borrow heavily from your comment!
Thanks again.
Truly excellent and succinct. Better than any similar video I've seen on RUclips in every way, especially because it's accurate and saves time. Thank you.
Thank you! Very nice of you to day so. 👍
Brilliant!! Short, crisp & precise. Well presented too , well done!!
Thank you!! 👍
Is there a way to download the cheat sheet, or must I "pay" with my email address?
Yes, you do need to enter your email address: that allows me to send you a new version when it's updated. (It's already been updated multiple times.)
@@Developmentthatpays Can you please send me the sheet too? Thanks
Ah, good ol daily meetings, the most hated thing ever. Sadly, the systems were not designed to help developers, they were designed to help micromanage the devs.
I was going to disagree with you... and then I saw how many times your comment was up-voted!
we always have few engineers who just love hearing themselves talk, team is also very large so their domain is different from others and nobody understands what they are talking about, it's so frustrating!
@@drawmaster77 The secret to avoid this issue is to set time limits and rules in how feedback can be given. Anything that is outside can be taken offline.
If all devs are awesome, they need almost no management, and these meetings are either unnecessary or very fast.
Back in the real world, that's not the case.
Sadly, some devs are bad (inept, slow, lazy, whatever). Those ones need more managing - it's rarely as simple as "fire them and get better ones."
Any methodology that can only work if all the team are way-above-average is seriously flawed. On average, a chunk of the team will be no better than average. Hence the need for these kind of meetings. If the team's good, they don't need or get micromanaged by a decent manager. If there's micro-managing, either the manager or the team are problematic - and it's not always the manager at fault.
Why would anyone be micromanaging at dailies? I mean, anything you use incorrectly can be blamed for not working.
Awesome video! Concise, simple to follow, and incredibly effective. Thank you!
Thank you! Great comment!
This is some interesting stuff, who knew your work life could have such an impact on this
0:00 tbh I came to this video to learn about how to cook cup cakes.
ruclips.net/video/HHm6hzxHpzY/видео.html
Aaaand here's a video that does in 5 minutes what a thousand blog posts have not done in a decade.
Loved it.. especially pull.. difference in scrum and kanban
Great explanations for both. Thank you. Explained simply and without top-heavy graphics.
You're very welcome!
Scrum isn't really a pull process because it doesn't typically prescribe pulling across activities. E.g. Code to Test. Typically when Code is complete it is pushed to a tester.
Two things:
1. It's common practice (as you point out) for devs to push to Test. That's always struck me as unfair: the devs get to pull from the backlog; why should they have all the fun? The Test team should be given the same consideration. All it takes is another column (or a buffer zone) on the Agile board .
2. If you zoom out a bit - and view the tech team as a whole - the pull becomes more evident.
good video, but those noises are annoying, I would avoid in following videos ('Bottleneck traffic signal' and 'Important')
I have been guilty of over-doing the noises in the past. Thanks for the feedback.
excellent presentation in finest way
this more comprehensive than lecture class! thank you :3
In my team, we simply use a mixture of boths styles, with longer sprints, and minus the cult-like stuff :D
Scrum: What’s the difference between me and you?
Kanban: I bought 5 bank accounts, 3 ounces and 2 vehicles.
?!?
Waterfall: Until my death, I'm Bangladesh
@@Developmentthatpays Dr.Dre song
After watching so many videos and reading so much, this video gives me the clearest picture of Scrum and Kanban.
Lovely comment - THANK YOU!
Thank you for the summarized video.
My pleasure!
This method look like the method adopted the day after Turing invented the computer...
I really cannot find anything new...
OK. (Did Turing invent the computer?)
Development That Pays sorry for my comment, but it seems a very ordinary developing method, never heard something different.
Yes, he did.
Scrum & Kanban are NOT methodologies. They are frameworks. Agile is the methodology and Scrum & Kanban fall under it.
You're right, you're right. When I made this video, I wasn't aware of the distinction: I've corrected this in more recent episodes - and in my Mini-course.
Agile is absolutely not a methodology as it follows no strict guidelines, it is to be used and adapted to the specific requirements of the business owner and the customer. Scrum and Kanban fall under the methodology convention as they have specific guidelines in place that distinguish them from other agile methodologies.
I guess it's a matter of degree: there's plenty of "wiggle room" in Scrum and (especially) Kanban.
Kanban existed long before software development, so it cannot be a subset of agile software development.
Well, it was developed at roughly the same time - the 1950s. But of course it can be used as a subset of Agile.
The computer is a subset of "internet connected devices", yet computers existed before the internet...
Very good video with great efforts on the graphical representation. Thank you!
Really glad you liked it!
Such a great overview video with helpful graphics. Thank you.
This is absolutely incorrect. Agile tells you literally nothing about process its just a set of values. No matter how many times the people who wrote the manifesto say this there will always be people who don't understand it.
I really do need to do a video or three on the Agile Manifesto.
FRAMEWWORK! not Methodology
I know, I know. I'm ashamed of myself. 😱
@@Developmentthatpays Whats the difference?
Wow, it has been only 1 and a half minute and it has already proved that it's the best content I've ever watched on the subject.
THANK YOU. Lovely comment!
i'm only starting with web development and hadn't realised there were so many things to learn in a more theoretical plan. this video really helped me, thanks so much.
Delighted that I could help!
The 'OnTime' tool looks like a great product for project management. Great video! *thumbs-up*
Is that the Axosoft product?
Short and clear explanation, no buzz, thanks. The kanban process looks more smooth, natural, logic and freedom, not just production because of production. With those management systems, I can see the management benefits however never mention something about the (code) quality aspects and the long term effects of doing it that way. Is it fast and furious or gentle and carefully, what do think costumers of it (review) and will stay the development crew motivated. If it turns out to be a factory of software no matter what the quality is, just a tool to get a secured periodically income by sending bills, I think that is not a (long term) win.
Short, succinct and to the point. Overjoyed that I somehow stumbled upon this video. Thanks once again.
Suresh/ Strasbourg, France
Merci!
I just reviewed four videos on Kanban to show my teams interested in Kanban. One was gorgeous but bashes scrum. The other was a snooze fest and missed all the key ideas.
Your video was the porridge that was just right! I think I communicate better than most, and I could NOT have done it this well, so thank you!
I have only one criticism. Your definition of agile at the beginning is actually the definition of iterative, not agile. My favorite quote for this, said by my client Andres Borque: Agile = Iterative + Culture.
What makes Scrum and Kanban Agile is the high trust, self-organizing, transparent, collaborative culture. Delivering smaller increments is a part of agile, but it is also a part of iterative (like RUP) even if you aren't embracing agile.
Either way, thank you for a great video. I will recommend it be used with the teams at my current client. :)
Just call me Goldilocks! Great comments of the video. Your "Agile = Iterative + Culture" point is just the kind of distinction I love to dig in to. It's on the list for a future episode!
OK seriously-where has this video been the last 2 years? Amazingly simple that even I can understand :). If I had to pick a nit, I'd point out the "cheetsheat" spelling error at 4:58 but I don't want this content to be removed and so I won't mention it :) (because it has simplified Scrum and KanBan to an incredible level, everybody needs to watch it). Seriously guys, good job!!!! 4.95/5 Stars!!!
Great, thank you! Perfect editing and visualisation of information. Quick, highly informative and convenient.
Thank you! You just amde my day!
This, Sir, is GOOOOD shit! Thank you for taking the time to assemble and share with us. I share the same impressions as the guys below: there was more clarity in your less than 6 minutes videos than all the coaching workshops I've "patiently" attended.
Therefore: I LIKED, SHARED and SUBSCRIBED... What?? The bell's notifications?!! Bitch please... ;) Seriously, thank you very much and by all means, keep it up!
Glad you liked it... and thanks for the like/share/subscribe goodness. 👍
Thanks for the video! Not sure which to use but will consider both!
A perfect mix of Scrum + Kanban = ScrumBan which works perfectly for Agile marketing teams
I have learned a lot in quite a short time. Thanks a lot for the video.
Such a wonderful explanation.
It was crystal clear...
The notes provided at the end is much helpful
Really glad it was helpful!
This was an eye opener on this concept. Thank you
Excellent video!
Probably one of the best on the topic (I wish I had found it 5 years ago).
But Scrum is prescriptive: Ken Schwaber demands purity
Glad you liked the video. And you raise a good point about purity; I tend to blur the lines between the "pure" and the "not-so-pure" versions of Scrum. I may need to tighten this up a bit. Great comment.
I watched in double speed, so in 2 minutes I understand now what has confused for long time, and couldn't find the answer for. Great video!
Excellent hack!
Thanks. Great explinations which are very clear and easy to follow.
Glad you liked it!
Nice video. Helped me in undersanding the difference between Scrum and Kanban in more clear manner.
Excellent - I'm glad it was helpful 👍
well presented. most materials have much too granular definitions, which makes near impossible to truly understand the 'why'
Excellent, This is what called as bite-size learning. In a lucid manner, you explained the complicated topic
Thank you - that's a great comment!
Great Amazing animations and Teacher. 5 minutes made a big difference in my understanding of Kanban and Scrum and Agile
Excellent!
Great video. One thing that would be great to see a video on is reasons why you might choose one over the other (unless you've made it already, I'll go look now 😁)