What I'm Talking About - Yes, I'm Talking About Changing

· October 24, 2013

I’ve done numerous presentations on Lean and Agile, and there are a couple of things that I often feel I don’t succeed in implanting in people’s minds. I thought I’d write them down so that I can direct people back here, and also remind myself when I forget.

Quite shortly, these things can be summed up with these two short answers:

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 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 are the individual workers’ timings and the result for the First coin to arrive and the Total time.

Results

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 seen 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 a 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 who is grumpy and skeptical of the whole scene (in fact, once I had a person who didn’t accept the outcome of the game he just played…). The comment often sounds something like:

This all sounds nice in theory, but you know here, where 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 are third-party suppliers. Also, we have instructions that tell us to…

Oh no

I now realize that I’ve lost them and missed the most important point; that is what we want to change! Lean and Agile are not problem solvers - they’re improvement opportunities finders.

Focusing on flow and limiting work in process will show you where you can improve your flow, where it slows down, 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 changed that question to put focus on the work rather than the workers. We are not selling keystrokes per 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:

Waiting

And, after we played the game, talked about Lean, and everyone had agreed that we were here to complete work items, not just be 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 be 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 were 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 you’re 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. Toyota’s vision is not to sell X million cars. It’s to have a smooth flow in their process.

That means that Toyota has 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 hypotheses 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.

Build Measure Learn

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 have 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 kinds of changes with a long feedback loop is both cumbersome, hard, and risky, as you will not see the effect of your suggested change (experiment) for 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 find 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.

Twitter, Facebook