10. Conclusion

“It is true that we have really in Flatland a Third unrecognized Dimension called ‘height,’ just as it also is true that you have really in Spaceland a Fourth unrecognized Dimension, called by no name at present, but which I will call ‘extra-height.’ But we can no more take cognizance of our ‘height’ than you can of your ‘extra-height.’ Even I—who have been in Spaceland, and have had the privilege of understanding for twenty-four hours the meaning of ‘height’—even I cannot now comprehend it, nor realize it by the sense of sight or by any process of reason; I can but apprehend it by faith.”

—Edwin Abbott, Flatland: A Romance of Many Dimensions¹

Figure 10.1 These two figures are both two-dimensional views of the same octahedron. If you cover the right-hand image, however, you will probably see the left image as a square with two diagonals. Only when you see the two together do the diagonals appear as edges of a three-dimensional shape.

In this book, I’ve described how a team of peers can apply a value-up approach and apply Visual Studio Team System (VSTS) to improve their capacity for creating customer value through their work. I’ve done this from the various qualitative viewpoints of the disciplines and from the quantitative metrics that get captured in the process. Both are multidimensional approaches.

I have frequently used the two instances of MSF (Microsoft Solutions Framework) as references because they are the process guidance that ships with VSTS and because they are the processes that, as far as I know, most closely represent value-up thinking. I have tried, wherever possible, to give credit to the intellectual sources of the ideas.

Expected Criticisms

At the time I am writing this book, Team System has just shipped. I’ve made a number of claims, and I expect a fair amount of criticism for them, so let me plead guilty to five major indictments right now:

1. This book is not Agile enough. In particular, I expect to be dinged for not following the Agile Manifesto tenets closely enough.² For example, I write more about processes and tools than individuals and interactions, and more about change in the context of a plan than responding to change without a plan. Actually, I think that a huge strength of the Agile community has been the effervescent tooling that has emerged for unit testing and change management. And processes such as XP have demonstrated the great value of discipline. With VSTS, we are trying to make tools and practices like these easier and more approachable to a much wider community than they have been before.

2. This book is not prescriptive enough. A value-up tenet is the importance of situationally specific strategies. I’ve tried to focus on recognizing and understanding the situation, trusting that if the whole team can see the same data, the team can work on the prescriptions. There is certainly a book waiting to be written on situationally specific management patterns.

3. There is not enough depth for each of the disciplines. I’ve written this as the introductory book to a series. A book targeted specifically to development practices with VSTS will be available shortly after this one is released. I hope many authors will join me over the next few years. And I realize that I stopped short on the vital topics of user experience, release management, and operations.

4. I don’t have enough data to support my claims. Not yet. Microsoft is certainly going to accumulate case studies around VSTS, and you will be able to find them on http://msdn.microsoft.com/teamsystem. I hope that they reveal enough insight into the processes used and enough data to illustrate the values that I discuss here.

5. The sources are too random. Software engineering is not new and does not occur independently of its business context. I’ve tried hard to bring in the threads of both the valuable work of the community and the business environment of the twenty-first century. I often find software debates to be very black-and-white, but I see the situation as much more multi-colored. I hope that you too may come to prefer the color and gradation over the absolute black or white projection.

I also might be accused of making too much of a product sales pitch. I have tried to argue the design ideas that led to the creation of VSTS with as many examples as I could fit. I’ve tried wherever possible to distinguish the ideas from the implementation, but I have used the product to illustrate them. I hope you found the presentation balanced.

Value-Up, Again

The core idea of this book is that a new paradigm is emerging for software development, which I’ve called the value-up approach. The early intellectual roots of value-up lie in the work of Deming, Weinberg, and Goldratt, and the Agile, Lean Manufacturing, and Theory of Constraints communities. The central tenet of value-up is to maximize the flow of customer value.

Consistent with these roots, value-up espouses these ideas:

1. Embrace change. Invest in just enough planning and design to understand risk and to manage the next small increment.

2. Measure only those deliverables that the customer values. View all interim measures skeptically.

3. Understand quality as value to the customer. The customer’s perception may change, so keep options open and plan for frequent delivery.

4. Accept variance as a part of all processes. Distinguish special-cause from common-cause variance. Treat them differently.

5. Use intermediate work products only insofar as they improve the flow of value. Use them to reduce uncertainty and variation, not measure progress.

6. Increase capacity by attacking bottlenecks in the flow of value. Tune resources and time only after removing the bottlenecks.

7. Be transparent and trusting. Assume that the team takes pride in its workmanship and wants it to be seen.

Figure 10.2 The principles and mindsets of MSF reflect the value-up paradigm.

If you consider this list to be motherhood and apple pie, then I’ve achieved half my purpose.

The second half of my purpose is to convince you that tooling can make a large, positive difference. VSTS is not the first product to address the software lifecycle, and it won’t be the last. However, I believe that it is the first that attempts to offer a comprehensive value-up approach for the whole team in a simple, productive, integrated, and extensible manner. Free trials of the product are available, and you can judge its suitability for yourself. Of course, VSTS is a new product, and there will be a large number of requests to take it further. I welcome the dialogue.

VSTS, by instrumenting the software process, enables trustworthy transparency. The metrics warehouse gives the whole team a common view of the facts and a common base of historical performance. This common view changes the discussion from “Whose numbers are right?” to “What should we do next?”

I hope that VSTS spawns similar innovations across the industry. Improving the capacity of IT and the software industry is one of the great economic challenges and opportunities of the coming decades. I believe that this requires both a value-up approach and the tooling to support it.

Endnotes