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 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.
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!
Perhaps the only channel which knows how to teach and deliver effectively. These 5 minutes were more productive than watching hours and hours of videos and reading tons of articles on this subject, yet left confused and unclear. Thank you for providing such a quality education. ❤
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.
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.
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.
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!
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.
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!
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.
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...
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!
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!!!
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
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!
We need this kind of animation rather than telling stories the whole time. The best way to make beginners know those approaches. Thanks for the effort.
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.
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: th-cam.com/video/fgT4AaKcBUA/w-d-xo.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
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! 🎉
Thanks for this. Quick correction - Sprint planning is 'not run' by Scrum master. I understand the sentiment of what you are trying to say, but some people might not. I think a better way to phrase it is the Sprint planning meeting is attended by Product owner, scrum master, the dev team, and any outside teams/tech experts that dev teams believes they need opinion of/help with. It is time boxed. And should the team feels they need someone to facilitate the meeting, Scrum master facilitates and guides/coaches everyone on how best these meetings can be conducted.
Good stuff. I know they may not be a part of either framework, but Definition of ready to let items into the sprint, and the Definition of Done, to gain a universal agreement on what it means for a work item to be done, are as important as wip limits imo. They help prevent work from getting stuck inside the sprint, or forgetting quality gates on the way out. Super helpful video overall though. Just thought I'd add this thought.
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.
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.
Excellent explanation, short and to the point, very clear, firms up and fills in my understanding, thank you DTP. Only negative (you wanted feedback) following the link for your cheat sheet, I put my email address in, tick the boxes to subscribe, and then I'm just given an advert run around for a course and material I don't want but there's no option to actually get the cheat sheet or am I missing something. Is this just clickbait? That bit is not cool. *EDIT* So entering an email address gets a link emailed to you to then download the cheat sheet, instead of being able to download it there and then after putting your email in. There's no message to say that's what is happening just the advert but I got the cheat sheet in the end. Thankyou! 👍🙂
My bad: yes the cheatsheet is sent by email , but there's no note to that effect. NOT COOL (as you said). I'll get that fixed as soon as I can. Thank you for taking the time to let me know. Much appreciated.
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.
I checked and the way it's setup is very misleading. Sorry about that. Yes, the offer of the course pops up. BUT... the cheat sheet was sent to you by email. Maybe check spam. Or drop a line to me at "gary at garystraughan dot com"
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!
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.
Great informational video - concise, eloquent and perfecly timed. The only thing I have a gripe with is the fact that e-mail is required to download the cheatsheet. Hence, it's not free - not in my definition of free anyway. I understand the reasoning behind it, but it's not the way to go. I don't know how many mailing lists you all are subscribed to, but the sheer volume of it is driving me crazy and I am very much inclined to develop a grudge against each and every instance that sends me e-mail and consequently to ignore them.
Great visual explanation. The only discrepancy I found is that the Sprint Review is not meant to be a "Demonstration", but an overview of what items/value were delivered in the by the current sprint.
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
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.
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.
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.
@@Developmentthatpays When non-devs try to sequence things based on their emotions (fun) they can create a ton more work for the developer. The developer knows which things need to happen first.
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.
Fantastic.. I always prefer videos over reading ebooks and trhis video just taught taught me things in 5 mins which could have taken me days if I was reading.
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.
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.)
This video helped me understand something that I have been trying to for more than 6 months. Cannot believe that I did not find this early. Thanks much. Life Saver. A few Questions. 1. When do Kanban teams do demos? 2. When is the retrospective conducted? 3. Also, is no one from the KANBAN team involved in release work? If so how do they maintain 100% efficiency in development? I think I know the answers to the above but would still like to hear from you.
Glad you enjoyed the video. I like your questions. Kanban teams *can* do demos... and retrospectives. They do them "as required". However, without the natural "rhythm" of a Sprint, there's a danger that they... get forgotten. Kanban teams can - and should - be involved with release work. What are your thoughts?
Your answers are inline with what I had in mind. I think it's fair to say that when using KANBAN the team is involved in demos and retrospectives and release work they are not always a 100% involved in pure development throughout. The flexibility that this offers if used wisely can be of added benefit.
If anything, the Agile approach - Scrum, Kanban or a range of other approaches - *reduces* the percentage of "pure development" time. Agile is not *efficient*. But it can be *effective*.
Truly excellent and succinct. Better than any similar video I've seen on TH-cam in every way, especially because it's accurate and saves time. Thank you.
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.
Nice! However, Kanban tends to be more flexible than what you described. It depend on the org and teams. For mine (software dev) we work with 7 columns on our board including a “To Do” column that is similar to a scrum backlog and 2 columns for tracking QA activities. We have drops (like sprints but in several weeks and months timeframes) based on quarterly deliverables. We just keep pulling from todo column based on Dev availability and blocked user stories. We have story points and priority ranking as well. Lastly, it’s team ran and we all work directly with our product owner (who is assigned to one Dev team). They’re kinda like a Agile Coach as they manage the board, but there are clear differences.
i JUST LANDED MYSELF FIRST GRADUATE JOB FROM IT SECURITY BACKGROUND TO QA ENGINEERING SO I NEED TO LEARN THIS ALL IN 1 WEEK BEFORE I START !! THANK YOU SIR
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.
A nitpick I'd like to mention is regarding the very start of the video. Scrum and Kanban are not methodologies but frameworks which fit into the methology of agile.
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 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.
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!
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!
Perhaps the only channel which knows how to teach and deliver effectively. These 5 minutes were more productive than watching hours and hours of videos and reading tons of articles on this subject, yet left confused and unclear.
Thank you for providing such a quality education. ❤
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!
Simplicity is the ultimate sophistication. Killer job, man.
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!
That's the clearest explanation of both Kanban and Scrum that I've yet seen. Thank you. Liked and subscribed.
Awesome, thank you!
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!
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 👍
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!
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.
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!
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."
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.
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 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.
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!!!
Incredible tutorial. I used to love SCRUM and the name Kanban was interesting to me. However the process of Kaban seems more interesting.
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
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!
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!
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.
We need this kind of animation rather than telling stories the whole time. The best way to make beginners know those approaches. Thanks for the effort.
I love how you are clear and explained everything simply
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!
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!
This is the best explanation of differences I have seen! Clear and simple. Thank you
Glad it was helpful!
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: th-cam.com/video/fgT4AaKcBUA/w-d-xo.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
such a short , simplified and perfect way to summarize the differences ...Kudos to the author!
Thank you! Glad you liked it 👍
What an amazing explanation. Easy and concise. Thank you for putting this info together!
You are most welcome. Glad you liked it!
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!
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 👍
Thanks for this. Quick correction - Sprint planning is 'not run' by Scrum master. I understand the sentiment of what you are trying to say, but some people might not. I think a better way to phrase it is the Sprint planning meeting is attended by Product owner, scrum master, the dev team, and any outside teams/tech experts that dev teams believes they need opinion of/help with. It is time boxed. And should the team feels they need someone to facilitate the meeting, Scrum master facilitates and guides/coaches everyone on how best these meetings can be conducted.
You're right. 100% agree with your description. 👍
Literally the most clear explanation! Thank you ❤️
Good stuff. I know they may not be a part of either framework, but Definition of ready to let items into the sprint, and the Definition of Done, to gain a universal agreement on what it means for a work item to be done, are as important as wip limits imo. They help prevent work from getting stuck inside the sprint, or forgetting quality gates on the way out. Super helpful video overall though. Just thought I'd add this thought.
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.
Nice video. Helped me in undersanding the difference between Scrum and Kanban in more clear manner.
Excellent - I'm glad it was helpful 👍
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.
Very crisp platter in many many videos on youtube. Thanks for building such a short but valuable video.
You are most welcome! 😊
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.
Excellent explanation, short and to the point, very clear, firms up and fills in my understanding, thank you DTP. Only negative (you wanted feedback) following the link for your cheat sheet, I put my email address in, tick the boxes to subscribe, and then I'm just given an advert run around for a course and material I don't want but there's no option to actually get the cheat sheet or am I missing something. Is this just clickbait? That bit is not cool. *EDIT* So entering an email address gets a link emailed to you to then download the cheat sheet, instead of being able to download it there and then after putting your email in. There's no message to say that's what is happening just the advert but I got the cheat sheet in the end. Thankyou! 👍🙂
My bad: yes the cheatsheet is sent by email , but there's no note to that effect. NOT COOL (as you said). I'll get that fixed as soon as I can.
Thank you for taking the time to let me know. Much appreciated.
Great job and teacher. I appreciate this gift you have.
Following Kanban my whole development career without even knowing the name Thanks for the video
Nice one!
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 video. in my team some people call our approach as Scrumban. But its just regular scrum with Kanban board, nothing else
Except the Cheat Sheet is is only free if you buy the course. The clue is in the name "cheat". Nice work!
I checked and the way it's setup is very misleading. Sorry about that.
Yes, the offer of the course pops up. BUT... the cheat sheet was sent to you by email. Maybe check spam. Or drop a line to me at "gary at garystraughan dot com"
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!
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.
Great informational video - concise, eloquent and perfecly timed. The only thing I have a gripe with is the fact that e-mail is required to download the cheatsheet. Hence, it's not free - not in my definition of free anyway. I understand the reasoning behind it, but it's not the way to go. I don't know how many mailing lists you all are subscribed to, but the sheer volume of it is driving me crazy and I am very much inclined to develop a grudge against each and every instance that sends me e-mail and consequently to ignore them.
Glad you enjoyed the video... and yes, the email thing is a bummer.
Incredible tutorial. Wonderful. Good job.
Great visual explanation. The only discrepancy I found is that the Sprint Review is not meant to be a "Demonstration", but an overview of what items/value were delivered in the by the current sprint.
You're right 100%. (Back then, we didn't know better.)
@@Developmentthatpays It is still a great video and better than I could do.
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.
Ok, I'm here in 2025, 8 years after publishing this video. And I still found it very useful, thanks!
same 😊
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.
These both sound like they're for business owners. Would either of these systems be helpful for an individual who just wants to organize themselves?
Scrum possibly. Kanban more likely. I recommend doing a search for "personal kanban".
@@Developmentthatpays Thanks, will do.
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
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!
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.
@@Developmentthatpays When non-devs try to sequence things based on their emotions (fun) they can create a ton more work for the developer. The developer knows which things need to happen first.
I am going to use it for my interview and will share the result. amazingly explained.
Hope the interview goes well. Good luck!
Aaaand here's a video that does in 5 minutes what a thousand blog posts have not done in a decade.
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.
Animations are helpful in memorizing these stuff.
Glad you liked the animations!
Fantastic.. I always prefer videos over reading ebooks and trhis video just taught taught me things in 5 mins which could have taken me days if I was reading.
What a lovely comment. Thank you!
Great pace, v clear, thank you for uploading this :-)
Thank you! Glad you enjoyed it.
Thank you so much sir for made this video. Your explanations are very easy to understand.
That's nice of you to say so. Thank you!
Good shot, thnx much, really defines well enough!!!!
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.
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.)
Best video on earth saved my day before the exam !!!! ❤️❤️❤️ Love it
*_DELIGHTED_* that it was helpful for you!
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.
This video helped me understand something that I have been trying to for more than 6 months. Cannot believe that I did not find this early. Thanks much. Life Saver.
A few Questions.
1. When do Kanban teams do demos?
2. When is the retrospective conducted?
3. Also, is no one from the KANBAN team involved in release work? If so how do they maintain 100% efficiency in development?
I think I know the answers to the above but would still like to hear from you.
Glad you enjoyed the video.
I like your questions. Kanban teams *can* do demos... and retrospectives. They do them "as required". However, without the natural "rhythm" of a Sprint, there's a danger that they... get forgotten.
Kanban teams can - and should - be involved with release work.
What are your thoughts?
Your answers are inline with what I had in mind. I think it's fair to say that when using KANBAN the team is involved in demos and retrospectives and release work they are not always a 100% involved in pure development throughout. The flexibility that this offers if used wisely can be of added benefit.
If anything, the Agile approach - Scrum, Kanban or a range of other approaches - *reduces* the percentage of "pure development" time. Agile is not *efficient*. But it can be *effective*.
Agreed! In this ever so complex development environment we need something effective.
0:00 tbh I came to this video to learn about how to cook cup cakes.
th-cam.com/video/HHm6hzxHpzY/w-d-xo.html
simple and lucid explanation
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
@@steveabiola447 sure... when?
Thank you for the summarized video.
My pleasure!
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
Truly excellent and succinct. Better than any similar video I've seen on TH-cam in every way, especially because it's accurate and saves time. Thank you.
Thank you! Very nice of you to day so. 👍
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
Nice! However, Kanban tends to be more flexible than what you described. It depend on the org and teams. For mine (software dev) we work with 7 columns on our board including a “To Do” column that is similar to a scrum backlog and 2 columns for tracking QA activities. We have drops (like sprints but in several weeks and months timeframes) based on quarterly deliverables. We just keep pulling from todo column based on Dev availability and blocked user stories. We have story points and priority ranking as well. Lastly, it’s team ran and we all work directly with our product owner (who is assigned to one Dev team). They’re kinda like a Agile Coach as they manage the board, but there are clear differences.
Thanks for sharing your process: sounds like it's working well for you. 👍
In my team, we simply use a mixture of boths styles, with longer sprints, and minus the cult-like stuff :D
i JUST LANDED MYSELF FIRST GRADUATE JOB FROM IT SECURITY BACKGROUND TO QA ENGINEERING SO I NEED TO LEARN THIS ALL IN 1 WEEK BEFORE I START !! THANK YOU SIR
CAN ANYONE SUGGEST VIDEOS I CAN LOOK AT TO FAMILIARISE WITH QA AS MUCH AS POSSIBLE ?
Wow - that's great news! Good luck with your new role.
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...
Great explanations for both. Thank you. Explained simply and without top-heavy graphics.
You're very welcome!
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.
This video is wonderful. I understand the difference between scrum and Kanban by watching the video. Thank you so much
Thank you! You just made my day 👍
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.
Thanks for the explanation, as well as the attached sheet.
FRAMEWWORK! not Methodology
I know, I know. I'm ashamed of myself. 😱
@@Developmentthatpays Whats the difference?
Great Amazing animations and Teacher. 5 minutes made a big difference in my understanding of Kanban and Scrum and Agile
Excellent!
A perfect mix of Scrum + Kanban = ScrumBan which works perfectly for Agile marketing teams
Short, succinct and to the point. Overjoyed that I somehow stumbled upon this video. Thanks once again.
Suresh/ Strasbourg, France
Merci!
A great contribution to clarify the differences between Scrum and Kanban !
Glad it was useful.
Absolutely phenomenal way of explanation, clear n crisp! 👏🏻
Thank you!
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!
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
A nitpick I'd like to mention is regarding the very start of the video. Scrum and Kanban are not methodologies but frameworks which fit into the methology of agile.
You're quite right: frameworks, not methodologies 👍
Great, thank you! Perfect editing and visualisation of information. Quick, highly informative and convenient.
Thank you! You just amde my day!