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.