- Previously, I got a coffee cup
pushed in my face.
Today, we'll uncover four Kanban principles
and discover how they can help you
in your agile development team,
whether you're doing Kanban or,
and this might surprise you, Scrum.
Hi, this is Gary, welcome to Development That Pays
and let's get straight to the action.
Things started so well, so simply.
A lone barista, bestriding his humble coffee shop
like a colossus.
Doing everything in his defined process.
(smooth jazz music)
Taking the order, making the coffee,
and delivering it back to the customer.
Adding a dedicated order taker into the the brew,
didn't seem like such a big deal,
but with specialization came the need for orchestration.
Key to that was the buffer.
In the coffee shop, this area of counter.
On the board it was this column.
The gray color a reminder, that no value is added here.
Waiting is one of several forms of waste,
but it is a price we pay willingly for switching the system
from push to pull.
Let's step out of the coffee shop for now,
and make our board a little more development oriented.
How about a defined process of develop, test, deploy.
Now if I was working alone,
this board would work as it stands.
But if I'm working together with dedicated developers,
dedicated QA/testers and even dedicated deployment personnel
then we're gonna have to add in
a little bit of orchestration to handle the handoffs
between our specialists.
And as you know by now, that means buffer columns.
And yet again, it's with a heavy heart,
that I'm coloring them gray, no value added here.
In this team, when deployment is done, the task is done,
which is why I haven't split the deploy column.
Some thought went into this you know?
Let's give this team some work to do.
Into development and as with most teams,
development is the stage that takes
the lion's share of the time.
So you might wanna talk among yourselves
for just a moment or two.
Oh, across to done and straight into test.
Test also a stage that cannot be rushed,
but I'm sure, yes we are, we're done already
and then straight across to deploy.
Deploy I think is mercifully brief.
End-to-end that was about 30 seconds.
So two items per minute.
There are six people on this team,
so I think we can do a little bit better than that.
Oh, and let's add some development
appropriate music into the mix.
Lots of things now happening in parallel.
(upbeat music)
And it looks like things are popping out
about every five seconds or so.
Around 12 per minute.
Tidy indeed, and a useful metric.
But there's a metric that's arguably far more important
and that is the time it takes for one item
to make its way all the way across the board.
Best case, as we just saw, was something like 30 seconds.
But what if our board looked like this?
(dramatic music)
Imagine how long it would take the pink card
to make its way all the way across.
Seriously, you're gonna have to imagine it,
because there's no way I'm animating that mess.
We already know the cure for this,
and that is of course our friends,
I hope they're our friends now, work-in-progress limits.
I'm gonna add a WIP limit of four for dev doing,
two for dev done, three for test doing, two for test done.
And two for deploy.
We'll be seeing this in action in just a second.
But just before we get there, I said at outset
that we'd be covering four Kanban principles today,
and of course, we've already come across two of them.
They are for the record,
number one, visualize the work.
Number two, impose WIP limits.
All right, let's see this team in action.
And again, keep an eye out for Mr. Pink.
- You're Mr. Pink.
- Things are rather gridlocked,
so he's gonna have to wait a few seconds
for some space to appear.
And there he's off.
That's before this is the stage that takes the longest,
but there's plenty of other interest across the board.
So I hope it won't feel like too long.
Almost there, and into done.
Well, bit of pause waiting for a space in test.
Into test.
(upbeat music)
Across to test done for the briefest of pauses,
before moving into deploy.
And stop the clock.
Sure, it took a good bit more than 30 seconds
for Mr. Pink to make his way all across the board.
But he got there much faster
than he would've done in this case.
That's an important point.
Work-in-progress limits, don't just limit work,
they also limit time.
The time taken for a single item of work
to make its way all the way through the system.
Why is it important, why could we work through the system
as quickly as possible?
Well think back to the coffee shop.
If we take too long about it,
the customer could change his mind.
Kinda similar thing happened in our development world,
well yes, of course it can.
Let's take way the WIP limits for a moment and go crazy
with the Post-its.
What if something comes to light that means all of these
have to be reworked?
Or what if we learn something
that makes them all irrelevant.
All the development time and money
that went into these items is now down the drain, a waste.
Clearly those work-in-progress limits are a big deal.
And before we move on, I'm gonna make a small optimization.
As both of these columns belong to the development team,
instead of having separate WIP limits of four and two,
I'm gonna impose a shared WIP limit of five.
Can't use the red lines anymore,
so I'm gonna replace them with a number at the top.
Similarly for test, in place of limits of three and two,
I'm gonna impose a shared WIP limit of four.
As I'm sure you notice, I've just reduced
the work-in-progress of the system as a whole by two,
and that should be good news.
All things being equal, items will now get across the board
from left to right that little bit quicker.
I say all things being equal because imposing WIP limits
is one of those things that is simple,
but it's not necessarily easy.
Let's throw a little bit of a spanner in the works.
Develop is at capacity.
And all of that capacity is in the gray.
The entire dev team is stuck, blocked.
Now this might indicate that it's time for us to beef up
the QA/test team.
And if this situation crops up regularly
then that probably is a good idea.
But right here, right now, we have a problem
and right here, right now, we need a solution.
So question for you, what should the dev team do?
Option one, pick up another ticket.
Option two, do nothing.
Option three, do something else.
The WIP limit rules out option one
and that's entirely by design.
Turns out that option two, do nothing
is a much better option.
And if you remember when we were back in,
yes, that's right in the coffee shop,
we talked about Doctor Who here beginning to stall
when those cups started to pile up.
It was better for the system as a whole
for him to fiddle with his sonic screwdriver
rather than taking more orders.
What about option three?
Is there anything that Doctor Who could've done?
Something more productive.
Well, many of you, I saw in the comments,
knew exactly what he should've done,
he should've jumped in the TARDIS gone back in time.
No, let's keep things serious.
No, he should've got on and made a cup of coffee.
Does he have to be as fast at making coffee
as our specialist Mr. Barista?
No, not at all.
Of course, he's still gonna be expected
to be able to produce a quality brew.
We've talked a lot about specialization
and in turn, about specialists.
Now we see the benefit of those specialists
having some cross-functional skills.
Being able to jump in at various points through the process
to help out as required.
Jumping back to our board, I hope you can see that the best
move for the dev team is to do a spot of testing.
If they can help to get just one of these items
in test across to done.
Hopefully then to be picked up by deploy,
then test now has capacity to pull another item
in from dev done.
And when it does so,
dev is at liberty to pull in another ticket from to do.
And just like that we tripped over another Kanban principle.
A principle that we should focus not on the dev columns,
not on the test columns, not on any individual column at all
but to focus on the system as a whole
and especially on keeping that system moving,
in other words, a focus on the flow.
What's next for this team?
Well, that's up to the members
of the team to discover over time.
They might want to further reduce work-in-progress.
They might find reasons to do more specialization.
Or they might decide that a particular specialization
no longer serves them, no longer pays them back
for the additional work-in-progress that it requires.
There are many other things that they might do
and I'm sure you can think of some of them,
and if so, please let me know in the comments below.
Whatever they choose to do, they are on a journey,
a journey that never really ends.
A journey of continuous improvement.
And that's a fourth and final Kanban principle,
continuous improvement, also known as Kaizen.
I have one more nugget to share with you,
but first I'd like to thank my co-stars
in this three parter.
Mr. Barista, Doctor Who and last but by no means least,
my dear uncle Robert.
Yes, that's right, Robert is my mother's brother,
and if you saw that gag coming a mile off,
then you should probably subscribe to this channel
and ring the bell, so you never miss a thing.
Since we first walked into the coffee shop,
two episodes ago, there'd been no shortage of Kanbans.
Post-its, coffee cups,
even, somewhat controversially, people.
And long the way, we've also uncovered
four Kanban principles.
Agile framework wise, we now have a board
that would serve a team doing Kanban,
it would serve them well.
At least the team that we've been talking about today.
And it would serve them well, because its design arose
from the application of those Kanban principles.
Which leads us to a really important point.
If you're currently doing Kanban
and are not getting the results that you'd hoped for,
chances are that you're suffering from a lack
of those Kanban principles.
Doing Kanban is no guarantee of the application
of those principles,
and it's the principles that make it work.
Now this is where things get really interesting,
if you are currently doing Scrum,
and are not getting the results that you'd hope for,
then I have excellent news.
You may also benefit from the application
of those Kanban principles.
It's true, there's nothing in the Scrum guide
that says that you can't visualize the work.
That you can't limit work-in-progress.
That you cannot focus on the flow.
And there's certainly nothing to say
that you cannot continuously improve.
If this idea of mixing Kanban principles into Scrum
sounds intriguing, then you may be even more intrigued
to learn that there is a step-by-step process
for doing exactly that.
And I'm gonna be talking about it in the very next episode.
If you're watching this in the future,
or have easy access to a TARDIS,
then it's this video right here.