From Dynamics of Software Development, Microsoft Press, 1995, 2006
Rule 40 Every little milestone has a story all its own.
Each milestone needs a story…The spirit of a milestone can be expressed in the story of the milestone. The story is a description of what is meant to be achieved in the milestone. All arguments can be resolved (theoretically) by reference to the milestone story. The story also articulates the goal. The reason I don’t call it the milestone goal is that it must have the dynamics and the moral, the message, of a story. It must ultimately encapsulate the meaning of the milestone. Most humans don’t find it motivating or rewarding to achieve a goal as purely abstract as something called M1, an immaterial list of deliverables we have convinced ourselves represents progress (something we could be totally wrong about—remember, this is software). A list just won’t engage the emotions, the focus, and the intensity required to deliver great software. People will make sacrifices to achieve something meaningful. They will invest their souls and their energies in visible, concrete results.
I have found several milestone stories useful in the context of Visual C++. In a typical M1 milestone, we usually aim to achieve a capability we call “dogfooding.” Dogfooding is using the product under development to further your development effort. The idea stems from the old marketing saw, popularized at Microsoft by Steve Ballmer, that dogfood manufacturers should “eat their own dogfood.” For a development tool like Visual C++, this concept is particularly important since Visual C++ is created with Visual C++. For our team to achieve 100 percent dogfooding means that our new version must be more productive than the old version, even given the new version’s incompleteness and bugginess. We will not generally enforce dogfooding: managers will not run around coercing people to use the current product version. However, the entire team is aware that dogfooding is an important sign of progress, that if we can get to a dogfood status for all components, everything will go better. By constantly using the product, we’ll find more bugs and deficiencies, gain more productivities, and realize more design efficiencies.
Another theme (and a most telling element) in our milestone story–making is when we are willing to give what to whom. We are protective of our reputation, and giving out our new versions is something we do selectively. And giving things out at the wrong times can substantially increase the workload of the team. A milestone might thus be defined by when you give your product to “early customers.”
So the story for our M1 milestone might be something like, “All components will be dogfooded by the majority of the team, and we will release the build tools to friendly internal Microsoft sites.” This would naturally be shortened to “dogfooding and internal customers.” A story for a later milestone—say, the third—might be “all features complete, visual freeze [no changes to the user interface], deliveries to a handful of friendly external sites.”
The key points about milestone stories are
- The story encodes the spirit of the milestone.
- Success is judged by whether the milestone story has been fulfilled.
- The team members understand and consent to the milestone story before they launch the milestone effort.
There are no comments for this post.
There are no comments on this entry.
There are no trackbacks on this entry.