Kanban VS Scrum // Definitions, Pros & Cons || Crema
Вставка
- Опубліковано 15 чер 2024
- ----
#Technology #BusinessStrategy #Workshops #UXDesign
Innovation doesn’t happen on its own. We can help you discover, understand, and execute on your business’ greatest opportunities. Learn more 👉 www.crema.us/
Find us almost anywhere:
🤝 LinkedIn → bit.ly/3LebFbb
🤳 Instagram → bit.ly/3LjWY6B
🐦 Twitter → bit.ly/44cZfc3
🎧 Podcast → bit.ly/3HpKbhz
🚀 Crema is a design & technology consultancy that partners with global brands like Adidas, H&R Block, Miro, and Callaway. Headquartered in Kansas City. - Наука та технологія
Check out our blog post on Kanban vs Scrum, including key differences and pros/cons of each framework: www.crema.us/blog/whats-the-difference-between-kanban-and-scrum
Best Kanban vs. Scrum explanation I have found to date! Thank you for just discussing the two vs. doing a tutorial.
This is one of the best, straightforward explanations of the two that I have come across. I would just add that organizations new to agile and lean methodologies most often need to work up to scrum by using incremental hybrid models; otherwise, organizational resistance to the change could be debilitating. For example, begin by using waterfall for overall project design, creating team Kanban boards with daily 10-15 min standup meetings, and then use the information from both to inform development of scrum stories and teams. I’ve found that people accustomed to using waterfall become very frustrated when thrown into a scrum environment as well as have trouble with forecasting and time management, so starting with a hybrid model helps them to better understand and acclimate to scrum while nurturing their ability to forecast as well as recognize the best approach for individual projects and/or stories.
Thank you for this great feedback, Barbara!
Hi I'm a Scrum Master. I manage one dev team using Scrum and another one in Kanban. I really enjoyed your explanation! Great job!
Thank you Evelyn!
Thanks both for your clear knowledge and obvious enthusiasm for the topic(s). Very insightful and helpful points of view here, and great to hear some practical thoughts on how the frameworks work individually, and how they might complement each other together. I appreciate you taking the time.
Glad you enjoyed it!
Wish I had as much confidence and vocabulary as them, especially Tuck!
Thanks for the feedback, George!
Wine helps! LOL
I love how happy the guy is talking about this stuff :D
I'm in a Technical Project Management course and this was extremely helpful.
I'm a little late with my comment, but you two did a fantastic job explaining. As a PM in the construction field, i have always struggled with explaining what methodology i have chosen for any given project, to the team. Your video helps bring those onboard. Cheers!
Thank you Ryan!
Superb practical application and approach advices and recommendations. Appreciate what you guys are doing in a simple way. Thanks 😊
This video was super helpful! Thank you!
Thank you for this overview, a lot of good points. I would add that the most important aspects of Kanban are: being able to control WIP and identify bottlenecks. Also, while Scrum is an Agile methodology, Kanban is Lean, this is why they have fewer ceremonies and often do not bother estimating. However, it can only be beneficial if either the team is self-sufficient and knowledgable about the product and is able to communicate with each other well enough without daily ceremonies OR the workflow is unpredictable, like production support and priorities often change daily. That said, when I have Kanban teams, I do like to incorporate some aspects of Scrum, like standup, perhaps 2-3 times a week, retros about once a month.
Thank you for sharing your perspective, Slava!
Great and important addition.
Thank you so much for this. I work in QA and this is the best explanation so far.
Great overview folks! Love the pros and cons of each and the comments left below. A nice slick production too.
Thank you, Jason!
Wow... I want to implement some agile dev with my team and this really helped me not to just define the methods but to get a feel for them. This was hugely important for me. I also already saw a few videos on the topic. Im glad I still chimed in here!
an excellent way to explain KANBAN vs SCRUM.
Thanks for the video. For bug fixes, which framework between Scrum and Kansan is usually used?
By far the best video about the topic. Keep up the good work!
Thank you! I've looked at several explanations and this one is the best! The only thing I'm slightly confused about is saying that Kanban is harder to predict. Wouldn't we still assign priorities and time estimates to tasks?
Hey there, thank you for watching!
While Kanban can be used to track toward releases using metrics such as cycle time and lead time, we find that we get more accurate projections toward releases when tracking velocity using story points. Most people don’t use Kanban well, which causes the data to be skewed, thus making it harder to predict releases.
Hope this helps!
Helped me ..thank you
Simply marvellous
I see the education of Scrum or Kanban as the responsibility of the Scrum Master/Agile Coach. The Product Manager from my experience is more focused on the client relationship and priorities of work. The Scrum Master/Agile Coach is a neutral party that aides the team in improving their chosen process.
This is totally viable depending on how you set up your teams. Our PdM’s tend to to wear several hats. But we’ve worked the way you described as well. Great feedback. Thanks.
A well-explained video, particularly liked your choice of words. Cheers!
Thank you for the feedback, Radha!
Great video and learned so much today and great insights from you both great minds.
Excellent video on the differences between the two frameworks. I am of the mind that the cons from both could be used depending on the needs of the product or client and the cons of each strategically avoided if it doesn't really help the course.
I am a small startup trying to decide which approach to go so I found this video really helpful.
Glad it was helpful! Thank you for watching.
Really nice breakdown. And I love the wine theme, ha! I have a couple of suggestions for the kanban side of things (even though I'm currently a scrum bag...I mean master...). Kanban can actually give you more accurate projections, given it's a pull based system. It lends itself well to cumulative flow diagrams, how have things gone, and scatter plots, how will things go. Suggestion 1) One of the core properties of Kanban is that Work in Progress is limited. (this eliminates most of the "cons" for kanban). Suggestion 2) It's always easier to start work than it is to finish work (this reinforces why you have WIP limits). In Kanban, you shouldn't start work until the work in front is finished.
Great suggestions Richard! Definitely something for us to consider moving forward. For your second suggestion, we strive to work that way within scrum as well. No individual should have multiple tasks/stories in progress at any one time, thus, shouldn't pick anything else up until their task moves to testing. Thanks again for the suggestions!
The only problem is... they are speaking about Scrum and Kanban like there is only one single application available that completely defines each category. Truth is that I work in they valley and have for like 11 years now. The people they get in to drive the yearly strategy workshops that they pay like $25K to for a day, and all our project managers all use current versions of Kanban PM apps that have all those things that these two say that only Scrum does.
Are they talking about 7-8 years ago or something?
I have nothing against Scrum in general, just that it tends to waste time. Any case.. if you use Kanban and you use it right, you save time and have better releases, happier bosses and customers. Not that you can't with Scrum... sure you can. Just with Scrum you spend more time in meetings rather than doing. Every 45 minute meeting wastes 10 on each side, at least 10 minutes with meeting prelims and about 30-45 minutes to get back into development stride for every developer that is a part of a meeting. That's almost 2 hours of lost programming time multiplied by our typical 7-10 people at a meeting. Do that 6 times in a week like most Scrum is done as and you lose 3 man-weeks of work every week that you wouldn't lose with Kanban. Maybe lost is not the best word, but you do lose that programming time for having the extra mandated Scrum meetings.
Now, if you do Kanban wrong like they are saying, or use a Kanban app that doesn't fit your specific requirements then you would be better off with something that is more of a straightjacket approach like Scrum. However, most would be even better off using a good-fitting Kanban package and using it correctly.
You can also measure performance and velocity in Kanban.
select sum(points) from tickets where state = done and the date is between Monday and Friday.
This is it.
I don’t see scrum as the future of agile development, it’s more like a gamification thingy that leads to exhausted developers.
I personally prefer 6 hour working days with a Kanban board and select tickets from the top 10 of the backlog if you run out.
Great video. Really smooth breakdown!
Thanks Yasir. The wine helps a little with that. 😁
Too bad they are mostly incorrect. They are both generalizing about strengths and weaknesses categorically that most of the better Kanban do not have anymore-- as there is a lot more functional overlap on both sides of the fence, and many offer all those features that they claimed only Scrum provided.
The better platforms combine the strengths and minimize or eliminate the weaknesses of each. Even some of the cheapest like Ora blow most of their assertions out of the water.
I enjoyed the information in this video. Great video
This is an excellent video. Very very helpful. Thank you both!
Thank you for watching, Seth!
Great explanation :) Thanks!
Great and very realistic explanations! I will share this.
Thank you, Tarik!
Kanban does allow teams to forecast by using throughput and cycle counts
Very clear explanation, thank youu!
Glad it was helpful! Thanks for watching!
what is best for Architects or Architectural design? is it Scrum or Kanban?
Motivation to future Product Owners and Managers.
Thanks for watching!
Nice to get some pratical views. Thank you.
Also the receptionist in the back made me giggle
We're glad you enjoyed the video, MacLaks!
Thank you for tuning in.
Felt good after listening to their conversation😍
Thanks for watching!
The Cons that you have outlined for Kanban were a bit confusing to me, because if you are limiting your WIP (as you should be since this is an essential principle in Kanban) then you should be able to see when team members are not being productive as well as have the ability to plan out releases and initiatives by using metrics such as lead time and cycle time. Also, it was mentioned that team members are able to pick up work when they have capacity but again there was no mention of the importance of WIP limits and ensuring flow through the system before bringing new work in.
Lacey, you are absolutely right.
We realized after filming this that a lot of our cons were based on poor implementations of Kanban that we’ve observed. We need to make a follow up video better describing how Kanban should work. Perhaps, rather than us comparing Kanban and Scrum and discussing which one is ‘better’, we should talk about in what context each of these frameworks could be useful.
- Tucker
Scrum Guide never said that velocity is a must. Scrum is just a framework, it does not even have a process. So how can you say it’s process heavy?
Hi Joshua,
Thank you for taking the time to watch our video.
When we talk about Scrum being more process heavy, we’re referring to the ceremonies that are typically part of the Scrum framework and not the Kanban framework. Sorry for the confusion with the wording - we’ll do better next time! Does that help clarify?
In the land of Agile, a tale unfolds,
Of Scrum Bum, whose antics never grow old.
A stinky fellow, with nary a care,
He'd pick his nose, in the open air.
With a backlog stack and sprints to run,
He’d dive right in, thinking it fun,
To pick and roll, his game of choice,
Ignoring the team's collective voice.
Kanban, with belches, and flatulence too,
Would shake his head at the view,
But in the spirit of the agile creed,
He'd focus on flow, and on speed.
Despite his quirks, Scrum Bum did shine,
Moving tasks with a rhythm divine.
Stories completed, and goals met,
His odd habits, the team would abet.
Kanban’s board, a sight so clean,
Except when gas would intervene.
Yet work moved on, with steady pace,
Each card moved forward, it was no race.
They both had their ways, odd though it seemed,
Productivity and results, of which they dreamed.
Pick and roll, belch and breeze,
In Agile land, they did as they please.
The team adapted, to each strange habit,
Finding humor, where others would snabit.
For in the end, the work's what mattered,
Not the noises, nor the noses tattered.
So let us take, from this strange pair,
A lesson in tolerance, and in care.
For it's the outcomes, not the quirks that count,
In Agile's realm, that's the paramount.
Seems like kanban would allow for better pivoting on priorities than scrum because the backlog priorities are so dynamic and can be changed mid development unlike the sprint backlog
awesome explanation!
Thanks for watching!
To the point about scope creep, Agile by it's nature does not have fixed scope except in Scrum during a Sprint the scope should be fixed and even then there may be exceptions such as a blocking production bug that the team will need to pull into a sprint to resolve. So the concept of scope creep really comes into play with if the PM/PO is adding scope to work within the sprint. Otherwise, I agree Product Managers need to have a good communication channel with their stakeholders so they can understand the shifting in priorities and that is also something that should be established at the onset of the stakeholder engagement in terms of how the team delivers work.
To try ally agree. As an agency we are always trying to stoke this balance of expectation, process, and communication. But ideally, you are correct. Thanks!!
Our projects start with Scrum and finish with Scru-Ban-Agi-Lean-JustWingIt... :P
Great video!
Glad you enjoyed it! Thanks for watching
Nicely Done.
Thank you, Mark!
Konbon?
For Better Understanding
KANBAN - IT Support Activities(L1,L2 and L2)
Scrum - Enhancement or Development activities
SAFe - Enhancement or Development activities in Large scale
at 9:40, Is scrum has a project manager role? Must be careful on what we teach to the audience...
May be you should listen more carefully. They mentioned PRODUCT MANAGER.
"To Do, in progress, Done" is not the Kanban Method. Sorry plenty of confusion here. There is no BLOCKED column bro! Blocked is NOT a workstate. If you dont know something dont teach it.
Yall could have your own Bravo / reality podcast. You dont have to do this
Tell me what you need when you need it and I’ll get it done. I’ll show you what’s done when it’s done collect feedback refine backlog and go = kanban
Tell me what is needed let’s prioritize, estimate, plan sprints, review sprints and miss time lines because we waste all our time on the scrum process rather than getting it done = scrum
Kaban seems fine when it's a repeatable process like maintenance where dependencies are always clear and tasks are less complex.
When things get more complex you need the more interaction btwn team members. That interaction creates more clarity so you can go off with your tasks and create your Kanban boards and get towprk within the framework of your sprints.
Above scrum you need a project plan that links your sprints together for large initiatives.
I like the wine-sipping hang vibe but I leave this w/ no real useful information. I feel like live/pre-recorded live streams, like Twitch streamers that stream themself daytrading everyday, is the best way to teach & learn. Answering questions in real time between trades. Undervalued learning process
Thanks for the feedback, Rich!
Awesome info. Btw, just to let you know. they hate each other...definitely.
I have a strong feeling they don't really understand Kanban
Kanban gives more freedom to Dev teams. Scrum is so rigid.
Agree. I think it depends on who you are working with - some people flourish in a kanban format, others can't.
> AJS content. Jussayin' *Ye shrug*
These resource management principals are valuable. There is no denying. What bugs me is the bull-shit "white paper" terminology created to justify the ecospheres of these principals. Eg: "story points". Really? Is that the best nomenclature that educated people could come up with. There are many other examples. So why do we technology developers have the burden of learning and using foreign terms created by Project Managers who cannot be bothered to learn our terminology?
Oh, actually... they have poor understanding of Scrum as well. If this was an interview I won't hire either of them :D
If you're new to scrum and Kanban, make yourself a favor and avoid watching this video. If you're familiar with both, you may watch it for lolz.
Maxim Khasiev which video would you recommend then?
This guy has no idea what a kanban is.