Overview of MSF

Microsoft Solution Framework (MSF) is an Agile software development process framework for building software solutions. It incorporates the latest software development methods used by teams both inside and outside Microsoft. MSF utilizes proven Agile development techniques, extends the Agile approach to all phases of the development life cycle and provides specific guidance for each role on the software development team.

The latest version of the Microsoft Solution Framework, MSF 4.0, is built from the ground up with Microsoft Visual Studio Team System in mind. Why tie the methodology so tightly to the development environment? One of the biggest problems to plague most development methodologies is the lack of good tools to support the methodology. Development teams are often left to struggle with poorly integrated tools that were never meant to support the process. As a result, the team comes to view the methodology itself as a cumbersome impediment. Visual Studio Team System offers a set of tightly integrated tools, and MSF 4.0 is designed to take full advantage of those process tools. In this way, MSF and Visual Studio Team System complement one another; MSF is the methodology that guides the process, whereas Visual Studio Team System is the tool set that enacts the process.

Visual Studio Team System includes two versions of MSF. MSF for Agile Software Development (MSF Agile) is geared toward an adaptive process for smaller teams. MSF for CMMI Process Improvement (MSF CMMI) is geared toward a refinement process for teams that require a more rigorous approach. It is designed to accelerate the achievement of CMMI Level 3 with an emphasis on automation rather than documentation.

Each MSF version is implemented as a process template, which is a set of configuration files that tells Visual Studio Team System how to set up a new Team Project. The process template effectively sets the methodology for the project by specifying which tools will be used and how those tools will be configured and by installing the process guidance documentation.

Visual Studio Team System provides a framework for process innovation that allows the process template to be readily customized for individual projects. Each project can run a separate version of a process, yet the metrics can be consolidated across all projects, regardless of process choice.

A Brief History of MSF

MSF was first introduced in 1994 as a loose collection of best practices from Microsoft’s product development efforts and Microsoft Consulting Services engagements. MSF has evolved based on learning from the successful, real-world best practices of Microsoft development groups, Microsoft partners, and Microsoft customers.

MSF is managed and developed by a dedicated product team within Microsoft with guidance and review from an international advisory council of subject matter experts. MSF also continues to draw upon current Microsoft experience. The best practices from these internal project efforts are consolidated and distributed outside of Microsoft through MSF.

Note 

The MSF product team encourages feedback from the growing community of practitioners though a public forum on the MSDN Web site. This is an excellent place to get your questions answered and see what others are saying about MSF. You can access the forum at http://forums.microsoft.com/msdn/showforum.aspx?forumid=63.

Microsoft conducted market research to determine what should be included in MSF for Visual Studio Team System. This research indicated that the market wanted a method for enacting Agile software development. Most of this demand was coming from North America. However, there was also a significant demand for the ability to enact and accelerate CMMI appraisal to Level 3. This demand was coming mostly from Asia, but it also included large defense contractors in North America.

Agile Software Development

MSF utilizes a lightweight, adaptive approach known as Agile software development. Agile software replaces the traditional phased approach to software development, known as the waterfall life cycle model, with a more nimble approach that utilizes iterative, incremental development based on short delivery cycles. Each iteration is of fixed duration, typically 2 to 8 weeks. The goal of each iteration is to produce working software-a product that may not be feature complete but that is shippable. This technique, also referred to as timeboxing, minimizes risk by breaking up a software development project into a series of mini projects, each with a fixed time frame. These mini projects are much easier to manage than one large monolithic project, and they offer the opportunity to change course, or adapt, from one iteration to the next.

Although Agile software development has its roots in various iterative and incremental delivery methods going back several decades, the mid-1990s saw the emergence of a variety of lightweight methods that later came to be known as Agile.

Manifesto for Agile Software Development

The term Agile was first applied to software development in 2001 by a group of prominent thinkers who represented various philosophies, including Extreme Programming, Scrum, Dynamic Systems Development Method (DSDM), Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming. Later known as the Agile Alliance, this diverse and outspoken group of individuals introduced the world to the concept of Agile software development by way of a manifesto, complete with underlying principles. You can read the manifesto on the Agile Alliance Web site.

Innovations in MSF

Although MSF is built on Agile methods that are popular in the mainstream development community, it adds many new twists. Here are some of the ways that MSF extends Agile software development methods:

• MSF is the first Agile methodology that covers the entire software development life cycle and all of the team roles.

• MSF incorporates the notion of designing for operations, which is similar in concept to designing for manufacturing. This means that deployment and maintenance are taken into consideration early in the development process, not after the fact.

• MSF takes a unique approach to risk management. The Team Model in MSF offers seven constituencies of risk concern: Product Management, Program Management, User Experience, Architecture, Development, Test, and Release and Operations. Each of these constituencies must have at least one advocate to ensure appropriate coverage of concerns to mitigate risk. Roles within MSF are mapped against Team Model constituencies as advocates. Risks are identified based on prior data and experience from the advocates of each risk constituency. The probability of occurrence is weighed against the cost of mitigation and the impact of occurrence. Mitigation actions are then planned and managed to reduce the likelihood of occurrence, and consequently, they reduce variation in capacity. The advocates are then responsible for day-to-day risk monitoring.

• MSF utilizes lean project management with staggered planning. This approach is based on the assumption that creating software is a process of discovery. There are too many unknowns at the beginning of a project to create a detailed project plan. Furthermore, the requirements often change during the course of development. For this reason MSF takes an adaptive approach that involves an initial project plan that describes the overall approach and scope of the project and also establishes iteration length. The planning for each iteration occurs during the previous iteration so that the transition from one iteration to another can occur quickly and smoothly. In this way, planning is done progressively throughout the project, as needed, just in time, which makes the planning process highly adaptive.

• MSF specifies a system in terms of Scenarios and Quality of Service (QoS) requirements. A Scenario describes a specific user interaction with the system, a sequence of steps with a clearly defined result. A QoS requirement describes characteristics of the system such as security, performance, load, availability, stress, accessibility, serviceability, and maintainability.

• MSF uses personas to describes the various groups of users. Each persona is a composite description of the relevant characteristics of a particular user group.

• MSF introduces an Agile architecture design technique called shadowing. A leading shadow describes the architecture to be implemented in an iteration. As pieces of the leading shadow are implemented, they are moved to the trailing shadow. When the iteration is complete, the leading shadow is empty because all of the implemented parts have moved to the trailing shadow. In this way the trailing shadow is the accumulation of the architectures implemented so far. In other words, the trailing shadow always represents the architecture of the system as currently implemented.

• MSF utilizes test thresholds, which are metrics that specify the minimum quality required to release the product. Each test threshold acts as a quality gate. If the product doesn’t measure up to the test threshold, it doesn’t ship. Test thresholds are determined by the project team based on QoS requirements. The testing strategy is then based in part on these test thresholds. A typical test threshold is code coverage, that is, the percentage of the total code actually executed by unit tests. Simple projects that are not critical to the business may have a very low code coverage threshold, whereas complex applications involving life safety will have a very high code coverage threshold.

• MSF separates governance from capacity. Governance involves the allocation of resources to projects. It’s the management process used to maximize the flow of value to the customer by selecting the best projects to work on. Capacity involves the people, processes, and tools used to implement projects. Capacity seeks to maximize the flow of value to the customer by continually improving productivity and quality. Governance and Capacity both work to optimize the effectiveness of the software development effort in different yet complementary ways.

• MSF utilizes the automated reporting capabilities of Visual Studio Team System to create trustworthy transparency. Visual Studio Team System automatically tracks work item progress and links it to version control. In this way, collection of process data is an automatic by-product of the development process, and the work products are directly tied to this process data. As a result, the data generated by Visual Studio Team System is both transparent and trustworthy. MSF takes advantage of trustworthy transparency by focusing on the use of reports to drive objective, rational management decisions and interventions. MSF metrics are self-generating, relevant, and leading (or predictive) indicators of project health. Trustworthy transparency leads to realistic schedules, reliable estimates, sustainable pace of work, and professional maturity rather than a reliance on heroic efforts.