What you taught me about Scrumban. (And Kanban.)

[@Developmentthatpays]

THANK YOU if you took the time to respond on the subject of Scrumban. Hope you enjoy this episode!

[@orqg5000]

Enjoy both the content of your videos but also the way you deliver it, great job!

[@Developmentthatpays]

Thank you! You just made my day!

[@richardgrieman1483]

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.

[@Developmentthatpays]

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

[@rwj_dk]

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"

[@Developmentthatpays]

It does sound like you've flexed (broken?!?) Scrum to fit you current needs. 👍\

[@fcomarchena]

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.

[@cme64]

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.

[@Fatherfatoants]

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.

[@Developmentthatpays]

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!)

[@benhill4874]

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.

[@Developmentthatpays]

Sounds like you've "broken Scrum" in a carefully-considered way. Nice one!

[@benhill4874]

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.

[@Developmentthatpays]

I don't disagree, but I think the originators believed that there was plenty of room to manoeuvre inside the framework.

[@ofalk1980]

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

[@Developmentthatpays]

Yes, I agree with you. And I'm pretty sure that the Scrum Guide agrees with you too!

[@DanKeeley]

Video Summary: "can of worms"

[@Developmentthatpays]

You nailed it.

[@DeadJDona]

have scrumbangile in cv

[@Developmentthatpays]

Ah ha! A portmanteau word!

[@ashleydickson62]

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

[@Developmentthatpays]

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.