Software Test & Performance Collaborative

/Performance/ Improvement, not “Process” Improvement

By Matthew Heusser on November 25, 2009 | 5 comments.

Would you be willing to go on a little experiment with me?

Pretend that you are an executive at an American Company in 1965. The story of Henry Ford’s Assembly Line, and the billions he made from it, have moved into the stuff of legend. “Everyone” knows that one way to make big money is to create a great product – one Americans wonder how they used to live without – that is disposable. Then, you break building the product into component tasks, get a cheap labor group of specialists to work on each task, and sell it to every single household, over and over again.

Enter Ray Kroc, businessman extrodinare. He notices that the McDonald’s Brothers have a better product – a burger – that people are willing to stand in lines for. Kroc buys the franchise, standardizes and defines every step in the entire operation, then takes it national. Then global. During his lifetime Kroc amassed a fortune of five hundred million dollars. Along the way, he acquires a major league baseball team.

What lesson do take from the McDonald’s story? Is it that the way to success it through standardization?

For many corporations, the lesson they took was exactly that.

I think they got it wrong.

You see, the McDonald’s Brothers had a great process to start with. They had a burger that was better than everyone else. So if you’ve got it all figured out allready – if you team has a “secret sauce” – it might make sense to do things in the same way. If you don’t; if the process is inefficient and slow and involves a lot of bottlenecks, then standardizing the process is going to prevent individual improvement.

But there’s more.

Part of Kroc’s goal was to produce a hamburger that was the same every time. His process was actually identical. In software development and testing, every project is different. We can try to talk in a language of standardization – “gathering requirements” or “requirements inspection” – but the actual requirements will be different every time.

Oh yes, there are rare cases where we really are doing very similar things; report generation, or just-slightly-different-each-time website development – but both of those are begging for some really strong 22-year-old codejockey to come along and write a code generator to make the problem disappear.

So in many cases in the corporate world, I’m suggesting we don’t need process improvement – at least, not the institutionalized, defined, audited kind. I suspect we need performance improvement. Let me give an example.

This summer, our family took a day off and went up to Michigan’s Adventure in Muskegon. The kids had a blast on the roller coasters and the waterpark, and I had one day to actually not think about technology or process. Until lunch, that is.

So it’s lunchtime, and I’m waiting in the line at the snack shack. A long line. And a long wait. They guy behind me starts to complain “You know, we come here every year. The kids love the park, but I spend the day in line. They need to do something about these waits for food. They really do. Maybe have one teen-ager work the cash register, another cook, and a third assemble the food. I don’t know. But they need some kind of process improvement to improve speed, that’s for sure.”

Man. Try as you might, you just can’t get away from it, can you?

So I start to talk to this gentleman, and I realize something about the teenagers behind the glass. They just aren’t moving very fast. I remember being a teenager myself, and the kind of jobs that paid the same minimum wage if I hustled or If sand-bagged.

A bigger assembly line with stations wouldn’t help the process. The food was pre-cooked, all the workers had to do was assemble it. What the workers had to was move faster.

There are lots of ways to accomplish that. One might be the McDonalds route; if the park was willing to invest the time and effort in hiring real process engineers. It’s easy to spread the cost of process engineers over 2,000 restaurants; over a half-dozen non-standard-sized snack shacks in a west Michigan Amusement Park, not so much.

Another would be simply to count the number of meals served in an hour, or the average wait time of the line. Then hand our raises and bonuses. You can do that with the register itself or with each manager simply using a stopwatch during lunch breaks. Or you could calculate the profitability of each shack and let the workers figure out the best way to make it more profitable. Oh, you might have to watch out to make sure the now-motivated workers aren’t serving undercooked food in order to make the numbers, but if you’re going to organize a group with managers, well, that’s part of the job.

Now, back in the world of technology, things are a little big harder. First of all, it might be safe to say that a dollar is a dollar or a minute wait is a minute wait, so those metrics are valid – but line of code are not creatd equal, and it is relatively easy to abuse them, or ‘test cases’ or most other engineering ‘metrics.’ Which makes management by output a whole lot harder then conformance to process.

So it’s harder. I don’t think that means we should abandon it.

In fact, quite the opposite. I think it means we need to work to understand the dynamics at play. We may not be able to turn the performance of a team into a metric, but I think we can manage for output. And management for performance is one of the things I am excited about right now.

I suspect that an outsider might see that kind of high-performance testing, snot and laugh that the work is the ‘very edge of chaos.’ Fancy that.

UPDATE: I’ve been reflecting on this, and I really have a strong emotional reaction to the standardized process thing. I dislike it. When I’ve worked with ‘process engineers’ who think in this command and control style, that want to separate the worker from the work … well, the reality is, they would not enjoy working in the very system they created. I expect they would hate it. Yes, they have ready-made excuses, like there are different kinds of people, some like to be told what to do, and fit well into the system, and others are more intelligent and independent and could not work in such a system, etc, and so on.

I don’t buy it. That is snobbery of the highest order; it’s nothing less than a new kind of class warfare, that replaces peasants with white-collar workers and nobility with executives.

It is also not treating people the way we would like to be treated. I wonder, as we Americans are about to embark on a two-day binge fest of Turkey and shopping, er, um, I mean, a two-day Holiday to thank our Creator for all the blessings he has bestowed upon us. I wonder if we should also stop to question our cultural assumptions about ‘process improvement’, and if they are an example of the Golden Rule … or not.

Update 2: At least one person read this as “Matt approves management by metrics.” Well, wait, that is a very complex subject. Please consider the post above in light of my other writing on metrics – this article comes to mind. How to do the performance improvement work in a knowledge-worker world, I suspect, deserves it’s own set of blog posts.

Keep it tuned here. More to come.