A couple of weeks ago I was presenting MSF v4.0 to a prospective customer. I got to the end of a 3 hour walkthrough and one of the audience threw me off balance with this comment, "it seems undifferentiated from [insert name of other popular methodology here]." I was taken aback by this. Yes, we might have 5 tracks (formerly known as phases in MSF v3.0) and yes some other rivals also have 5 phases. Hmmm. So we're updating the MSF guidance to detail the many innovations we're bringing not just to MSF and process guidance but to the field of software engineering. We truly believe that we are innovating with MSF v4.0 and beyond that we have a clear roadmap of further innovations for future versions. It will be at least a month before this material is available in a guidance download. Here is your first chance to see it.

(1) Separation of governance from capacity

MSF separates out the corporate and project governance for allocation of resources to projects and the value the project seeks to create, from the operational management of functional capacity, throughput and its variation.

Governance

Which projects should we do? Which features should be included in the product that project is producing? How much of our capacity should we allocate to this project? What's the return on investment? How can we deliver value into the hands of customers early and often? These are all valid questions for good corporate and project governance? MSF makes these the responsibility of the product managers, project managers, the integrated project management office and senior management.

Capacity

Meanwhile, what's the capacity of our development organization? Our test organization? Our user experience function? How can we increase that capacity? How can we maximize effectiveness of the function? What's the variation in capacity and productivity? What causes that variation and how can it be minimized? These are all valid questions about the operational function of the organization. Functional structures are a fact of corporate life, because functional groups are efficient. Accordingly, MSF does not matrix everyone under a project manager or project director. MSF recognizes that capacity, productivity and its variation are important and functional managers have a role. That role is to maximize and increase capacity, and the reliability of that capacity through the reduction of variation. Reduction of variation includes improving quality to reduce capacity sucking rework and regression.

(2) Lean Project Management

Project management in MSF using Team System takes a Lean approach. The flow of value creation through a lifecycle of progressive functional steps is tracked and managed by monitoring the queue of work at each step. The Work Remaining report uses a cumulative flow chart developed for Lean Manufacturing. Work-in-progress and queuing can be monitored with this report in order to identify bottlenecks and address issues which are affecting throughput and reducing capacity.

(3) Trustworthy Transparency

MSF leverages Team System to track progress of work items and link that progress to check-in policies for artifacts stored under version control. The reporting in Team System provides transparency on progress. By tying the work item lifecycle to the control of artifacts in version control, Team System makes that transparency trustworthy. Metrics collection is friction-free, because it is a by-product of everyone's work, not an overhead sucking capacity and producing waste. As the reports reflect the status of real work and faking the data would require tampering with real work - something that would be unacceptable to team members - the reports from Team System are both trustworthy and transparent.

MSF takes advantage of trustworthy transparency by focusing on the use of reports to drive objective, rational management decisions and interventions. MSF metrics have been selected to be simple, 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.

(4) Qualities of Service

Too often non-functional requirements are second class citizens in project scope. Often they are added as an afterthought and they are treated in the "nice to have" category. MSF elevates non-functional requirements to first class citizens in the project scope through the definition of Quality of Service Requirements. For example, performance and security are not added as an afterthought, but are planned and scheduled from the beginning and developed into the product as recognized value within the required scope.

Qualities of Service can differentiate a product from its competitors. They can represent true customer value and defensible differentiation against competitors products. MSF requires that Qualities of Service are taken into account from the beginning and that systems are architected to deliver the required qualities of service from the beginning.

MSF leverages guidance from Microsoft's Patterns and Practices Group to provide context-specific guidance on qualities of service, such as the incremental threat modeling method for security requirements, architecture and design. Through incorporation of incremental threat modeling, security requirements are treated as first class citizens in MSF.

(5) Constituency and Event-Driven Risk Management

Risk Management is not new, but the MSF approach is. MSF combines a day-to-day event-driven risk monitoring with the MSF Team Model, which treats risks as future special cause events with a probability and impact of occurrence.

The Team Model in MSF offers seven constituencies of risk concern - Product Management, Program Management, User Experience, Architecture, Development, Test, Release and Operations. Each of these constituencies must have at least one advocate to insure appropriate coverage of concerns to mitigate risk. Roles within MSF are mapped against Team Model constituencies as advocates.

Risks are future potential special cause events that might block productivity, reduce capacity and impact project schedules. They 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 reduce variation in capacity. The reduced variation, in turn, improves the reliability of delivery and improves competitiveness through shorter schedules.

(6) Continuous Adoption Curve - Agile through CMMI

By developing a Deming-based quality assurance approach to the CMMI and by incorporating all the guidance from MSF for Agile Software Development within that approach, MSF offers organizations a smooth adoption curve up the organizational process maturity ladder.

MSF for CMMI Process Improvement provides acceleration to CMMI Level 3 and provides a basis for progress to Level 4 and Level 5 with up to 35% coverage of practices at those higher levels. Future work in MSF will provide additional guidance on how to smoothly move to Level 5 and adopt the use of statistical process control with existing metrics and reports such as Velocity and Work Remaining. This leads to full implementation of Deming's Theory of Profound Knowledge and his teaching of the avoidance of management mistakes #1 and #2.

MSF v4.0 is innovative and provides a clear roadmap of continued innovation in version 5.0.

(7) Situationally specific, context-driven project guidance

MSF understands that no one size fits all. MSF provides two process templates and 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

In all cases, MSF adopts the use of concrete and specific methods for requirements solicitation and capture through the use of Personas and Scenarios. Unlike other methods which use abstractions and encourage analysts to get abstract early, MSF encourages the use of concrete examples through the lifecycle.

Concrete examples improve context throughout iterations and reduce the need for end-to-end traceability or for documentation explaining the meaning behind abstractions. MSF believes that concrete persona definitions and usage scenarios are more memorable for developers and testers. Concrete scenarios lead to better quality assurance than the use of abstractions, which often hide the true goals of the user from the developer or tester.

(8) Full Life Cycle Agile Methodology

Where many attempts to capture the spirit of the Manifesto for Agile Software Development in methodologies have focused purely on coding and testing, or iteration planning and issue management, MSF delivers a full lifecycle agile method with an expanded set of roles including business analyst and release manager. From creating the vision statement through to deployment of a working system, MSF for Agile Software Development describes the entire lifecycle for a project being undertaken in an agile fashion. MSF for CMMI Process Improvement incorporates MSF for Agile Software Development and hence both MSF v4.0 process guidance offerings deliver a full lifecycle agile methodology.