What you taught me about Scrumban. (And Kanban.)
HTML-код
- Опубликовано: 29 авг 2023
- I asked you about Scrumban and your replies caught me by surprise. It is Scrumban that's confused... or is it me?
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
Links:
- The previous episode on Scrumban: • Will the real Scrumban...
- The LinkedIn post on Scrumban: www.linkedin.com/posts/garyst...
A huge THANK YOU to everyone who took the time to reply: you made this episode possible.
-------------------
157. What you taught me about Scrumban. (And Kanban.)
#scrumban # scrum #DevelopmentThatPays
I asked you for your thoughts on Scrumban and you responded in some numbers. I also got more than I bargained for. I've been getting something very wrong and it's time to come clean about it. Welcome back to the shed at the bottom of the garden. You know I had a comment not too long ago casting doubt on whether I really am in a shed at the bottom of the garden. So I think we need to put that one to rest and take this thing outside. Yes, it is a shed. Yes, it is at the bottom of the garden. You're not seeing it at it at its best: that's undercoat; I need to get a top coat on. That's on my Kanban board. But to business! Let's get straight into some of your many many comments. Here's one that I liked: "Dear Gary, I followed your channel for a while and it become quite a fan of Scrumban (excellent!) So now I'm scared... but always excited to see what insights you have to share". Yes, I do have some new insights. And the person who sent me this email is probably not the one that should be scared because, as you'll see, it's more me that became scared the more that I went into the comments. And to foreshadow that a little bit I had another email (I think it was an email - I'm not sure) saying that - in quotes - "If you tell me you're doing Kanban I also have a good idea of what you're doing". I think that was a quote - that was a quote - from me from my previous video all about Scrumban where I talked about how I thought it had an identity crisis and this person has basically said, "The Kanban bit: are you sure " He actually says "Do you think so " Yeah, we'll come back to that because that's quite key to some new realizations that I've been having. As I said, we'll get to that in due course. I sent out an email. I sent out some various quick questions on various places: I guess there was the video itself, all the comments that came into that. I also sent an email to my whole list saying if you have any thoughts on Scrumban please let me know. And last but by no means at least, LinkedIn. I also put a post on LinkedIn asking for feedback and I got plenty. But let's start with a real simple one: "Scrumban isn't that a cross between Agile Scrum and Kanban I think I've heard of it. But other than that I don't really have a strong opinion on the matter." Okay. The one that really made me smile was from Krishna on LinkedIn where he just says "Scrumban the agile turducken." And he provided a nice little picture of that dish - I'll put it up on the screen. And Krishna, you got me. I went looking for the etymology of that word expecting to find it was German or perhaps East European. It's not. It's just the words chicken turkey and duck. Not in that order, is it No: turkey, duck and chicken squashed together. A portmanteau word. I've tried to group these. I've tried to put some structure to it. That's not always easy to do. I had many people saying, well, expressing concern about "this Scrumban thing". Here's a good example of that: "I think many people who want to implement Scrumban don't always have the best intentions. They want some sort of easy watered-down version of Scrum. So really they want ScrumBUT rather than ScrumBAN. So it's Scrum but we're not doing the things that we don't like doing." Yeah, and I think in my in the previous video I'd expressed that very sentiment. This is a good one, also on an email. (By the way, when it's an email I'm not going to mention people's names. When it's LinkedIn I may mention people's names.) This is a good one: "Generally when a team tells me they're using Scrumban, it's another way of saying 'We do Sprints. We don't meet Sprint commitments. We can't make commitments. We pick the parts of Scrum and Kanban we want to do. We get all worked up done so don't bug us'". Yeah. The next series and Malcolm Lisle. Malcolm sent me an email but he also sent
• What you taught me abo... 
Хобби
![DRAGON BALL: Sparking! ZERO - Fused Warriors Trailer [BUDOKAI TENKAICHI Series]](http://i.ytimg.com/vi/84p4Lvyfyes/mqdefault.jpg)
THANK YOU if you took the time to respond on the subject of Scrumban. Hope you enjoy this episode!
As pointed out in previous comment the "answer" to your comment will differ from team to team, but lately my hybrid successes include Kanban, Automated DoD checklists directly on Kanban cards, Standup (Walk the board style) and finally Scrum Retro.... leaving out Scrum Planning/Estimation (waste of time IMHO) and Scrum Review (CICD don't need it)... Aka what fits for the Teams I manage currently
And yes, I tried pure Scrum and liked it back in the day... Me, my Teams, and my customers have just outgrow such rigid ways with especially all the meeting and spend our time instead on agile delivery and less on "ceremony"
It does sound like you've flexed (broken?!?) Scrum to fit you current needs. 👍\
I'm in kind of the same boat, because of the mostly unpredictable nature of the workload we manage. However, we try to follow agile principles. Experience has led us to become backlog prioritization ninjas mostly.
I’m a SCM and PMP with a lot of agile experience and currently teach Agile Project management.
I personally have always referred to the mixing of Scrum and Kanban as a “Shotgun Marriage” because, while many teams like the idea of adding Kanban to Scrum, the two simply are not a natural fit and adding Kanban can break Scrum to the detriment of the team.
It seems to me Extreme Programming is much better fit with Scrum and xP can be added without breaking Scrum. Extreme Programming defines a set of operating processes (not all of which need to be implemented) that allows the team to build and run an engineering workflow. Scrum defines a set of ceremonies and meetings the allow the team to define the necessary work quickly. Extreme Programming and Scrum are attempting to solve to different problems and naturally fit together to give guidance to the team from how to gather requirements, through the building and release stage of a project. You can bend and stretch xP and Scrum to fit the teams needs without fatiguing either framework while building an engine to create a product in a very short time.
This, to me, makes more sense that attempting to fit Kanban, with it’s ruleless set of principles, into the formal, codified framework of Scrum.
I feel bad that I missed this comment when it first came in: so much good stuff here. I'm going to see if I can track you down on LinkedIn.👍
Enjoy both the content of your videos but also the way you deliver it, great job!
Thank you! You just made my day!
Kirk Bryde thoughts were very good.
If you are technically following Scrum to the letter, it is counterproductive. Remember Agile Principal #1 - "our highest priority is to satisfy the customer through early and continuous delivery of valuable software". Following a framework strictly is not the goal.
I don't disagree, but I think the originators believed that there was plenty of room to manoeuvre inside the framework.
I love this content, and your other videos as well.
When I first tired working with scrum it felt rigid, and not realistic with the world around us. I had to use a board very much like a Kanban board to make it more viable. Now I came across Scrumban and I understand where it came from but not what it has become. Even though I believe Kanban (or other boards) boards adds clarity to scrum, something still feels missing. Task estimations should not be removed, as time constraints are important too. but being rigid about a sprint restricted by time isn't also a solution. Maybe we need to keep the time estimates per task, estimate the total sprint's work based on dependencies and team size, and since we mostly do it on some application, the calculation can become automated. The tasks prioritization can be assisted with multiple inputs to be pushed into the to do list (e.g. assigned priority, estimate time, dependencies ... etc) to ensure continuity in the development process.
We've been using Scrumban for a bit now, and while it certainly helped increase throughput it didn't noticeably increase quality. We did find that the traditional "as a, I want, so that" wasn't working well and switched over to a more narrative format. It still carries the spirit but has led to a more holistic understanding of the story.
You've made me realise that we don't often talk about quality and Agile in the same breathe. (That might make for a good video at some point!)
We use Scrum generally. But because of our situation and how work comes into development, Scrumban works better. For us, that means we follow scrum, but we don't plan all our work into a sprint. We generally decide what we want to get done in a sprint, but we feed the work in, meaning assign it to a developer based on priorities set by the scrum leader/product owner, as needed.
We still do the morning stand-up, very valuable, we do the review as demos, for our business unit, of work completed. The sprint planning and retrospective have recently been combined. We will see how this combination works over the next few months.
Sounds like you've "broken Scrum" in a carefully-considered way. Nice one!
I think it's fair to use a mix'n'match approach that fits your team's needs, but I'm a strong believer that if one doesn't follow the (Scrum) book by it's letter, it shouldn't be called Scrum. I had that discussion over half a decade ago, where they wanted to introduce Scrum. I explained the requirements and immediately people started to complain that it's too much effort, too complicated/complex and we should reduce it to only a few of the ideas. My answer to this was: That's OK, but then call it an agile methodology and not Scrum, because it (essentially) isn't Scrum any more (and don't count on me to be the Scrum master in this mess).
Yes, I agree with you. And I'm pretty sure that the Scrum Guide agrees with you too!
Video Summary: "can of worms"
You nailed it.
have scrumbangile in cv
Ah ha! A portmanteau word!
Honestly, all this scrum, kanban, scrumban becomes a triumph of illogical definition over simply doing what is effective in the circumstance, ie dogma over agility...
I've heard that a lot over the years, mostly (entirely?) from developers like me. People who are really well placed to "do the thing right"... but are very poorly placed to "do the right thing". And they're poorly placed to even realise it.