Previously I introduced you to Corey Ladas on Scrumban. Today, I'm going to be taking
you all the way from Scrum to Scrumban in just six steps. And stay tuned to the end,
because I have a rather lovely cheat sheet for you.
Welcome to Development That Pays, the channel dedicated to profitable software development.
My name is Gary Straughan, and if we're meeting for the first time, please consider subscribing
and remember to hit that bell icon so you don't miss a thing.
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.