I have done numerous presentations on Lean and Agile and there’s a couple of things that I often feel that I don’t succeed in implanting in peoples minds. I thought I’d write it down so that I can direct people back here, and also to remind myself when I forget.
Quite shortly these things can be summed up with these two short answers:
Yes - I’m talking about changing the way we work (this post)
This post is about changing.
When I introduce people to Lean I often play a little game with
them. Pass the pennies or
The Dot Game are my two current favorites.
We might have end up with a result table like the one to the right. This
is a result of running Pass the pennies. Each column represents the
number of coins to pass per batch (or
Work In Process if you want). The rows is the
individual workers timings and the result for the First coin to arrive
and the Total time.
Note the big difference for the 20-coin-batch result and the
1-coin-batch result. Also note what happens with the individual workers
timings.
I then talk about the Lean principles based on what we've just saw in
the game. My conclusion can sound something like this:
> As you can see from the results we would benefit from doing fewer
> items at the time and instead make sure that each item is completed
> before continuing on to the next
Around this point I often get interrupted. Often from someone way in the
back that is grumpy and skeptical to the whole scene (in fact; once I
have had a person that didn't accept the outcome of the game he just
played...). The comment often sound something like:
> This all sound nice in theory but you know here, we I live, let's call
> it reality for the sake of argument, that stuff doesn't work. We need
> to wait for others, or there's third party suppliers. Also we have
> instructions that tells us to ...
I now realize that I've lost them, and missed the most important point;
that is what we want to change! Lean and agile is not problem
**solvers** - it's ~~problem~~ improvement opportunities **finders**.
Focusing on flow and limit work in process will show you where you can
improve your flow, where it slows downs or is uneven. And it will do it
fast.
Now here it comes; *Lean will not improve your process for you*. Neither
will Scrum. Not even Kanban can help you out improving your flow.
You have to do something about it. If you don't - you will not
improve.
What I can tell you is that keeping your eye on the true north for Lean
(better flow) and doing small changes often, rather than big seldom, you
will get help to see if you're improving or not.
Oh yeah - *improving* is of course from the point-of-view of Lean. Lean
is aiming to have better flow, moving work faster from idea to
production. If that is not where you are striving you will probably see
the problems and then take countermeasures that might not help (Thanks
@drunkcod
for that insight).
For example; asking if everyone has something to do, in your daily
standup, is not promoting better flow. In one team that I coached we change that question
to put focus on the work rather than the workers. We are not selling
keystrokes / minute, we're selling features that are making a business
impact in production. Right?
Speaking of examples - here are two examples that I often come back to
when I talk about this.
### Example 1 - Waiting
I once visited a team that had a really bad reputation for being slow.
It was a support team and they "took forever to get something done". The
first thing we did was to visualize their process and added their
current work item into the different stages of their workflow.
It looked something like this:
And, after we played the game, talked about Lean and everyone had agree
on that we were here to complete work items not being busy - the comment
of course came:
> But that won't work for us, this is the way we do things around here.
> There's a lot of built in waiting in our process.
I'm talking about changing that. I'm talking about removing those
waiting states. I'm talking about doing our work in a different way to
increase the flow. I'm talking about letting flow being the primary
thing that we strive for and change our process/ways of working to
support that decision.
But Lean thinking only showed us that this was a problem, by visualizing
your work (resulting in the customary "Oh My God! Is it that much?!")
and asking what we can do to improve the flow of the work, instead of
focusing on keeping the workers busy. The workers was plenty busy,
believe you me.
In this case I simply asked: What would improve the flow of the work?
And their answer was (of course): less waiting, maybe?
Me: What can we do to wait less?
... and on we went.
Sadly I have no solutions for you here. Your knowledge about your
process is much better than mine, of course. But I can tell you this: if
we do nothing we will still have these problems.
(And maybe that is ok...). Focusing on flow and
limiting work in process will help us push our improvements towards a
better flow.
How about going over to the guy that you are waiting for when your done
and ask how you two together can take this to the next step? Or tell him
that you are now finished with "Do stuff 1" and that he can call you
back when you can continue with "Do stuff 2"? Maybe you could do what's
done in "Wait for others" yourself for certain work items?
### Example 2 - Toyota
One of the things that really fascinates me about Toyota is their vision
(something like "future of mobility, enriching lives around the world")
and that they aim to accomplish that through focusing on
one-piece-continuous-flow. That is just mind blowing to me. Toyotas
vision is **not** to sell X million cars. It's to have a smooth flow in
their process.
That means that Toyota have a very clear and distinctive true north:
one-piece-continuous-flow. They are not there yet and probably never
will be, but in the striving towards that ideal state they allow
themselves to innovate and evolve their process in small increments.
In fact, they can (and are in fact doing this too), pose hypothesis of
how changing their process would lead them closer to their goal. In
doing so they can allow themselves to experiment, in very small
increments, and see if their hypothesis was confirmed or disproved. You
can read more about this in the excellent book
Toyota Kata.
| |
|:------------------------------------------------------------------------------------------------------------:|
| 
|
| From <http://lean.st/> |
If you think that this sounds familiar you would be right; it's how the
scientific method is lined out and hence how all
major landmarks in science has been made. It's also the basis of the
currently very popular
Lean Startup
movement.
The current way of working is only best so far, for a company with a
mindset like Toyota. Changing the process is the normality, that's how
we work. A failed experiment is just a learning that disproved our
hypothesis - that's a good thing. We learned and can improve from that.
Doing these kind of changes with a long feedback loop is both
cumbersome, hard and risky, as you will not see the effect of you
suggested change (experiment) in a long time. With a short feedback
loop, which in turn pushes us towards doing tiny changes, it's much
easier and safer to experiment.
Change is the normality.
### Conclusion
Yes - I'm talking about changing the way you work today. In ways that
neither you nor I could foresee. But keeping our eye on our true north
(be it one-piece-continuous-flow or something else that you and your
organization finds important) we will improve.
I can promise you that. But we have to change. Yes - I'm talking about
changing the way we work today.
We might have end up with a result table like the one to the right. This
is a result of running Pass the pennies. Each column represents the
number of coins to pass per batch (or
Work In Process if you want). The rows is the
individual workers timings and the result for the First coin to arrive
and the Total time.
Note the big difference for the 20-coin-batch result and the
1-coin-batch result. Also note what happens with the individual workers
timings.
I then talk about the Lean principles based on what we've just saw in
the game. My conclusion can sound something like this:
> As you can see from the results we would benefit from doing fewer
> items at the time and instead make sure that each item is completed
> before continuing on to the next
Around this point I often get interrupted. Often from someone way in the
back that is grumpy and skeptical to the whole scene (in fact; once I
have had a person that didn't accept the outcome of the game he just
played...). The comment often sound something like:
> This all sound nice in theory but you know here, we I live, let's call
> it reality for the sake of argument, that stuff doesn't work. We need
> to wait for others, or there's third party suppliers. Also we have
> instructions that tells us to ...
I now realize that I've lost them, and missed the most important point;
that is what we want to change! Lean and agile is not problem
**solvers** - it's ~~problem~~ improvement opportunities **finders**.
Focusing on flow and limit work in process will show you where you can
improve your flow, where it slows downs or is uneven. And it will do it
fast.
Now here it comes; *Lean will not improve your process for you*. Neither
will Scrum. Not even Kanban can help you out improving your flow.
You have to do something about it. If you don't - you will not
improve.
What I can tell you is that keeping your eye on the true north for Lean
(better flow) and doing small changes often, rather than big seldom, you
will get help to see if you're improving or not.
Oh yeah - *improving* is of course from the point-of-view of Lean. Lean
is aiming to have better flow, moving work faster from idea to
production. If that is not where you are striving you will probably see
the problems and then take countermeasures that might not help (Thanks
@drunkcod
for that insight).
For example; asking if everyone has something to do, in your daily
standup, is not promoting better flow. In one team that I coached we change that question
to put focus on the work rather than the workers. We are not selling
keystrokes / minute, we're selling features that are making a business
impact in production. Right?
Speaking of examples - here are two examples that I often come back to
when I talk about this.
### Example 1 - Waiting
I once visited a team that had a really bad reputation for being slow.
It was a support team and they "took forever to get something done". The
first thing we did was to visualize their process and added their
current work item into the different stages of their workflow.
It looked something like this:
And, after we played the game, talked about Lean and everyone had agree
on that we were here to complete work items not being busy - the comment
of course came:
> But that won't work for us, this is the way we do things around here.
> There's a lot of built in waiting in our process.
I'm talking about changing that. I'm talking about removing those
waiting states. I'm talking about doing our work in a different way to
increase the flow. I'm talking about letting flow being the primary
thing that we strive for and change our process/ways of working to
support that decision.
But Lean thinking only showed us that this was a problem, by visualizing
your work (resulting in the customary "Oh My God! Is it that much?!")
and asking what we can do to improve the flow of the work, instead of
focusing on keeping the workers busy. The workers was plenty busy,
believe you me.
In this case I simply asked: What would improve the flow of the work?
And their answer was (of course): less waiting, maybe?
Me: What can we do to wait less?
... and on we went.
Sadly I have no solutions for you here. Your knowledge about your
process is much better than mine, of course. But I can tell you this: if
we do nothing we will still have these problems.
(And maybe that is ok...). Focusing on flow and
limiting work in process will help us push our improvements towards a
better flow.
How about going over to the guy that you are waiting for when your done
and ask how you two together can take this to the next step? Or tell him
that you are now finished with "Do stuff 1" and that he can call you
back when you can continue with "Do stuff 2"? Maybe you could do what's
done in "Wait for others" yourself for certain work items?
### Example 2 - Toyota
One of the things that really fascinates me about Toyota is their vision
(something like "future of mobility, enriching lives around the world")
and that they aim to accomplish that through focusing on
one-piece-continuous-flow. That is just mind blowing to me. Toyotas
vision is **not** to sell X million cars. It's to have a smooth flow in
their process.
That means that Toyota have a very clear and distinctive true north:
one-piece-continuous-flow. They are not there yet and probably never
will be, but in the striving towards that ideal state they allow
themselves to innovate and evolve their process in small increments.
In fact, they can (and are in fact doing this too), pose hypothesis of
how changing their process would lead them closer to their goal. In
doing so they can allow themselves to experiment, in very small
increments, and see if their hypothesis was confirmed or disproved. You
can read more about this in the excellent book
Toyota Kata.
| |
|:------------------------------------------------------------------------------------------------------------:|
| 
|
| From <http://lean.st/> |
If you think that this sounds familiar you would be right; it's how the
scientific method is lined out and hence how all
major landmarks in science has been made. It's also the basis of the
currently very popular
Lean Startup
movement.
The current way of working is only best so far, for a company with a
mindset like Toyota. Changing the process is the normality, that's how
we work. A failed experiment is just a learning that disproved our
hypothesis - that's a good thing. We learned and can improve from that.
Doing these kind of changes with a long feedback loop is both
cumbersome, hard and risky, as you will not see the effect of you
suggested change (experiment) in a long time. With a short feedback
loop, which in turn pushes us towards doing tiny changes, it's much
easier and safer to experiment.
Change is the normality.
### Conclusion
Yes - I'm talking about changing the way you work today. In ways that
neither you nor I could foresee. But keeping our eye on our true north
(be it one-piece-continuous-flow or something else that you and your
organization finds important) we will improve.
I can promise you that. But we have to change. Yes - I'm talking about
changing the way we work today.