Will the real Scrumban please stand up
HTML-код
- Опубликовано: 27 июн 2023
- 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"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
Let's talk about it.
-------------------
156. Will the real Scrumban please stand up
#scrumban #DevelopmentThatPays
if you tell me that you're doing scrum I have a good idea what you're doing if you tell me you're doing kanban I also have a good idea what you're doing but if you tell me that you're doing scrumbine my first thought is oh oh welcome to development that pays my name is Gary Strawn and I have been something of an advocate for this thing scrum band at least one particular definition of scrum band you see and I suppose therein lies the problem there are at least two scrum bands scrumban the original and scrumban the young Pretender the original the OG was devised by Corey ladas who coined the term and quite literally wrote the book this is scrumban the pathway dare I say it the methodology specifically designed for scrum teams who want to transition to kanban this is the version that I've been an advocate for if you've seen me talk about scrum bum before you will have seen me talking about this particular pathway but there's a new kid in town the young Pretender scrumban the agile framework not just an agile framework but a hybrid agile framework incorporating we're told the very best of scrum and kanban and I have to say if you go Googling for scrumban it's this young Pretender that comes up again and again yes there are references here to the OG but it seems as far as the interweb is concerned the war is over and the young Pretender has won and I'm not sure that that is a good thing for a couple of reasons for one thing I have a theory that the very name scrum ban might be part of the problem if you're hearing about it for the first time here today I wonder if you're already imagining how you might mix and match drop a bit of scrum here add in a bit of kanban there and see what happens and I guess really what my concern is that many people are rolling their very own agile framework perhaps quite randomly and giving it the label scrumban when what it really is is Scrum minus the bits we don't like or find to be inconvenient I wonder if you uh know anyone who might have been guilty of this if you're watching this I'm sure I don't have to tell you don't know every combination of scrum and kanban is going to be valid especially not if we're attempting to create a framework so this young Pretender is going to have to be a specific combination we're going to need a scrum band guide and the great news is I found one the not so good news is I then found another one seems like there are lots of guides definitive guides ultimate guides for how to do scrumban and I wasn't really able to find very much commonality between them than I have to confess that I got discouraged packed up and went home but if you didn't if you have gone through that process of finding out about scromban and found a good source and ideally a source that you then went and implemented I really love to hear from you let me know in them their comments below but as I said my conclusion was this is a big mess I give up but I may have been a little Hasty take a look at this this is from get clockwise.com and it reads scrum band was originally intended to help teams transition from scrum to kanban as we have talked about however many teams found at the midpoint was actually a great place to stay for that reason you'll find nuances in the way that different companies Implement scrumban interesting perhaps what I was looking at was a feature and not a bug scrumban as a collection of agile Frameworks and I guess it makes sense after all the OG the original scrum band was indeed a pathway starting at scrum ending at kanban with presumably scrumban in between multiple scrum bands in between that being the case you'd think we'd be able to find them right here in this book except they're not there this I'm afraid is a lie yes the book starts with scrum yes there are multiple stages along the way but most of those stages are about adding kanban elements to scrum without taking anything away this isn't scrum but this is Scrum and scrum and those kanban elements now what's another name for scrum and bearing in mind the scrum is a Nigel framework that's the important word it's a framework so that we're at Liberty to add things to it meaning that scrum and is the same as scrum me
• Will the real Scrumban... 
Хобби
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: ruclips.net/video/17pYBpCjRcM/видео.html
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.
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!)
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.