Don't we and shouldn't we fit the processes to our situations? We use the Scrum ceremonies but like to feed work in as needed, as Kanban does. It fits our situation.
"If you tell me you're doing Kanban, I also have a good idea what you're doing" - do you think so? Because Kanban says "start with what you do now", there can be a LOT of mystery in a Kanban implementation, figuring out how to plan the work and implement feedback loops. I think there is potential value to be gained by borrowing elements of Scrum for your Kanban implementation (e.g. planning the work in X week cycles), even where other Scrum elements are not appropriate. But the fact that there is no definitive "Scrumban Guide" is a good point - Scrum has an official guide, and Kanban has (at least) two official guides, so the rules of the game are quite clear. Maybe if Scrumban has it's own value, it needs its own official guide.
The advantage of an official guide is that if what you're doing isn't working or has stopped working effectively, then anyone on the team can point to the official guide and say "hey look, why aren't we doing it that way?"
As Fred Brooks said, there is no silver bullet. So I always get concerned when a team says "we are doing X" as the implication is that if you just follow the directions on the label of X *exactly* then all your problems are solved. Whatever X is it needs to be tailored to each team. I know that you know this, but my experience has been that most developers especially those just starting out do not, and will be pedantic about "but the Scrum book says do bla bla bla". This team customization can be a slippery slope I agree, and often teams go over the line and do dumb things that just can never work. I did say no silver bullet. At this (late) point in my career I've gone to the "flow" side and think Kanban just works better with less energy expended. I think the advent of CI and CD is at odds with Scrum's sprint cycle.
I tend to agree with you in past videos, but here I strongly disagree. IMHO it is bad to be a framework purist in 2023, saying you need to follow a framework to the letter. A hybrid of bits from ALL frameworks is what I find best as long as you are agile in evaluating your process of what work best for your team (process-retro), then you get the best of everything... If, you call it "Scrumban", some other name or nothing at all is not the main point here... The point is to work in a manner that fit you and your team... Yes, not a popular opinion among licenced scrum-masters (it treaten their job, if everyone does whats best for them and not what the guide/framework says)
I regret only that I have but one upvote to give. My first reaction to this video was that this sort of gatekeeping is unhelpful at best. Then I thought about how we would (and do) react when organizations say they’re ‘doing Agile’ or ‘doing Scrum’ but have simply changed the labels on their waterfall. But I think the overall point is to do what works for your team. Take the things from each framework or approach that make sense in your situation. Maybe estimating and planning are a waste of time, but retrospectives are super valuable (that one I would actually make non-negotiable). Maybe you see a ton of value in reviews. Experiment and do what works.
I'm working with a team that seems to me to be a good candidate for Scrumban. This is not a software development team, but rather a deployment scripting/remote installation team for a large customer estate. We're using the Kanban Method to improve transparency of the work, limit work in progress, and evolve the team's working practices. The team struggles to plan their work effectively, because they are constantly being disrupted by customer representatives who hijack the most experienced members of the team for urgent tasks that are not coordinated with each other at an overall level. Because of this hijacking, the team struggles to keep the service documentation up to date, which would allow the work to be shared with more people than the 1 or 2 most experienced members of the team. To me, Sprint Planning every 2 weeks offers an opportunity to bring the team together to focus together on their objectives (in a way not offered by Kanban alone) - to identify the most important customer requirements, to set Sprint Goals, to agree what needs to happen in order to deliver the customer's most important requirements in a professional way that suits the team's longer term agendas. Retrospective meetings are another Scrum element that would be useful in this context. Sprint Review meetings would not be useful here though - the software development is done by a different organisation, there is nothing to demo at the deployment/installation stage. "Scrumban" seems like a good name for this hybrid approach.
Love to hear your thoughts on this: even if Scrumban (the Original) is "a good thing", has the "Young Pretender" muddied the waters too much?
Thank you all for your comments. I included some of them in this follow-up episode: th-cam.com/video/17pYBpCjRcM/w-d-xo.html
Scrumban = Scrum - minus the bits we don't like!
Soooo true! It's like the Scrum pick a mix!
EXACTLY! (Damn: I missed the chance to put a pic of Pick & Mix in video!)
Don't we and shouldn't we fit the processes to our situations? We use the Scrum ceremonies but like to feed work in as needed, as Kanban does. It fits our situation.
Scrambledban... at the end😅
I might have to use that!
"If you tell me you're doing Kanban, I also have a good idea what you're doing" - do you think so? Because Kanban says "start with what you do now", there can be a LOT of mystery in a Kanban implementation, figuring out how to plan the work and implement feedback loops. I think there is potential value to be gained by borrowing elements of Scrum for your Kanban implementation (e.g. planning the work in X week cycles), even where other Scrum elements are not appropriate. But the fact that there is no definitive "Scrumban Guide" is a good point - Scrum has an official guide, and Kanban has (at least) two official guides, so the rules of the game are quite clear. Maybe if Scrumban has it's own value, it needs its own official guide.
The advantage of an official guide is that if what you're doing isn't working or has stopped working effectively, then anyone on the team can point to the official guide and say "hey look, why aren't we doing it that way?"
As Fred Brooks said, there is no silver bullet. So I always get concerned when a team says "we are doing X" as the implication is that if you just follow the directions on the label of X *exactly* then all your problems are solved. Whatever X is it needs to be tailored to each team. I know that you know this, but my experience has been that most developers especially those just starting out do not, and will be pedantic about "but the Scrum book says do bla bla bla". This team customization can be a slippery slope I agree, and often teams go over the line and do dumb things that just can never work. I did say no silver bullet.
At this (late) point in my career I've gone to the "flow" side and think Kanban just works better with less energy expended. I think the advent of CI and CD is at odds with Scrum's sprint cycle.
I tend to agree with you in past videos, but here I strongly disagree. IMHO it is bad to be a framework purist in 2023, saying you need to follow a framework to the letter. A hybrid of bits from ALL frameworks is what I find best as long as you are agile in evaluating your process of what work best for your team (process-retro), then you get the best of everything...
If, you call it "Scrumban", some other name or nothing at all is not the main point here... The point is to work in a manner that fit you and your team... Yes, not a popular opinion among licenced scrum-masters (it treaten their job, if everyone does whats best for them and not what the guide/framework says)
I regret only that I have but one upvote to give.
My first reaction to this video was that this sort of gatekeeping is unhelpful at best. Then I thought about how we would (and do) react when organizations say they’re ‘doing Agile’ or ‘doing Scrum’ but have simply changed the labels on their waterfall.
But I think the overall point is to do what works for your team. Take the things from each framework or approach that make sense in your situation. Maybe estimating and planning are a waste of time, but retrospectives are super valuable (that one I would actually make non-negotiable). Maybe you see a ton of value in reviews. Experiment and do what works.
I'm working with a team that seems to me to be a good candidate for Scrumban. This is not a software development team, but rather a deployment scripting/remote installation team for a large customer estate. We're using the Kanban Method to improve transparency of the work, limit work in progress, and evolve the team's working practices. The team struggles to plan their work effectively, because they are constantly being disrupted by customer representatives who hijack the most experienced members of the team for urgent tasks that are not coordinated with each other at an overall level. Because of this hijacking, the team struggles to keep the service documentation up to date, which would allow the work to be shared with more people than the 1 or 2 most experienced members of the team. To me, Sprint Planning every 2 weeks offers an opportunity to bring the team together to focus together on their objectives (in a way not offered by Kanban alone) - to identify the most important customer requirements, to set Sprint Goals, to agree what needs to happen in order to deliver the customer's most important requirements in a professional way that suits the team's longer term agendas. Retrospective meetings are another Scrum element that would be useful in this context. Sprint Review meetings would not be useful here though - the software development is done by a different organisation, there is nothing to demo at the deployment/installation stage. "Scrumban" seems like a good name for this hybrid approach.