"Value-Up Processes"

Software Engineering with Microsoft Visual Studio Team System, Chapter 2 review:

In this chapter, the authors dive into the details of the processes that take place during the “Value-Up” software development life cycle (SDLC), and begin to discuss how those principals apply to Microsoft Visual Studio Team System (VSTS).

 

Key points, snippets & thoughts:

Build Your Method Up, Don’t Tailor It Down

Start with a simple SDLC process that meets the basic needs for your projects.  As your team assembles, begin to discuss the needs of your project and tailor your process to suit your needs.  General observations are that when teams attempt to use an “all-inclusive” SDLC process and tailor it down, they have a tendency to end up with unnecessary overhead.

* MSF for Agile Software Development
* MSF for CMMI Process Improvement

I have to be honest… before reading this chapter I never took a serious look at the CMMI process.  The title itself turned me off, and I quickly categorized this as a heavy weight, document centric waterfall process methodology.  However, this book has grabbed my attention and piqued my interest.

First of all, both of the MSF process templates are “Value-Up” processes focused on iterative development, with the ability to adapt when necessary.  Additionally, these templates were designed as a starting point for development teams, and they are designed for customization.  Here are some of the differences out of the box:

Fit the Process to the Project

Whether you are using a full suite of tools such as VSTS or not, my recommendation is to review your environment, business drivers, team, project, etc., and then make process & tooling related decisions before the project really starts moving.  Secondly, have a team huddle, and clearly communicate all decisions made so that everyone on the team is working within the same guiding principals.

Risk Management

Instead of looking at risk with avoidance scenarios for critical situations, VSTS encourages constituency based risk management.  This approach embraces necessary change, whereas the other attempts to prevent it.  VSTS accomplishes this by placing risk at a work item level and definition of the following advocacy groups (Setup for both MSF process templates):

• Program Management (for Solution Delivery)
• Architecture
• Test, Quality Assurance
• Release/Operations
• User Experience
• Product Management (for Customer Business)

One Project at a Time Versus Many Projects at Once

This didn’t really seem to fit well within the chapter, but the authors threw in a great gem about project planning, and context switching.  The authors wanted shed light on the fact that many projects don’t include time in their estimates and project plans for additional overhead that is challenging to compute.  Gerald Weinberg came up with the following to compute time wasted caused by juggling multiple projects.

No. Simultaneous Projects	Percent of Time on Project	Loss to Context Switching
1	100%	0%
2	40%	20%
3	20%	40%
4	10%	60%
5	5%	75%

 

Final thoughts:

Excellent topics throughout the chapter.  I thought the text wandered around a bit from topic to topic and wasn’t sure where the authors were going to go next, but the content itself was very effective.  This chapter alone opened my eyes to the CMMI process template, and in the business of consulting I find many of the principals within that template to be very important.  I don’t want to stray too far a way from this chapter review so I hope to write another post about how some of these topics apply to the world of consulting

For additional resources on VSTS templates and tools you may find valuable information here:

http://www.codeplex.com/process
http://msdn.microsoft.com/en-us/teamsystem/aa718795.aspx

 

If this is the first post you’ve read about my review of this book… don’t forget to read the others:

• Chapter 1