MSF for CMMI Process Improvement

The Microsoft Solutions Framework also has a more formal instance called "MSF for CMMI Process Improvement." Capability Maturity Model Integration (CMMI) was originally developed by the Carnegie Mellon Software Engineering Institute (http://www.sei.cmu.edu/cmmi/) to assess defense, aerospace, and government contractors in a regulated environment. The MSF version of CMMI is partially based on the work of W. Edwards Deming, a renowned statistician in the area of quality control and statistical process.

Deming popularized statistical process control in the field of business and manufacturing in his theory of profound knowledge. To properly implement process controls, you must be able to identify the difference between common cause variations (CCVs) and special cause variations (SCVs): Common cause variations are natural fluctuations found in any process. Special cause variations are caused by special occurrences, environmental factors, and problems that affect a process. The challenge as a project manager is to correctly identify an instance of a special cause variation and reduce it. Complicating this goal is the fact that these variations usually occur on a random basis. The reporting component of Team System provides visual metrics to measure factors such as project health. These charts can help you determine whether the Upper Control Limits (UCLs) and Lower Control Limits (LCLs) are within operational boundaries. Figure 21-3 illustrates the two varieties of variation and the attainment of process improvement.

Figure 21-3

Another principle that influenced the development of MSF for CMMI Process Improvement is the Theory of Constraints (TOC) documented by Dr. Eliyahu M. Goldratt in his novel The Goal (North River Press, 2004). The focus behind the theory is the goal of constant improvement. Constraints (as defined by Goldratt) are bottlenecks preventing you from reaching a specific goal. By identifying physical and nonphysical constraints, you can focus your energies on eliminating (or reducing) the constraints, making your process more effective.

Team System is Microsoft's foray into the Application Lifecycle Model (ALM). The ALM was developed in response to the inefficiencies of software development projects such as budget overruns, delivery delays, and so forth (in other words, special cause variations). Process within a project is vitally important to bring down costs and increase productivity, which is why you are currently unable to create a project in Team System without first selecting a process template.

Important

Some of the working titles for MSF for CMMI Process Improvement include MSF Complete and MSF Formal. For in-depth insight on the development of MSF for CMMI Process Improvement, be sure to visit David J. Anderson's blog at http://www.agilemanagement.net.

System and hardware engineering processes have matured over the decades. Relative to manufacturing, software engineering is still in its infancy. CMMI is based on quality assurance ideas that came out of manufacturing. This makes sense from an operational perspective — most hardware manufacturing companies rely on software on the production line. For that reason, there are many varieties of CMMI specifications.

In a nutshell, CMMI is used to track the maturity of any software design organization, from requirements to validation. The CMMI has six maturity capability levels outlined in Table 21-1.

Table 21-1

Capability Level	Description
0	Incomplete Process
1	Performed Process. You have little to no controls in your project. The outcome is unpredictable and reactive. Frequent instances of Special Cause Variations. All of the process areas for performed process have been implemented and work gets done. However, the planning and implementation of process has not yet been completed.
2	Managed Process. You have satisfied all of the requirements for the implementation of a managed process. Work is implemented by skilled employees according to policies. Processes are driven according to specific goals such as quality and cost. Planning and review are baked into the process. You are managing your process.
3	Defined Process. In the defined process, you have a set of standard processes (or processes that satisfy a process area) within your organization that can be adapted according to specific needs.
4	Quantitatively Managed Process. All aspects of a project are quantitatively measured and controlled. Both your operational and project process are within normal control limits.
5	Optimizing Process. Continuous project improvement. CMMI Level 5 focuses on constant process improvement and the reduction of special cause variations. The project process is under constant improvement.

Important

There are two models for implementing CMMI: the continuous model and the staged model. In the continuous model, elements such as Engineering, Support, Project Management, and Process Management are each composed of a set number of process areas. A process area is a description of activities for building a planned approach for improvement. Using the staged model, the process areas are set up according to the five maturity levels. MSF for CMMI Process Improvement was designed to support the staged model.

Capability Level 3

The CMMI template included in Team System is designed to help you accelerate the appraisal to Level 3 compliance. The CMMI specifications are quite detailed (more than 700 pages long). Here are the characteristics of CMMI Level 3 (boiled down to three main points):

• Customized to the organization's set of standard processes according to the organization's guidelines

• CMMI Level 3 has a process description that is constantly maintained. This is implemented in Team System using work items and iterations.

• CMMI Level 3 must contribute work products, metrics, and other process improvement information to the organization's process assets. Process templates and the Project Site enable project managers to share metrics and documents with the rest of the team.

Business analysts, project, and release managers

Business analysts and managers can benefit from utilizing pre-established planning and management processes, based on lessons learned and best practices. Projects contain templates and historical metrics that apply regardless of what project you are working on, which help in the estimation phase of the project. You can detect and reduce defects early in the process and before you ship. From a business perspective, you can establish a project schedule and measure costs, which enables you to negotiate better contracts with your clients.

Developers, testers, and architects

CMMI Level 3 provides a solid process framework for developers, testers, and architects. With process, the knowledge and experience gathered during the project is quantifiable. That means any lessons learned can help improve the process, bugs are avoided, and code is enhanced. All of this information can then be leveraged on future projects. This also builds processes that are derived from best practices, much like MSF is derived from Microsoft's collective experience.

In a process-driven environment, the roles and tools are better defined because it is a more detail- oriented methodology. This helps team members stay focused within your organization. CMMI provides a focus on process and project management — in fact, the entire team shares the responsibility of making decisions, managing risk, and shaping and meeting requirements. CMMI emphasizes training and integrated teams to create an environment that facilitates the integration of end-to-end features and a verification process to lower bugs and keep the project on track in terms of QA and feature requirements.

CMMI Level 3 versus MSF for CMMI process improvement

Formal processes have a reputation of being too bureaucratic and lacking agility. The traditional way of planning software is using the waterfall method (see the section "Team Model" for more details). The plan is central to the process and usually a lot of ceremony is attributed to the handing off of the project (for example, a project plan sent to developers for a coding phase).

The Microsoft Solutions Framework will enable your team to operate at CMMI Level 3. MSF for CMMI Process Improvement adds work items such as Risk, Change Requests, and Issues (building on the work items already available through MSF for Agile Software Development). MSF for CMMI will also include additional reports to the base spec.

MSF CMMI is designed to be flexible. In fact, MSF CMMI out of the box will not "automagically" transform an organization into Level 3 — it needs to be augmented with the other parts of MSF not in Team System. (For example, some components not included in MSF, such as training, are required to reach that goal.) If you need a formal process architecture, MSF for CMMI Process Improvement provides a light and flexible meta-framework you can customize to your needs.

MSF for CMMI Process Improvement provides an example of an agile interpretation of CMMI when more often than not the interpretation is traditional, waterfall, command and control, and documentation centric. It is designed to be light, with almost no overhead or bureaucracy. David J. Anderson (one of Microsoft's leading architects for the CMMI for Process Improvement Framework) describes this hybrid in his book Agile Management for Software Engineering (Prentice Hall, 2003) as "the Learning Organization Maturity Model." The CMMI version of MSF has the following characteristics:

• It is geared toward larger-scale projects with a greater emphasis on breaking a project into phases and groups. MSF for Agile Software Development, conversely, is designed for smaller groups with quicker iterations.

• It is designed to conform to a process, rather than plans and specifications. Process improvement is implemented in two ways: by reducing variations within baseline operating conditions and instituting constant improvement using cyclical process structures.

• It does not support project management artifacts by default, such as time tracking. However, the specification can be extended to include earned value (EV), the critical path method (CPM), and other Enterprise project management features into the framework.

• Everyone on the development team is responsible for issue and risk management. The goal is to eliminate special cause variation.

• MSF for CMMI Process Improvement focuses on automation through Team System's toolset and the CMMI appraisal model via the reporting tools to measure quality, velocity, and productivity.

• It uses the Team Model whereby all team members are empowered to make decisions and take responsibility for the success of a project. This includes standup meetings and log, risk, and operations reviews.

• All software development contains constraints. They include time, personnel, functionality, resources, and budget. MSF for CMMI Process Improvement has the means to help you buffer uncertainties (SCVs) within your project, and measure events and activities outside the scope of your project. The MSF for CMMI model is geared to reduce variation.

• MSF for CMMI Process Improvement expands on CMMI with the concepts of release management, risk management, and iterative cycles.

• It includes custom work items, reports, and process guidance. Like its Agile counterpart, the framework is highly extensible and customizable.

• This version of MSF uses metrics such as remaining work (or cumulative flow) and iteration velocity (measuring work in progress to track project health).

• Microsoft is working with SEI and other partners to build the specifications.

In future versions of MSF, Microsoft is aiming for Level 5 compliance. They are also investigating making the process Sarbanes-Oxley (SOX) compliant. CMMI is required for dealing with government agencies and larger software companies (see Figure 21-4).

Please refer to the Microsoft Solutions Framework website for more detailed guidance and technical information about the MSF for CMMI Process Improvement specifications, at http://www.msdn.microsoft.com/vstudio/teamsystem/msf/msfcmmi/.

Figure 21-4

One of the key principles behind MSF is the concept of trust. A lot of the mechanics behind formal processes are designed for the purpose of accountability and conformance to specification — in other words, documenting, evaluating, and auditing each step of the process to make sure the quality of the end product remains high. In Agile methodologies, trust is inherent in the process — you have to trust that your developers will build quality features and build trust with your customers. MSF Agile and CMMI both foster agility by allowing your team members to focus on their core activities, automating documentation and policies, and most importantly building quality within the process.