Components of MSF

MSF is a framework made up of various conceptual components. These components, shown in Figure B-1, represent a set of practices that complement each other in such a way that the sum of the practices is greater than each one used in isolation.

Figure B-1: MSF components

Cycles and Iterations

Software development projects based on MSF utilize an iterative development process. In other words, a project is split up into a series of mini-projects called iterations that last a few weeks each. As such, MSF-based projects are cyclical in that each iteration starts with planning, followed by execution, and wrapped up with a retrospective evaluation. Although the work performed changes from one iteration to the next, the cyclical nature of the iterations give the project a rhythm that helps the project team perform. The repetition produces a sense of familiarity, and with each iteration the team gets better at what they are doing-fine-tuning the process, increasing their velocity and improving their productivity.

Every iteration, except the first, begins with an iteration plan. An iteration plan specifies the Scenarios, QoS requirements, and bug allotments that are scheduled for the iteration. In the first iteration, the second iteration is planned. In the second iteration, the development and test team work on the tasks that they have chosen from this plan. Meanwhile, the third iteration is planned. In this way, there is only one checkpoint: the end of one iteration and the beginning of another. The retrospective and iteration planning meeting mark this checkpoint.

Advantages of iterative development include:

• Continuous learning and refinement.

• Mid-course corrections can be made.

• Reduced margin of error in your estimates.

• Fast feedback about the accuracy of your project plans.

Each iteration results in completion of a stable portion of the overall system. In many internal IT projects, each iteration also results in the a new release of the application. This allows the development team to deliver useful results to the customer early and often. In MSF, putting useful software into the hands of the customer is known as flow of value.

Governance

Governance involves the management of resources with the goal of maximizing the flow of value to the customer. MSF governance concerns itself primarily with aligning IT projects toward the benefit of the overall organization and its stakeholders. To that end, MSF governance ensures that each project obtains the required approvals and direction at clearly specified checkpoints throughout the project life cycle (Figure B-2).

Figure B-2: MSF tracks

MSF specifies five tracks with each track representing a logical group of activities associated with a specific governance checkpoint. Each checkpoint is like a go-no-go gate through which the project must successfully pass in order to continue. This go-no-go gate consists of one or more governance questions. The answers to those questions result in a management decision, and the management decision brings the track to an end.

Principles and Mindsets

The behavior of a highly effective software development team can be described in terms of the principles that guide the team’s actions. Principles empower the team by providing a framework that guides the team’s day-to-day decisions. MSF offers a set of principles that the team can use as a starting point as it establishes its own principles.

Core Ideas

MSF divides principles into core ideas and mindsets that complement one another. The core ideas embody an overall philosophy, whereas the mindsets suggest a way of thinking that motivates the actions of individual team members. The core ideas are as follows:

Partner with Customers Software development is a process of discovery. As mentioned before, many software development projects start with ambiguous, incomplete requirements. For this reason, it is important that the project team work closely with the customers to better understand their needs and to frequently solicit their feedback as work progresses. This partnership is vitally important for the project team to deliver the greatest value to the customer.

Foster Open Communications People are competitive by nature. To that end, some folks are reluctant to share information with their teammates because they think it will give the others a competitive advantage. This sort of attitude is counter-productive because it hurts overall team performance. It is important that every team member understands that their indivual success is tied directly to the success of the team. When team members think of success in these terms, communications will flow freely thoroughout the team. People make better decisions when they have all the facts at their disposal. It’s interesting to note that this free flow of information helps the team because it maximizes individual effectiveness. In this way, the person who shares information freely with the rest of the team is more likely to be personally successful than the team member who withholds information.

Work Toward a Shared Vision Think about it-every great team achieves outstanding performance when all the members share a common vision of the team’s ultimate objective. A software development team is no different. That shared vision focuses the team members on a common goal, which naturally leads to an alignment of interests. A shared vision promotes cooperation and collaboration within the team based on a sense of common purpose.

Quality Is Everyone’s Business Every Day Enlightened manufacturers have learned that quality is not something you can achieve by inspecting the product after it is produced. Quality must be built into the product at every step in the process. This is true for any type of product, from toasters to televisions to automobiles. Software is no different in this regard. All the team members should feel a sense of responsibility for software quality regardless of their roles. The quality of the final product-the software-depends on each step in the development process, from design to implementation to deployment. Defects can be introduced at any point in the process. Of course, testing is still important to ensure that the software performs as expected. However, Agile project teams don’t wait until the software is complete to perform testing. Rather, they utilize testing throughout the development cycle to verify that each new feature added is performing correctly and that all previously implemented features continue to work properly. In general, the earlier a defect is caught, the less expensive it is to repair. However, the best defect is the defect that never happened. To that end, pride of workmanship and continuous improvement are very important to software quality.

Stay Agile, Adapt to Change We live in a turbulent world of uncertainty and change. Your project team must function in this environment. Change is a fact of life: new opportunities pop up; problems occur; platform technologies evolve; new patterns and practices emerge; project team members come and go; and so on. The best way to cope with change is to embrace it, and the best way to embrace change is to take an incremental approach. Don’t try to plan too far ahead. Do work in short iterative cycles. At the end of each iteration, evaluate the results, make adjustments, and then do it again. This approach forms the basis for Agile software development.

Make Deployment a Habit One area where software development teams run into problems is deployment. Frequently, software works perfectly in the development environment, but when the team goes to deploy it, all sorts of problems crop up. The deployment environment might use a different version of the operating system, or maybe it’s missing some required components. And then there is the common issue of misconfigured permissions that prevent things from working. By making deployment a habit and by practicing and testing deployment procedures, even with early–life cycle prototypes, the whole team learns how to make deployments run smoothly and predictably.

Flow of Value The flow of value refers to the delivery of business value in the form of software from the project team to the customer. It’s a subtle but important distinction for a team to realize that its objective is not to deliver software per se, but rather to deliver business value. When team members start thinking of their work in terms of the flow of value it produces, then value-added practices start replacing wasteful practices, which in turn leads to increased productivity, increased throughput, reduced costs, improved quality, and increased customer satisfaction.

Mindsets

Quality Is Specified by the Customer Software exists to satisfy the needs of its intended audience-the customer. To that end, it’s the customer who ultimately determines quality in terms of the software’s ability to meet its intended purpose. A customer-oriented mindset means that the project team’s number one priority is to understand and solve the customer’s business problem.

Pride of Workmanship The quality of a software solution tends to be directly related to the pride the project team takes in its design and construction. Team members who take pride in their work pay attention to the details that make the difference between merely satisfactory software and really great software. Pride of workmanship comes from within each team member, but as a project manager, you can reinforce this sense of pride through recognition for a job well done.

Team of Peers Each member of a software development project team contributes to the development process. This team-of-peers mindset places an equal value on each of the team members and the roles they play. No one team member is more important than another. This sense of equality produces more open and transparent communications as well as a common sense of accountability for the outcome of the project.

Frequent Delivery Historically software development teams delivered a software solution only after it was feature complete; i.e., it met all the requirements. Iterative development methods allow a project team to take a different approach by delivering the software solution incrementally. Frequent incremental delivery offers many benefits. The most important benefit is that it accelerates the flow of value to the customer. In most cases software does not need to be feature complete to be of value to the customer. By implementing the most valuable features first-as determined by the customer-and then delivering the software incrementally as features are completed, the project team allows the customer to realize that value as soon as possible. The team establishes credibility when it delivers useful results to the customer early and often. What’s more, frequent delivery provides important customer feedback that allows the team to detect and resolve risks, bugs, and missing requirements in a timely manner. Frequent delivery also allows the team to validate and improve its processes and infrastructure.

Willingness to Learn Software development teams perform best when their members have a thirst for knowledge. Software development is a rapidly changing field in which technical knowledge quickly becomes obsolete. Team members who keep up on the latest advances in tools and methods are in the best position to evaluate alternatives and maximize the flow of value to the customer. But a willingness to learn goes beyond keeping up with technology. Each project, indeed each iteration, offers an opportunity for the team to learn from its successes and mistakes and apply those lessons learned to their ongoing efforts. As a project manager, you can foster a learning environment by scheduling time for reviews, retrospectives, and training activities.

Get Specific Early Analysis and design are important aspects to every software development project. However, it’s possible to have too much of a good thing. In other words, the team can spend too much team designing an elegant solution instead of tackling solvable problems. This mindset encourages the team to define the big picture in broad strokes, then define specific goals through scenarios, and then describe specific implementation through the use of storyboards and prototypes. Getting specific early provides concrete examples that facilitate communications which, in turn, provides a rich source of feedback that further informs the design process. Getting specific early is key to clearly understanding both the problem and the solution, which is key to effectively building working code, passing tests, and creating deployable bits.

Qualities of Service Software development teams have a natural tendency to focus on features initially and defer quality of service considerations such as performance, security, and scalability. It’s important to keep in mind that quality of service requirements are often just as important as features in terms of value to the customer. A system with unacceptable response time is just as useless to a customer as a system with the wrong features. Failure to consider quality of service requirements early in the project can lead to expensive rework later. A quality-of-service mindset looks at the solution and develops plans based on every aspect of the customer experience.

MSF Team Model

The Team Model, depicted in Figure B-3, describes a team of peers who represent all of the constituencies involved in the production, use, and maintenance of the product. Each team member acts as an advocate on behalf of the constituency that he or she represents. There is no hierarchy involved-no team member is more important than another. This approach reduces risk by producing a system of checks and balances that guides the team toward the right solution.

Figure B-3: MSF Team Model

The fundamental principles of the MSF Team Model are:

• A team of peers with clear accountability, shared responsibility, and open communications. Each role is accountable for a specific share of the quality of the overall solution.

• Advocacy for all key constituencies who must be represented on a successful software project. Every perspective is represented to provide the checks and balances that prevent errors of omission and lopsided decisions.

• Stretch to fit to the scale necessary for the specific project. Constituencies may be combined in small teams or further refined as teams scale for larger projects.

Roles

Each member of the project team plays at least one of the roles and is accountable for advocating on behalf of the constituency that that role represents within the Team Model.

Table B-1 shows how MSF Roles relate to the MSF Team Model advocacy groups.

Table B-1: Mapping MSF Roles to the MSF Team Model
Open table as spreadsheet

Team Model Advocacy Groups	Roles MSF Agile	MSF CMMI
Program Management	Project Manager	IPM Officer Project Manager
Architecture	Architect	Infrastructure Architect Solution Architect
Development	Developer	Build Engineer Developer Development Manager Lead Developer
Test	Tester	Test Manager Tester
Release/Operations	Releaser Manager	Release Manager
User Experience	Business Analyst	User Education Specialist User Experience Architect
Product Management	Business Analyst	Auditor Business Analyst Product Manager Sponsor Subject Matter Expert

Workstreams, Activities, and Work Items

MSF organizes work into workstreams and activities and then tracks work by using work items. A workstream is a group of activities that flow logically together and are often associated with a particular role. An activity is work performed to accomplish a specific objective. For instance, Define Personas is an activity that produces a specific work product-namely a Personas document.

Roles are assigned to each workstream and activity by using a common project management technique called RACI, which is an acronym that represents the four assignment categories:

• Responsible One or more roles responsible for performing the work.

• Accountable The one role with overall responsibility for the workstream or activity.

• Consulted The roles that provide input.

• Informed The roles the members of whom should be kept informed, that is, they have a vested interest.

A work item is a database record on the Visual Studio 2005 Team Foundation Server that is used to track the assignment and state of work, as shown in Table B-2. Each version of MSF has its own unique set of work items, which you can customize to meet the needs of your organization or project. You can add or remove work items and even add or remove fields for each work item.

Table B-2: MSF Work Items Track the Assignment and State of Work
Open table as spreadsheet

MSF Agile	MSF CMMI
Bug	Bug
QoS requirement	Change Request
Risk	Issue
Scenario	Requirement
Task	Review
	Risk
	Task

MSF at a Glance

The MSF Process Guidance, the Web-based documentation built into the MSF process templates, does a great job of providing context-based guidance at each step of a project. As a project manager, you will most likely click the Roles tab, select Project Manager, select the appropriate track, and then view the relevant workstreams, activities, work items, examples, and templates.

Sometimes, though, it’s helpful to see the big picture. Understanding the overall structure of MSF gives context to the individual activities and work items. There are many different dimensions to MSF: tracks, workstreams, activities, roles, responsibilities, and so on. As a result, it’s difficult to show all these dimensions at once, especially when you need to represent it in two dimensions on the page of a book.

As it turns out, the Responsibility Matrix, a familiar project-management tool, does a pretty good job of showing the overall structure of MSF at a glance. Figure B-4 shows a portion of the Responsibility Matrix for MSF Agile. You can find the complete Responsibility Matrix for MSF Agile as a PDF document at http://blog.arrowrock.com/sourceart/2006/02/07/MSFAnalysis-Tool.aspx. This article also includes a PDF document containing the Responsibility Matrix for MSF CMMI.

Figure B-4: Responsibility Matrix: MSF for Agile Software Development (Entire chart available at http://blog.arrowrock.com/sourceart/2006/02/07/MSFAnalysisTool.aspx)

Joel Semeniuk

Joel Semeniuk is a Microsoft Regional Director and a Microsoft MVP in Team System with more than a decade of software project management experience. He has worked with Visual Studio Team System since its early development and has travelled the world lecturing, teaching, and helping customers adopt Team System. Joel is the author of two other books on programming software, and he blogs regularly about Visual Studio Team System and software development best practices.

Martin Danner

20 years and is a Project Management Professional (PMP) as well as a Microsoft Architect Most Valuable Professional. Martin contributed to a Microsoft Press book and Microsoft courseware on Visual Studio Team System during its development. Martin is a Senior Software Engineer at Healthwise, and he also provides training and consulting services through Accentient.