Whats New in MSF 4.0

What's New in MSF 4.0

MSF 4.0 is a descriptive framework. In fact, the MSF 4.0 framework is similar to MSF 3.0 in many respects, but here's the big difference: MSF 4.0 also includes the aforementioned prescriptive methodologies: Agile and CMMI Process Improvement. One way of looking at it is to consider these methodologies as instances of the framework. These prescriptive methodologies are implemented in Visual Studio 2005 Team System.

Descriptive vs. Prescriptive
A descriptive SDLC model documents the process passively, from the point of view of an observer. Descriptive models are useful as the basis for understanding and improving software development processes. A prescriptive SDLC model, on the other hand, describes the process in terms of the players involved, the sequence of activities, and the end products. If software development is like baking a cake, the descriptive model is a narrative that contains useful guidelines for baking cakes in general, while the prescriptive model is the recipe for baking a particular cake, say, German chocolate (my favorite). Put yet another way, a descriptive model can be translated into one or more prescriptive models, and each prescriptive model can be translated into action.

The MSF 3.0 framework and the MSF 4.0 metamodel are structurally similar. They both contain foundational principles, a team model, a process model, and disciplines. As you might expect, MSF 4.0 makes changes to these components based on the current state of the art, but these changes are incremental in nature. Because the notion of incremental improvement is built into MSF, it makes sense to apply that philosophy to MSF itself. We'll briefly review the changes to each of the MSF components before examining the MSF 4.0 metamodel in detail.

NOTE
The MSF 4.0 framework is often referred to as the MSF 4.0 metamodel. The terms framework and metamodel are interchangeable, although Microsoft appears to prefer the term metamodel in MSF 4.0. We'll use the term metamodel from here on.

MSF 3.0 contains eight foundational principles:

• Foster open communications.

• Work toward a shared vision.

• Empower team members.

• Establish clear accountability and shared responsibility.

• Focus on delivering business value.

• Stay agile, and expect change.

• Invest in quality.

• Learn from all experiences.

MSF 4.0 includes all the foundational principles in MSF 3.0 and adds two more:

• Partner with customers.

• Always create shippable products.

The Team Models for both MSF 3.0 and MSF 4.0 describe a team of peers with shared responsibility, clear accountability, and open communications.

MSF 3.0 describes team member roles in terms of the following Role Clusters:

• Product Management

• Program Management

• Development

• Test

• User Experience

• Release Management

MSF 4.0 replaces the term Role Cluster with Advocacy Groups, where each Advocacy Group has a Constituency with representation on the team. The MSF 4.0 Advocacy Groups are identical to the MSF 3.0 Role Clusters except that MSF 4.0 adds another Advocacy Group: Architecture. (See Figure 8-1.)

Figure 8-1 Process Model comparison

The MSF 4.0 Process Model builds on MSF 3.0. It includes the same iterative development process, including a setup iteration at the beginning and a release iteration at the end of the project cycle. The MSF 4.0 Process Model is definitely an improvement because it more accurately reflects the complete life cycle of a development project.

MSF 3.0 includes three disciplines: Project Management, Risk Management, and Readiness Management. Disciplines tend to be prescriptive in nature, and they can vary significantly from one methodology to the next. For this reason, the MSF designers chose to remove disciplines from the metamodel altogether and add them to the methodology process guidance instead. You can find the MSF 3.0 disciplines more or less intact in the process guidance for MSF for Agile Software Development, but the disciplines in the process guidance for MSF for CMMI Process Improvement will more closely reflect the Capability Maturity Model (CMM) Key Practice Areas for a Level 3 organization.

CMMI, CMM, and Key Practice Areas will be covered later in the chapter.

MSF 4.0 Key Concepts

MSF 4.0 was built on a foundation of key concepts that inform the methodology. These concepts fall into four major groups: principles and mindsets, the team model, cycles and iterations, and governance. Let's examine each group in more detail.

Principles and Mindsets

MSF 4.0 principles describe the behavior of highly effective software development teams. These principles are divided into core ideas and mindsets. The core ideas embody an overall philosophy, whereas the mindsets suggest a way of thinking that motivates the actions of individual team members.

Principle: Partner with Customers

Customer validation is often the difference between real and fictional business value. Understanding the value proposition of your solution and communicating it effectively are key success factors.

Principle: Foster Open Communications

To maximize members' individual effectiveness and optimize efficiencies in the project, information has to be readily available and actively shared.

Principle: Work Toward a Shared Vision

Having a generally long-term and unbounded vision inspires the team to rise above its fear of uncertainty and preoccupation with the current state of things and to reach for what could be.

Principle: Quality First

Quality requires both bug prevention and solution verification. Utilize practices such as code analysis and buddy reviews to prevent bugs as well as to maximize the testing to find bugs. All roles are responsible for the prevention and verification of bugs.

Principle: Stay Agile, Adapt to Change

The more an organization seeks to maximize the business impact of a technology investment, the more it ventures into new territories that are inherently uncertain and subject to change. This uncertainty requires the team to stay responsive to changing conditions and unanticipated situations.

Principle: Always Create Shippable Products

The team should be committed to creating the highest-quality product while making changes. Each change should be done in the context of the belief that the product should be ready to ship at any time.

Principle: Flow of Value

Plan, execute, and measure progress and velocity based on the delivery of increasing value to the customer and rising return on investment. Minimize those activities that do not add customer value because they are wasteful. Use iterations to maintain the cadence of work products that your customer can evaluate. Make the handoffs of work from one team member to another as efficient as possible.

Mindset: Quality Is Defined By Customers

Satisfied customers are priority number one for any great team. This satisfaction includes both internal and external customers. A customer focus throughout development means having a commitment from the team to understand and solve the customer's business problem.

Mindset: Pride of Workmanship

Taking pride in contributing to a solution is an important part of creating a quality product. Motivation and a sense of responsibility result from this pride.

Mindset: Team of Peers

The “team of peers” mindset places equal value on each constituency. This mindset requires unrestricted communication between the roles, transparency, and a single visible backlog. The result is increased team accountability and effective communication.

Mindset: Frequent Delivery

Nothing establishes credibility like frequent delivery. It's more than having a nearly shippable product every day; it's about responding to the needs of your customers with small, quality deliverables that show progress. Through frequent delivery, process and infrastructure are proven and improved. Risks, bugs, and missing requirements are detected early. Feedback can be provided when it can make a difference.

Mindset: Willingness to Learn

Because each development project, environment, and team is unique, each project and iteration within the project creates a learning opportunity. However, there can be no learning without honest feedback and reflection. Unless there is a supportive environment that fosters courage and personal safety, feedback will be limited and not placed in a light of improvement. After these factors are in place, individuals and teams can focus on ongoing self-improvement, gathering a sharing of knowledge, and beneficial lessons learned. Additionally, there will be opportunities to implement proven practices of others and to commit time in the schedule for learning.

Mindset: Get Specific Early

Too many projects lose time because of people procrastinating about the “big” picture instead of tackling solvable problems. This mindset stresses taking one step at a time and learning from specifics rather than the abstract. Defining the project in everyday terms is a key to effectively building working code, passing tests, and creating deployable bits.

Mindset: Qualities of Service

A quality of service (QoS) mindset looks at the solution and develops plans based on every aspect of the customer experience. The idea is that qualities of service such as performance and security should not be considered late in the project but throughout it.

MSF 4.0 Structure

MSF 4.0 contains both descriptive and prescriptive components. (See Figure 8-2.) The descriptive component is called the MSF 4.0 metamodel, which is a conceptual description of SDLC best practices. The metamodel is not tied to any specific methodology—it can be implemented in various ways.

Figure 8-2 MSF 4.0 structure

MSF 4.0 implements the metamodel as prescriptive methodologies that provide specific process guidance. Team System comes with two MSF 4.0 methodologies: MSF for Agile Software Development and MSF for CMMI Process Improvement. You'll see how Team System implements these methodologies later in this chapter. But first, let's take a closer look at the MSF 4.0 metamodel and the two MSF 4.0 methodologies. Figure 8-3 shows the MSF 4.0 metamodel.

Figure 8-3 MSF 4.0 metamodel

The MSF 4.0 Team Model

The MSF 4.0 Team Model consists of peers who represent all the constituencies involved in the production, use, and maintenance of the product. There is no hierarchy involved—no team member is more important than another. There is, however, a reporting structure, but it is not that important in the context of the Team Model. This approach reduces risk by producing a system of checks and balances that guides the team toward the right solution.

Each team member acts as an advocate on behalf of the constituency that he or she represents. There are seven constituencies in the MSF 4.0 Team Model:

Product Management

Advocates for the Customer Business. Product management is responsible for project success from the standpoint of the customer requesting the solution.

Program Management

Advocates for Solution Delivery. Program management is responsible for delivering the solution within project constraints.

Architecture

Advocates for Systems in the Large. Architecture is responsible for ensuring that the solution is correct in terms of its place in the business or product family road map, its ability to interoperate with other services, and its compatibility with the infrastructure in which it will be deployed.

Development

Advocates for the Technical Solution. Development is responsible for designing and building the solution, including unit tests and providing estimates as needed to program management.

Test

Advocates for Solution Quality from the Customer Perspective. Test is responsible for identifying and reporting any issues that diminish the solution quality in the eyes of the users or customers.

User Experience

Advocates for the Most Effective Solution in the Eyes of the Intended Users. User experience is responsible for understanding the user's context as a whole and ensuring that the rest of the team keep the user experience in mind.

Release/Operations

Advocates for the Smooth Delivery and Deployment of the Solution into the Appropriate Infrastructure. This group is responsible for the timely readiness and compatibility of the infrastructure for the solution.

The MSF 4.0 Team Model, which you can see in Figure 8-4, can be scaled to fit various projects. For small projects, each team member might represent multiple constituencies. Larger projects can be organized into a team of smaller MSF teams.

Figure 8-4 MSF 4.0 Team Model

NOTE
Working in a team of peers is not always easy. There's an art to making a team of peers work well. It requires a great deal of collaboration, negotiation, and effective communications, as well as clear ground rules that all the team members buy into. For really useful information about creating an effective team, I recommend The Team Handbook, Third Edition by Barbara J. Streibel (Joiner/Oriel Inc., 2003).

MSF 4.0 Cycles and Iterations

The MSF 4.0 Cycles and Iterations describe a process model consisting of a series of short development cycles. Small iterations support continuous learning and refinement, reduce the margin of error in estimates, and enable incremental testing and delivery of the product.

The first iteration deals with the startup activities associated with a new project—typically project planning and setting up the development and test environments. Each subsequent iteration focuses on implementing specific features of the system, resulting in a stable, functional version of the product. Each incremental version of the product might be an unreleased alpha test version, released to the user community as a beta test version or released as a functional incremental version that can begin delivering value immediately. Each iteration often includes testing deployment procedures as well. The final iteration involves the transition of the product from development to production. This transition includes final acceptance testing and deployment. Figure 8-5 shows you the MSF 4.0 Cycles and Iterations.

Figure 8-5 MSF 4.0 Cycles and Iterations

MSF 4.0 Governance

Governance refers to the executive decision-making process that allocates software development resources based on the flow of value. MSF 4.0 defines five tracks that roughly correspond to phases in the project. Each track concludes with a governance checkpoint, a go/no-go decision point that provides an opportunity to authorize continued work on the project or to cancel or suspend the project.

Do not confuse tracks with the Cycles and Iterations described earlier—they deal with the operational aspects of the project (the day-to-day activities). Tracks, on the other hand, deal with organizational governance—the allocation of resources. Another way to think of it is that Cycles and Iterations produce tangible work products, whereas Governance tracks produce decisions.

It's interesting to note, though, that tracks and iterations are related. Looking at Figure 8-6, you can see that each iteration involves one or more tracks, and the tracks involved give each iteration its focus.

Figure 8-6 MSF Governance