- Previously, six steps from Scrum to Scrumban.
Today, a canal, two swans,
a rain shower, and a big pile of your comments.
Hi, my name is Gary Straughan.
Welcome to Development That Pays,
and welcome to the Grand Union Canal,
one of my favorite destinations
for a Saturday morning bike ride.
But this Saturday, I've swapped my Lycra for a jacket,
'cause I thought we'd try a little bit
of an outside broadcast, so let's get this thing started.
So I've moved just a little bit away from the canal
to get away from the canal-side traffic,
and taken a couple of steps closer to Heathrow Airport.
I don't know if you can hear it in the background,
a plane taking off.
So not ideal for my outside broadcast,
but I'm gonna carry on like the trooper that I am.
So that video, Scrum to Scrumban,
well I never really know how a video's gonna go down,
but that one in particular was a concern,
and not least because in a way
it's attacking a bit of a sacred cow.
Not all of us are ready to even consider
moving away from Scrum.
So I wasn't sure the reaction that I would get.
I wasn't really sure I'd get any reaction at all,
but here I have a printout of all
of the comments that came in.
As you can see, I've scribbled over quite a lot of them,
which gave me a challenge of how to structure
this particular video, 'cause I do want
to address most of the comments that came in.
So I think the logical sequence is probably,
just chuck that to one side,
is probably to stick with this.
This the Scrum to Scrumban cheat sheet.
You will find a link to this
in the description right below this video.
It's not free, I shall tell you that straight away.
It will cost you an email address.
And one of the reasons I ask for an email address
is so that I can send you updates
if and when a mistake is spotted.
And you guys out there are very good at spotting mistakes.
It turns out that this, the very first issue
of the Scrum to Scrumban cheat sheet
had a little bit of a howler right at the bottom,
arguably the most important line on the entire thing.
Congratulations, you are now doing Scumban?
So yes, if you don't already have a copy of this,
it might be good to go and grab it now,
print it off, and follow right along.
Step one of the journey from Scrum to Scrumban
is visualize the work, and I don't think I got
any comments directly on that subject,
so let's move swiftly on to step two,
which is impose WIP limits.
Again, surprisingly, I think most people
are comfortable with the idea of limiting WIP.
Ruby Rose Evenstar had this question,
one question about WIP limits.
What do you do with tickets that are blocked
from an external team you don't have control over?
So if the item really is blocked and can't be moved along,
then I think we have no choice to remove it from this area.
One or two people suggested having a dedicated column
for blocked items, and that might be the easiest
if you're using some kind of electronic board like Jira.
What I like to do is maintain the state
or the position moving left to right on the board,
even for items that are blocked.
So I prefer blocked items to be in separate swim lane.
Either way, the column or the process
that we're interested in, space is created inside
and the pull system can operate once again.
Moving on again, the third step
on the road from Scrum to Scrumban
was to add more columns.
Now I've advocated for a long time
for multiple columns on a board,
basically as many as the team think is appropriate
is the number that I think should be on the board.
But there's a comment here from Vincent Lord
that raises a cautionary note
that I confess I haven't really thought of before.
There's a real danger in having multiple teams
within a single team each having their own
requirements before they will work on something.
So I think the message is that the additional columns
can in some way build walls between sub teams
that appear within the team.
This feels like it's something we should really
dive into in a separate episode.
Wow, the sun's come out.
I wasn't really expecting that.
Let's move along and find a shadier nook.
(water rushing)
Okay, I found myself a shady nook
just beside the top lock and well locks,
and I think we've got to the third step,
sorry, the fourth step,
which was to stop early binding and start ordering.
Plenty of things to talk about in this step.
TheEmperor80 had this to say.
What is a developer supposed to do
when pulling a ticket from DEV
that he or she is just not able to do
because of lack of skill?
Should the developer work on the second item?
This is a question I've asked myself
on many an occasion, because I am a developer,
it quite often happens that I go
to pick an item from the top of the pile
and find out it's one that I know
will take me an absolute age to do,
so I'm very aware of the temptation
to pick from the second list.
So I suppose the purest answer is
you should take the first one.
The pragmatic answer is that you might
agree with the team that you might pick the second one.
Perhaps even the third.
Actually, we had another really good answer
to the question from Pinecone Defense,
one that I like a lot.
We had this exact issue in our recent
move from Scrum to Kanban.
We did a balance of the two approaches,
prioritizing the former if it involved
very little training and support.
And this is the bit I really like.
We found team members were able to take
on a much broader range of tasks relatively quickly
with less skill development and cross training than before.
Mm.
Ah, wasn't expecting the sun,
but I wasn't expecting rain either.
Um, cue some nice B-roll of water falling on a canal.
All dried off and back under cover.
Those outside broadcasts are trickier than they look.
I didn't even get a chance to show you
one of my favorite bits on the canal, The Three Bridges.
Road bridge above, railway line beneath,
aqueduct right through the middle,
and designed by none other than Isambard Kingdom Brunel.
It was his very last project.
He died just a few weeks after its completion.
But I digress.
Back to the action with step five, stop estimating.
I'm sure it won't surprise you to learn
that this section generated most of the column inches,
and Santosh spoke for many of you
when he asked these four questions.
How do you time-box your sprint
when you don't do spring planning in Scrumban?
You don't.
Estimation, what about that?
It's complicated.
Is there a concept of velocity in Scrumban?
How would you calculate it?
Velocity is usually expressed as story points per sprint,
and since in Scrumban you don't have either of those things
how do you track your burn downs?
You don't.
On a slightly more serious note,
we don't estimate just for the sake of it.
There has to be some kind of tangible output.
And yes of course there is a direct output,
but there's also an indirect output
that many of you were concerned about losing.
But let's start with the obvious one,
the direct result of estimating.
Adriano had this to say.
How can I have predictability towards stakeholders
as there is no clear sprint planning?
And this, from Aidan.
I agree that it would be difficult
to remove estimating without finding
an alternative to forecasting.
So if you don't have estimates
and you still have predictability,
a couple of you provided a clue.
Chris said regarding velocity,
you can argue that the number of work items
completed per week, month, quarter is a team's velocity.
Though traditionally measured in story points,
it doesn't have to be.
Very interesting.
Velocity can still be determined
as it is based on the speed in which the work is done
and doesn't necessarily need to be base lined by estimation.
You can get predictability without estimating,
and you do so by counting stories
rather than by counting story points.
Clearly there's more to it than that
and it deserves an episode all on its own,
which we will get to in the very near future.
Should you be watching this video
in the very near future,
then there may be a link to it up here.
But if you've been quick off the mark, there won't be.
Sorry about that.
Before we move on, let's talk about the side benefits
of estimates, or rather the side benefits
of the process of estimating.
Wouter had this to say.
Personally, I've always though of estimating
as an indictor of whether you need
more detail in your stories or not.
If stories are given high estimates,
chances are they are not clear enough
or can be split into multiple stories.
And Paul had this to say.
The bit where I do have a problem
is the stopping of estimating,
and it's not necessarily the estimating bit
that I disagree with the most.
Grooming, as we know its called in Scrum,
I prefer to call it refining and estimating,
is the most underrated ceremony of all,
but it's actually critical in the team's arsenal
of dealing with the complexity and uncertainty,
and therefore risk, than they face when it comes
to actually delivering the stories they commit to.
Wouter and Paul, I'm completely with you.
I've long thought that the least important outcome
from a planning poker session is actually
the number of story points to assign to a ticket.
Far more important is the discussion that precedes it.
The message, I think, is clear.
If we're going to be transitioning from Scrum to Scrumban,
we must make sure to not throw
out the baby with the bathwater.
We need to retain that all-important discussion.
And on the subject of baby and bathwater,
Marion had a concern.
Does Lean recognize value added
with Review and Retrospective?
As I hope I said in the previous episode,
a team would be wise to retain the ritual
that is the rRtrospective.
And Pablo echoed the thought.
I also agree with the comments
about retaining Retrospectives.
We've made it at long last to the final step.
It seems a long time since I was caught in the rain.
You know, this outside broadcast was
originally planned to be done here.
It's a place where you can rely on the weather
a bit more than here in old Blighty.
Step six, trigger planning.
In case we were in any doubt at all, Chris has the news.
A just-in-time sprint planning event
defeats the point of the Scrum time box.
I'm not arguing that it's not valuable,
I'm just saying that when you depart
from fixed length time box, sprint, you've broken Scrum.
Guilty as charged.
We are well and truly into Scrumban
and we've left Scrum behind.
And Wilson liked the look of it.
Great video, thanks for sharing.
The triggered planning is definitely a game changer.
If you're watching this video
the chances are you are doing Scrum,
but I wondered if any of you were doing Scrumban.
I was pleasantly surprised.
This is essentially what we're doing in my team,
but without knowing that someone had already
attempted to describe it and codify it.
How about that?
I'm already doing some kind of Scrumban with my team.
I started by not doing sprints anymore
and estimating using ticket count.
We became quite demanding about ticket splitting.
I try to break down more complex stories
into many smaller ones and this way,
we kept some kind of predictability.
Yet another clue about how to use
story counting for predictability.
Michel went on to say that after migrating to this approach,
I missed planning poker and estimation.
When we, the team, estimate some tasks,
we are encouraged to think deeper about the problem.
Yes, exactly.
That's why it's important to maintain that discussion step.
And this one's from Pinecone Defense.
This very much mirrors what we did with our teams.
And here's a couple of sentences that I really like.
In the first two weeks, teams tried
to keep early binding and the sprint schedule.
By week three they gave up,
started focusing on unblocking work,
triggered by the new WIP limit, and started shoving
work out the door like there's no tomorrow.
We're five week into a fairly Scrumbanish Kanban
and no one wants go back.
How's that for a success story?
And this one from Chan Flo.
I moved my two development teams
to Scrumban almost a year ago.
The team loved the more structured way
of dealing with priorities without breaking
a spring commitment and swarming on bottlenecks.
The feature manager loved it because he knew
that newly discovered information
would be worked quickly since we let him
have input on the prioritization of the backlog.
And listen to this.
Although the rest of the project,
about 13 teams, are still working Scrum,
I've partnered with some of the other Scrum Masters
to understand how Scrumban can work for their teams.
Fantastic.
And that's a fabulous note, I think, to end on today.
Thank you very much indeed for all of your comments.
My apologies if I didn't manage to work yours in.
Question of the day, having watched this episode
are you more or less likely
to give Scrumban a try in your team?
Let me know in the comments below.
And it only remains for me
to thank you very much for watching.
I look forward to seeing you next time.
Cheers for now.