Will the real Scrumban please stand up

I've been something of an advocate for Scrumban. But I'm the first to admit that it has a problem: it suffers from an identity crisis.

= = = = = = = = = = = =

New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"

= = = = = = = = = = = =

Let's talk about it.

-------------------
156. Will the real Scrumban please stand up
#scrumban #DevelopmentThatPays

[Developmentthatpays]

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?

[benhill]

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.

[hollie-annegale]

Scrumban = Scrum - minus the bits we don't like!
Soooo true! It's like the Scrum pick a mix!

[paulhutchinson]

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

[rwj_dk]

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)

[duanestrong]

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.

[paulhutchinson]

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.