Scrum to Scrumban in 6 Steps + FREE Cheat Sheet

Here's your roadmap for the journey from Scrum to Scrumban. And remember to grab your FREE CHEAT SHEET!
https://www.developmentthatpays.com/cheatsheets/scrum-to-scrumban
In 2009, Corey Ladas gave us Scrumban. He presented it - not as an alternative to Scrum and Kanban - but as a PATHWAY from Scrum to... something more "kanban-like".

In this episode, we'll walk that pathway: Six steps that take SCRUM and add layers of KANBAN and LEAN.

Along the way, we’ll step outside of the boundaries of Scrum... but you may be surprised at how we get before we “break out”. Which means that even if you have no plans to move from Scrum to Scrumban… this episode is a must-watch.
= = = = = = = = = = = =

JOIN the Development That Pays COMMUNITY (it's free!):
→ https://www.developmentthatpays.com/community

SUBSCRIBE to this Channel:
→ http://www.DevelopmentThatPays.com/-/subscribe

= = = = = = = = = = = =
-------------------
126. Scrum to Scrumban in 6 Steps + FREE Cheat Sheet
# #DevelopmentThatPays

Last time I introduced you to this man, Corey Ladas, and his invention, I guess you could call it that, Scrumban. If you missed that episode and you'd like to catch up, you can find a link to it over here. As I said in that episode, Corey didn't so much position Scrumban as a midway, halfway house between Scrum and Kanban, rather as a pathway from Scrum to ... well, to something else. This I think was a super shrewd move, given the level of adoption of Scrum, and the fact that Scrum is often the first step that teams take when getting in to Agile. So how easy is it to follow this pathway from Scrum to Scrumban Well, I think we should go and find out. And as we travel, keep your eyes open for the moment that we break, or breakout, of Scrum. I think you might be surprised at just how far we get before we do so. Step one, visualize the work. Oh, you thought this journey was going to be difficult If you're like most Scrum teams, you probably already have a board. And the board is just one of the things that Scrum doesn't mandate. In Kanban though, a board is mandatory. It's one of the key tenants of Kanban that we must visualize our work. So if you have a board, even one as simple as this one, then you've already taken your first step toward Scrumban. Congratulations. At this point I'd like to introduce you to the team we're going to be working with today. I'm going to ask them to take themselves off for a super quick sprint planning session. And I do mean super quick. Thank you very much, team. Eight items, let's call them tickets, in the to do column. As this is Scrum, we could also call the to do column the Sprint Backlog, they're effectively one and the same. Time to set to work starting each day, of course, with a daily standup. One thing that every developer knows, but few will admit, is that it's much easier to start a job than to finish it. So if we check in with this team again after a couple of days, there's every chance that their board will look like this. And this where visualize the work starts to pay us back. It's very clear that the three developers are attempting to work on eight tickets simultaneously. I could spend a whole video, a whole series of videos, talking about why this is undesirable state of affairs, starting with the cost of context switching. But for now, I think we'll just move on quietly to step two. Step two, impose work in progress limits. If you know anything at all about Kanban, you'll know that one of the things it does is to impose work in progress limits. So let's give that a go. I'm going to rewind to the beginning, and this time each developer is allowed to work on a maximum of two tickets at any one time. Ideally, it would be just one ticket, but we know that things happen, and tickets can get blocked. So, we're going to give people just a little bit off leeway. So two tickets maximum. Let's see how that plays out. Fast forward a couple of days, and oh, it does seem now that we have all three developers working on exactly two tickets, we've given them the opportunity to work on two, and they haven't been slow to take us up on our offer. They've stayed within the letter of the law, but the spirit of the law, not so much. I think we should try a different work in progress limit, something a little more Kanban style. And I'm going to do that, not by applying a limit to a person, but by applying a limit to the process. The process here is the in progress column, and I'm going to squish it so there's only room for one ticket in the column. And I'm going to draw a hard limit at five tickets. It's hard to overstate the impact of what that simple change will have
https://www.youtube.com/watch?v=fgT4AaKcBUA&list=PLngnoZX8cAn_niM2ehLsFGPh33DGU5it9

Видео Scrum to Scrumban in 6 Steps + FREE Cheat Sheet канала Development That Pays