Scrum to Scrumban in 6 Steps + FREE Cheat Sheet

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 on this team. Starting with what happens when this occurs, which it will. Now if a ticket gets blocked, the developer no longer has the option of reaching for another card. It may be necessary, and this could be a revelation, for the team to work together to solve the problem, to unblock this column.

Quick question for you, have we broken Scrum yet? No, I don't think we have. Everything we've done so far is, I think, Scrum compliant. These are changes that you could make to your team today. And maybe, maybe you should.

Another thing you may have heard about Kanban is that it is a pull system, and indeed it is. I'm about to use that term, pull system, rather a lot. So I think we should look at a very quick example, an example that you've probably experienced.

You go into a restaurant, let's say it's a fairly fancy restaurant, and you order yourself an omelet. Believe it or not, you have just triggered a Kanban pull system. The first of a series of pulls. The waitress writes down your order and takes it to the kitchen. Now that piece of paper is the Kanban. Kanban's literal meaning is signal, or sign. So that note arrives in the kitchen. Question, does the chef start on your omelet immediately? Well, she might if your order is the first of the day, but if she's already preparing a meal for someone else, do you think she should start your omelet as well, or would you prefer that she waited until that other dish was finished? I think you already know the answer, she's going to focus on finishing the current dish. Then, and only then, will she reach for the piece of paper with your omelet order, and then she'll set to work on your omelet, ignoring any other orders that come in which she's busy.

When the omelet, your omelet, is ready, the chef will ring the bell to indicate to the waitress that it's time to bring you your omelet. And that bell, that's the second pull. That's the pull system in a restaurant. Let's see the same thing in action back at the office. And believe it or not, the pull system here is enabled by this line. And here's how. When a card moves to the right, it frees up space. And it is this space that is the signal, the Kanban, a signal to the team to pull another card from the left.

I think it's great that we've added a pull to our board, but I think we can take it up a notch. Step number three, add more columns. Step one was about visualizing workflows, and this board was not a bad start. But for most teams, the workflow is a little more involved than this. Let's reflect that by replacing in progress with a column for development, and a column for testing. Each of course with their own work in progress limits.

So DEV pulls from to do, and test pulls from ... ah, yeah, that doesn't quite work. As things stand, DEV is pushing into test. Let's fix that by introducing a buffer between the two. Excellent. Now we have a place for the developers to put cards that they have finished, and test is now empowered to pull tickets in when they are ready to test. Excellent. Let's move on to the next step.

Step four, stop early binding, and start ordering. I wonder if you noticed way back when we did the super speedy sprint planning session, that not only did we assign points to each ticket, we also assigned people. Corey refers to this early binding, and while there's probably short term benefit in giving work to the expert, in the long term the team's ability to handle anything that's thrown at it will suffer.

Again, that's something we could spend a long time discussing. But quite apart from the impact on the long term performance of the team, this early binding can jam up our perfectly positioned pull system. Brian's about to pick up this ticket, even if it's the least important card here. And Carol doesn't have a ticket to pick up at all, at least she won't without a discussion with her colleagues. So let's not do this. In Scrumban, we swap early assignment for ordering and prioritization.

And to make this explicit, I'm going to create a new column called ready. These are cards that are ready to pick up, and importantly, they are presented in order, with the most important at the top. So all things being equal, when a developer is ready to pick up, to pull a card, this is the card to pull. The one at the top, the one that is most important.

Three steps down, two to go, have we broken Scrum yet? I think not. Perhaps the next step is the one that will tear it.

Step five, stop estimating. On our journey so far, there's been no shortage Kanban principles. But now it's time to layer on just a little bit of LEAN. In LEAN, as I'm sure you know, every action that is considered not to have value is considered to be waste. And it can be argued that estimating backlog items does not add value, and should therefore be considered a waste, and should therefore be eliminated.

Now that argument, and I know it's a controversial one, is beyond the scope of what I want to talk to you about today, but rest assured, we will be coming back here on Development That Pays to discuss it more fully. So do stay tuned. But for now, back to the action.

Where was I? Oh, yes. In Scrumban there is no estimating. No story points, no planning poker. The sprint planning sessions becomes a session purely about prioritizing work, and not about sizing work.

That sound was the sound of Scrum breaking. Yes, we've now stepped outside of the boundaries of Scrum, and we're well on our way to Scrumban. But we're not quite there, there's one step still to go.

Step six, move to triggered planning. There's an aphorism that goes along the lines of don't test what you can't release, and don't develop what you can't test. And the board is now perfectly set up to deliver this. Test is pulling from ready to test. Develop is pulling from ready. Ready is pulling from the sprint backlog. Spring backlog is ... ah, yeah, that's where it breaks down.

How do things get in to the sprint backlog? Well, we take ourselves off for a sprint planning session, a session where we move items, selected items, from the product backlog into the sprint backlog. Would it be fair to say it like this, we take items from the product backlog and push them into the sprint backlog. Hmm. I think you can see what I'm getting at here. This part of the process is starting to look like a bit of an odd one out. But is it even possible to apply a pull system to this part of the process, instead of scheduling a sprint planning session every two weeks? Could we trigger a planning session on demand?

We could, and if we want to do Scrumban, we must. The enabler for this is another line. When the number of items in this column drops below a certain point, the trigger point, then it triggers the need for a planning session. Sprint planning happens for most teams once a fortnight. So a valid question would be, does this triggered planning session happen more frequently than once a fortnight? Well, the chances are that it could, possibly that it should, but don't quit on me yet. These sessions, remember, are much more lightweight. No planning poker, no story points, the focus of the meeting becomes only on prioritization. Answering the question, what are the things that the team should work on next?

I'll wrap things up in just a second, but first, the small matter of the cheat sheet that I mentioned at the beginning. It is yours to download today, it will cost you an email address. The email address I will use to send you updates. All Development That Pays cheat sheets improve over time, and when they do, you'll get the copy in the mail. You'll find a link to it somewhere around this video. Let's get right back to the action.

So we've made it all the way from Scrum to Scrumban in six steps. Along the way we lost the concept of a sprint, but did we also lost the sprint review and the retrospective? Not at all, we'd be wise to retain these rituals from Scrum, although now we're going to have to be disciplined about scheduling them in.

Along the way we stopped estimating, which I guess means that we no longer have an indication of the team's velocity, and therefore we no longer can forecast accurately. Actually, that's not quite true. We still have the power to forecast, but that really is a tale for another day.

So we've dropped a couple of things along the way, but what have we gained? By taking Scrum and layering on a generous portion of Kanban, and a sprinkling of LEAN, we've exchanged a relatively heavyweight framework for a lightweight one. We've bought ourselves a little more development time. But most importantly, we've implemented for ourselves a fully fledged pull system. A system that helps us to identify high value items and to get those high value items from backlog to customer in the shortest possible time. That is the promise of Scrumban.

So question of the day, would you consider taking your team on this journey, or at least on part of this journey from Scrum to Scrumban? Let me know in the comments below.

Thank you very much for walking, I hope you enjoyed this episode as much as I enjoyed making it. If you did, I would appreciate a thumbs up, and remember to hit that logo to subscribe for a brand new episode each and every Wednesday. I will talk to you again very soon.