Microsoft in 2003 to work on Visual Studio Team System (VSTS), the new product line that was just released at the end of 2005. As the group product planner, I have played chief customer advocate, a role that I have loved. I have been in the IT industry for twenty-some years, spending most of my career as a tester, project manager, analyst, and developer.

As a tester, I’ve always understood the theoretical value of advanced developer practices, such as unit testing, code coverage, static analysis, and memory and performance profiling. At the same time, I never understood how anyone had the patience to learn the obscure tools that you needed to follow the right practices.

As a project manager, I was always troubled that the only decent data we could get was about bugs. Driving a project from bug data alone is like driving a car with your eyes closed and only turning the wheel when you hit something. You really want to see the right indicators that you are on course, not just feel the bumps when you stray off it. Here, too, I always understood the value of metrics, such as code coverage and project velocity, but I never understood how anyone could realistically collect all that stuff.

As an analyst, I fell in love with modeling. I think visually, and I found graphical models compelling ways to document and communicate. But the models always got out of date as soon as it came time to implement anything. And the models just didn’t handle the key concerns of developers, testers, and operations.

In all these cases, I was frustrated by how hard it was to connect the dots for the whole team. I loved the idea in Scrum (one of the Agile processes) of a “single product backlog”—one place where you could see all the work—but the tools people could actually use would fragment the work every which way. What do these requirements have to do with those tasks, and the model elements here, and the tests over there? And where’s the source code in that mix?

From a historical perspective, I think IT turned the corner when it stopped trying to automate manual processes and instead asked the question, “With automation, how can we reengineer our core business processes?” That’s when IT started to deliver real business value.

They say the cobbler’s children go shoeless. That’s true for IT, too. While we’ve been busy automating other business processes, we’ve largely neglected our own. Nearly all tools targeted for IT professionals and teams seem to still be automating the old manual processes. Those processes required high overhead before automation, and with automation, they still have high overhead. How many times have you gone to a 1-hour project meeting where the first 90 minutes were an argument about whose numbers were right?

Now, with Visual Studio, we are seriously asking, “With automation, how can we reengineer our core IT processes? How can we remove the overhead from following good process? How can we make all these different roles individually more productive while integrating them as a high performance team?”

Neno Loje

I started my career as a software developer—first as a hobby, later as profession. At the beginning of high school, I fell in love with writing software because it enabled me to create something useful by transforming an idea into something of actual value for someone else. Later, I learned that this was generating customer value.

However, the impact and value were limited by the fact that I was just a single developer working in a small company, so I decided to focus on helping and teaching other developers. I started by delivering pure technical training, but the topics soon expanded to include process and people, because I realized that just introducing a new tool or a technology by itself does not necessarily make teams more successful.

During the past six years as an independent ALM consultant and TFS specialist, I have helped many companies set up a team environment and software development process with VS. It has been fascinating to watch how removing unnecessary, manual activities makes developers and entire projects more productive. Every team is different and has its own problems. I’ve been surprised to see how many ways exist (both in process and tools) to achieve the same goal: deliver customer value faster though great software.

When teams look back at how they worked before, without VS, they often ask themselves how they could have survived without the tools they use now. However, what had changed from the past were not only the tools, but also the way they work as a team.

Application Lifecycle Management and practices from the Agile Consensus help your team to focus on the important things. VS and TFS are a pragmatic approach to implement ALM (even for small, nondistributed teams). If you’re still not convinced, I urge you to try it out and judge for yourself.

Chapter 1: The Agile Consensus      1
The Origins of Agile     1
Agile Emerged to Handle Complexity     2
Empirical Process Models      4
A New Consensus     4
Scrum     6
An Example     12
Summary     15
End Notes     16

Chapter 2: Scrum, Agile Practices, and Visual Studio     19
Visual Studio and Process Enactment      20
Process Templates     21
Process Cycles and TFS     23
Inspect and Adapt     36
Task Boards     36
Kanban     38
Fit the Process to the Project     39
Summary     42
End Notes     43

Chapter 3: Product Ownership     45
What Is Product Ownership?     46
Scrum Product Ownership     50
Release Planning     51
Qualities of Service     63
How Many Levels of Requirements     67
Summary     70
End Notes     70

Chapter 4: Running the Sprint     73
Empirical over Defined Process Control     75
Scrum Mastery     76
Use Descriptive Rather Than Prescriptive Metrics     81
Answering Everyday Questions with Dashboards     86
Choosing and Customizing Dashboards     94
Using Microsoft Outlook to Manage the Sprint      95
Summary     96
End Notes     96

Chapter 5: Architecture     99
Architecture in the Agile Consensus      100
Exploring Existing Architectures     103
Summary     121
End Notes     123

Chapter 6: Development     125
Development in the Agile Consensus     126
The Sprint Cycle     127
Keeping the Code Base Clean     128
Detecting Programming Errors Early     135
Catching Side Effects     152
Preventing Version Skew     160
Making Work Transparent     168
Summary     169
End Notes     171

Chapter 7: Build and Lab     173
Cycle Time     174
Defining Done     175
Continuous Integration     177
Automating the Build     179
Elimination of Waste     196
Summary     201
End Notes     202

Chapter 8: Test     203
Testing in the Agile Consensus     204
Testing Product Backlog Items     207
Actionable Test Results and Bug Reports     212
Handling Bugs     218
Which Tests Should Be Automated?     219
Automating Scenario Tests     220
Load Tests, as Part of the Sprint     225
Production-Realistic Test Environments      230
Risk-Based Testing     232
Summary     235
End Notes     236

Chapter 9: Lessons Learned at Microsoft Developer Division     239
Scale     240
Business Background     241
Improvements After 2005     245
Results     254
Law of Unintended Consequences     255
What’s Next?     259
End Notes     259

Chapter 10: Continuous Feedback     261
Agile Consensus in Action     262
The Next Version     263
Product Ownership and Stakeholder Engagement     264
Staying in the Groove     270
Testing to Create Value     275
TFS in the Cloud     275
Conclusion     276
End Notes     279

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.