Monthly Archives: December 2011

How we measure progress defines how we work

We want to be fast and reliable in our work, so we want to measure our progress. The question is what is the right scope for the measurement? When do we start the clock and when do we stop it? This is a fundamental question that in practice defines the way we work.

Let’s say the phases of our value chain — be they implicit or explicit — are like the picture on the right. To start with a narrow example, if we choose to measure our progress from the start of coding to the end of coding, that drives us towards very careful up-front planning and design of the system. We will want to be sure that when we start the coding, we will have as thorough understanding of the system as possible. We will be using something akin to waterfall as our development method.

On the other hand, if we measure from the start of the idea to the end of coding, we will end up with something like cowboy coding. We want to do as little design as possible, because that takes time from coding, which is the crucial part. We don’t need to care about testing, because that is out of our measurement. (Cowboy coders, almost by definition, don’t measure anything explicitly. But the argument goes in the other direction: if we measure things this way, we end up with something akin to cowboy coding.)

What measure leads you to Scrum? The methodology itself does not mandate where the boundaries are, but the way I have seen most Scrum teams implement it, is from the start of UI design or technical design to the end of testing or deployment. In theory, these kinds of Scrum teams strive to deliver working software but don’t care if it actually produces value or not. Product owner should take care of that part, although it is a bit more complicated than that in practice.

The things we measure set in practice the boundaries of our business. Even though we may focus on a certain part of the process—e.g. from IX design to deployment—if we choose to measure our success more broadly—e.g. from end to end—we will become invested in the result of the broad interpretation. This entails that we will in one way or another want to help our customers and suppliers in doing their part of the work.

So what is the right measure? There are two conflicting forces pushing us to different directions. What the business ultimately wants is quick creation of business value. But on the other hand, work is easier to organize and buy when it is modularized with clean interfaces. For example, if a company modularizes interaction design well enough, so that its input and output are clearly defined and of good quality, then it is easy to buy IX design from that company, and the measure of progress from the start of interaction design to the end of interaction design makes sense.

In my experience, success is often measured too narrowly, leading to many of the problems in our industry. The earlier in the process you start the clock the more adaptative the process will be. Likewise the later in the process you stop the clock the more relevant the feedback. Development of complicated software is not good enough yet to use modularized approach in its value chain. We need a more integrated approach.

Looking in the eyes

When I was in the seventh grade, I used to walk past this dog every day on my way to school. It was a small dog – some kind of a poodle, I suppose – but it guarded a big house and took its job seriously. Every morning and every afternoon when I walked past the house, it barked furiously. I was annoyed so I planned all kinds of schemes how to get rid of the wretched creature. In the end I chose to execute the simplest one of them, which was to stare it to death.

So every day, I would stare at the dog right in the eyes until I had passed the house. At first the dog barked at me like it had before. But in the matter of weeks its barks turned softer and then muted completely. My staring didn’t result in the dog’s death but it did the next best thing: the dog recognized me and didn’t bark at me anymore.

It was autumn then, and for the winter the owner kept the dog inside. At the start of the spring the dog came back to its guarding routine, but it didn’t bark at me anymore. I walked past that house to school for the next two years. Only once I talked to the owner of the dog. She said: “I wonder why the dog barks at everyone else and not you?”

That’s actually a good question. Obviously it was because of my looking the dog in the eyes, but what was the ultimate reason? Had I established that I was the master and it the servant? Or did it consider me someone familiar and of equal status, its pal?

I’ve come to believe the latter. When we look someone in the eyes, we acknowledge that they exist, are worthy looking at, and that we are not afraid. It is a good start.

Answer the Right Questions with Prototypes

Prototypes validate ideas. Rather than basing plans on guesses, you create something concrete and put it to the test. But what kind of a test? That depends on whether you are aiming for a sustaining or a disruptive innovation. The distinction helps us ask the right questions and build the right prototype. As a consequence we eliminate waste and create an effective innovation process.

I posted to Leonidas blog today: Answer the Right Questions with Prototypes.