The forthcoming release of Visual Studio Foundation Server will include two methodology templates for the next version of MSF (the Microsoft Solution Framework). These are MSF for Agile Software Development (MSF Agile) and MSF for CMMI Process Improvement (MSF4CMMI). These two templates map MSF 4.0 onto two distinct software development methodologies.
What is MSF 4.0?
MSF has been undergoing continuous development and improvement for over a decade. The original vision for MSF was to collect and organise a body of guidance and best practice for the software development life cycle drawn from Microsoft’s experience, industry best practice and partner input.
Historically, Microsoft has always been very careful to avoid turning MSF into a methodology. By this, I mean that the adoption of MSF has never mandated the purchase of expensive tools, templates, etc., or the adoption of highly prescriptive and detailed processes. Instead, MSF consciously aims to provide a higher-level framework, or meta-model, of guidance and principles which can be mapped to a variety of discrete methodologies. This includes both ‘home-grown’ processes, and industry recognised methodologies such as DSDM and RUP. In the mid 1990s there were several reasons for adopting this approach. One was the environment of autonomous product groups within Microsoft. MSF grew out of an internal effort to foster process improvement within Microsoft in a culture that encouraged a high degree if independence amongst development teams. Microsoft was not willing to force a one-size-fits-all methodology upon its product teams, but needed some mechanism by which they could promote and communicate principles of best practice across the company. By extension, this thinking applied also when Microsoft made MSF publicly available. They knew they couldn’t dictate methodology to their partners or the industry in general.
MSF has come a long way since its earliest incarnations, and has undergone two major revisions. Visual Studio Team System coincides with a third revision (version 4.0), and this version represents a significant evolution of the framework. Two general characteristics are immediately obvious in this respect.
- There is a much stronger emphasis on the use of a supporting toolset (Visual Studio Team Services). MSF retains its role as a meta-model, but the advent of Team Service methodology templates for MSF means that the framework will probably now be perceived, incorrectly, as a methodology (or, rather, two associated methodologies) in its own right.
- Taken together, MSF Agile and MSF for CMMI Process Improvement show a clear commitment to ensure that Microsoft’s software development guidance is firmly grounded in, and aligned to, modern industry-recognised approaches and standards. Microsoft has done this without loosing the distinctive characteristics of MSF. In the earlier versions of MSF, the presentation of these characteristics could make MSF appear rather quirky, but that quirkiness is now a thing of the past.
I believe MSF represents a subtle change in Microsoft’s attitude. The promotion of MSF in conjunction with Visual Studio Team Services all but guarantees that the framework will become far more widely adopted and recognised over the next few years. In this respect, Microsoft possesses a confidence it lacked a decade ago in its ability to function as an industry leader in advocating best practice for consistent engineering of high quality code at all levels of professional and enterprise software development. Several years ago, the joke (I heard it first from a Microsoft MSF evangelist) was that if you wanted to know how to do software development properly, the last people you would think to approach would be Microsoft. Today, the reality is that they are amongst the first.
The true nature of MSF will, I suspect, continue to be widely misunderstood. One of its strengths is that, as a meta-model, it is designed to be mapped to a wide variety of existing methodologies. These include modern ‘agile’ methodologies like Scrum and XP, more formal methodologies such as RUP and DSDM and even project management methodologies such as Prince 2. Perhaps more importantly, MSF can be mapped onto existing ‘custom’ methodologies that organisations have evolved over time. In all these cases, it is generally quite easy, to identify the correspondence between the principles and guidelines offered by MSF, and the details of the various methodologies. There is, of course, a need to translate between different terms in MSF and the target methodology. Mapping MSF in this way can have benefits. It allows organisations to adopt a common language and understanding of process and practice that is not tied to any one explicit or detailed methodology. Organisations that collaborate with different customers in software development, or who undertake projects that vary significantly in their size, nature, toolsets, etc., can therefore promote best practice across the board, despite these variations. In these situations MSF illuminates both the strengths and weaknesses of existing methodologies, thereby supporting and promoting process improvement.
MSF can also be used as a meta-model when evolving new or custom methodologies from the ground up. The flexibility of MSF means that it can support a wide degree of variation in the implementation of methodologies whilst helping each one to remain rooted to a set of core principles and mindsets. This is the approach that Microsoft has taken with MSF 4.0 and Team Services. Team Foundation Server provides a customisable and configurable environment for hosting XML-defined methodology templates. The two MSF templates which will ship with the product offer different methodological approaches to software development. They will both, however, exploit the work item-based architecture of Team Foundation Server, and will both share a high degree of commonality because they are based on the same meta-model. They share a set of common terms and models, and express the same principles in the same language. However, they remain distinct. These two MSF 4.0 templates represent a new departure for Microsoft who has, for the first time, provided the industry with Microsoft-branded software development methodologies
Generic, but highly prescriptive, detailed methodologies are generally not well received within the industry. They represent top-heavy, one-size-fits-all, approaches that do not adequately encompass the specific requirements and culture of individual organisations and teams. However, as many organisations have discovered, building a development methodology from the ground up, complete with documented processes, best-practice, guidance and templates, and incorporating hooks into a variety of tools and systems is a very ambitious and costly undertaking. One answer to this dilemma is to adopt a ‘white label’ approach in which a reasonably detailed methodological framework is provided and integrated into an existing suite of development management tools, and then customised and extended as required in order to cater for the demands of a specific organisation. This is exactly the approach adopted by Team Foundation Server and Visual Studio Team Services, working in conjunction with the MSF 4.0 templates. Of course, other methodologies can just as easily be integrated into Team Foundation Server. Conchango will deliver a set of Scrum templates, Cognizant will deliver a version of FDD, Avenade will port their ACM (Avanade Connected Methods) to Team Services and Ossellus will deliver RUP templates. There are even the beginnings of an XP-like version of MSF (BSDAgile) on GotDotNet. However, because the MSF 4.0 templates will ship with Visual Studio Team Foundation Server, and thanks to MSF 4.0’s alignment with industry-recognised approaches, it is likely that many development shops will adopt one or both of the MSF 4.0 templates and customise them accordingly. In line with this expectation, BrightWork has announced companion SharePoint-based functionality to supplement MSF Agile, and Osellus will offer further integrated CMMI and MSF support into their Process Author tool which itself integrates with Team Services.
In an interesting development, Ivar Jacobson, who was one of the three original designers of UML (Unified Modelling Language), recently announced that his company will work with Microsoft on the development of an additional MSF-based methodology template for Visual Studio Team Services. This will map MSF onto a new version of Unified Process (the basic foundation of RUP). ‘Essential Unified Process'(EUP) will provide a lightweight alternative to RUP, and will be targeted, at least initially, at the .NET development community. It may prove that EUP is the first of several third-party MSF-based methodologies and mappings
MSF 4.0 for Agile Software Development
Agile development methods have increasingly taken central stage in the last few years. When MSF was first published, there were few truly agile methodologies, and ‘Rapid Application Development’ was considered by many to be a vacuous term used to excuse poor practice. MSF played a role in advocating many of the central and most valuable principles and practices of agile development, although it has not historically used that term.
The central characteristics of the agile approach are defined by statements of emphasis. According to the ‘Manifesto of Agile Software Development’, agile methods value…
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The manifesto is directly echoed in Microsoft’s description of MSF Agile contained within the template. This reads as follows:
“Choose the MSF for Agile Software Development process for projects with short lifecycles and results-oriented teams who can work without lots of intermediate documentation. This MSF process is a flexible guidance framework that helps create an adaptive system for software development. Agile methodology anticipates the need to adapt to change, and focuses on people as the most important component to the success of a project. Agile methodology also emphasizes the delivery of working software and promotes customer validation as key success measures.”
Agile methodologies advocate practices that include the direct involvement of customers and business users in the development team, an emphasis on rapid and highly iterative code releases and test-driven development, collaborative working practices and the fostering of shared responsibility and ownership. Agile software development expects and welcomes change and refinement to the requirements list, and manages this through close alliance with the business and by progressing through small, simple steps.
Perhaps the best known agile methodology is Extreme Programming (XP). Other methodologies include Scrum, Adaptive Software Development (ASD), Crystal and Feature-Driven Development (FDD). Other methodologies, such as DSDM, RUP and Unisys QuadCycle may exhibit or accommodate some of the principles of agile development. MSF has always had a strong emphasis on many of the core characteristics and principles of agile methodology, including highly collaborative teams, strong advocacy of business stakeholders and end-users, short iterative cycles of code release, testing throughout the project cycle, etc. MSF 4.0 has strengthened this correspondence, and any mapping between MSF 4.0 and a given methodology will highlight and encourage the use of agile principles within that methodology.
MSF 4.0 for Agile Software Development (MSF Agile) represents a version of MSF that de-emphasises formal project governance and emphasises agile principles within smaller collaborative teams. Consider, for example, the MSF Team Model which now has seven ‘constituencies’, rather the MSF 3.0’s six ‘role clusters’. The new ‘constituency’ is that of Architecture, bringing the team model into closer alignment with modern best practice. MSF Agile maps the seven constituencies onto just six roles, where each role represents collaborative team membership. In contrast, the current beta of MSF 4.0 for SEI CMMI Process Improvement maps the same team model onto seven major roles and a total of eighteen sub-roles, including roles that function at a wider project/programme governance level, such as sponsors, integrated project management (IPM) officers and auditors.
An important feature of MSF Agile concerns what used to be the MSF Process Model. MSF 3.0 described five phases within its process model, and five corresponding milestones. It extended this by suggesting, rather loosely, that the process model can be adapted to different levels of iteration project, interim code release, etc.). The terms ‘process model’, ‘phases’ and ‘milestones’ have been broadly replaced in MSF 4.0 with new terminology of ‘governance’, ‘tracks’ and ‘checkpoints’. A track encapsulates a set of work streams and activities (a work stream is a sequence of activities) which conclude in a governance checkpoint. Each checkpoint provides an opportunity to authorize continued work on the project or to cancel or suspend the project. A major change in MSF 4.0 is that tracks are not bound to a notion of sequential phases. Instead, MSF 4.0 has strengthened its view of iteration, introducing the terminology of ‘cycles’ which it carefully differentiates from governance. MSF 4.0 defines five cycles as Check-In, Daily Build, Accepted Build, Iteration and Project. MSF4CMMI extends this with the notion of the programme being a sixth cycle.
MSF 4.0 describes five tracks for project governance, each of which is associated with a checkpoint. These correspond broadly to the five phases and milestones in the old model. The list of five cycles is separate. Methodologies are free to draw their own associations between governance and sequence. One immediate benefit of this new approach is that it is far easier to communicate the concept (always present in MSF) that groups of activities and work streams may overlap to a greater or lesser degree. Historically, RUP has done a better job of communicating this principle in the context of a project-level process model.
In MSF4CMMI, the five tracks (Envision, Plan, Develop, Stabilise and Deploy) culminate in five familiar checkpoints (Vision/Scope Approved, Project Plans Approved, Scope Complete, Readiness Plans Approved and Deployment Complete). These provide the broad pattern for governance at the project and programme levels. MSF Agile describes the same five tracks, but the checkpoints are quite different. The long-standing MSF view of sequential phases at the project level has been entirely subjugated to the agile principle of fine-grained rapid iteration. Checkpoints are expressed principally as questions which are asked, not at the major boundaries of project phases, but continuously throughout the development effort, and at every level of iteration. Tracks can be highly parallel in MSF Agile, and the emphasis is on communication and feedback between the different tracks. The five governance checkpoints and related questions are:
- Objectives Reviewed – Will we meet the minimum acceptance level of functionality?
- Progress Assessed – Are we making the necessary progress to meet our deadline?
- Test Thresholds Evaluated – Are we maintaining an appropriate level of quality?
- Risks Identified and mitigated – Are we addressing project and technical risk?
- Deployment Ready – Have we designed and created a solution that is ready to deploy?
The dramatic break with the sequential ‘phase’ model of previous versions of MSF shows clearly that the complaint, already voiced on the web, that MSF Agile is really a form of ‘lightweight RUP’, and therefore not truly agile, is entirely mistaken. MSF Agile is very different to RUP, and is closely aligned to modern agile principles and practices. I am, of course, aware that many RUP practitioners report success in adapting RUP to the principles of agility.
Another complaint that has raised its head is that MSF Agile can’t be truly agile because it is bound to a toolset. Apparently, some people consider that the use of tools to manage process is fundamentally at odds with agility (I guess, according to this theory, true agility depends on Post-It notes). Conversely, it has been claimed that MSF Agile is not truly agile because the Team Services toolset does not force developers to adopt agile principles. Microsoft just can’t win!
A general distinction between MSF4CMMI and MSF Agile, recognised within Microsoft’s emerging guidance on method selection, is that MSF Agile is built firmly on the principle of trust and a reliance on the ability of individual team members (one good reason for not forcing them to adhere to process dictated by the toolset). MSF4CMMI is described as an “agile approach to CMMI” (more on this later) which introduces “additional formality, reviews, verification and audit”.
MSF 4.0 for CMMI Process Improvement
The Software Engineering Institute’s (SEI) Capability Maturity Model Integration (CMMI) is one of the industry’s best know and most widely adopted software development process improvement frameworks. Formally known as CMM, it is widely adopted in the US, but is less well known in the UK although, in its earlier forms, it had an impact on software quality standards such as TickIT, and was a major consideration in the development of the ISO/IEC 15504 (SPICE – Software Process Improvement and Capability dEtermination) standard. In turn, CMMI has been deeply influenced by the US/Japanese ‘quality movement’, building on the ideas of quality ‘gurus’ such as the late W. Edwards Deming. It is worth noting that, historically, this US/Japanese quality culture was very different to its UK counterpart. The well-known ISO 9000 family of standards originally evolved from a British standard (BS5750) which, it is said, was rooted in the need to improve safety and quality of ordnance production in the Second World War. ISO 9000 earned a poor reputation over many years for its advocacy of bureaucratic adherence to the notion of compliance. However, the family of standards was entirely re-written and re-launched in 2000, and now draws strongly from the same sources and influences as SEI CMMI, radically de-emphasising compliance to written procedures, and emphasising, instead, the establishment of a culture of continuous process improvement.
A CMM is described by the SEI as “a reference model of mature practices in a specified discipline, used to improve and appraise a group’s capability to perform that discipline”. SEI CMMI integrates four different CMMs which address the disciplines of Systems Engineering (SE), Software Engineering (SW), Integrated Product & Process Development (IPPD) and Supplier Sourcing (SS). MSF 4.0 maps directly to an integrated CMMI model that includes all four disciplines.
CMMI provides a model for assessing the maturity of an organisation’s process and, hence, determining its capability. CMMI offers two different ‘representations’. The ‘Continuous’ view represents a more flexible interpretation of CMMI in which organisations can pursue process improvement on a process-by-process basis. This means that some process areas may be very mature whilst others remain immature. This in turn makes assessment of process maturity at the organisational level very difficult or impossible. By contrast, the ‘Staged’ view advocates an approach to process improvement in which process maturity as assessed at the organisational level across multiple process areas. In this model, an organisation’s capabilities are determined against a scale of five levels, as follows:
- Level 1 – Initial: Process unpredictable, poorly controlled and reactive
- Level 2 – Defined: Process characterized for projects, and is often reactive
- Level 3 – Managed: Process characterized for the organization, and is proactive
- Level 4 – Quantitatively Managed: Process measured and controlled
- Level 5 – Optimizing: Focus on continuous process improvement
MSF 4.0 for SEI CMMI Process Improvement, as delivered, specifically targets levels 2 and 3 of the staged model, with the stated aim of accelerating the achievement of Level 3. The use of the staged, rather than the continuous, model is curious. It may be that Microsoft adopted this model because it represents the approach taken by the older SEI-CMM scheme, and remains the most widely used representation of CMMI.
Level 3 achievement may seem unambitious. However, many organisations still fall short of this maturity level, and level 3 is commonly stated as a minimum acceptable level when suppliers are assessed for suitability. MSF4CMMI provides some partial support for levels 4 and 5, and we are promised more in future versions. It should also be noted that support for levels 2 and 3 is not comprehensive. MSF4CMMI, as provided, could, of course, be extended manually to provide greater compliance.
It is very important to note that the adoption of MSF4CMMI does not preclude the use of agile methodology within the process cycle. On the contrary. Microsoft describes MSF4CMMI as an agile approach to CMMI. This is strongly underlined by comparing MSF4CMMI with MSF Agile. The two methodologies, each based on the same MSF meta-model, contain the same set of principles, ‘mindsets’ and guidelines. Indeed, MSF4CMMI will, when complete, offer a superset of the guidance provided by MSF Agile, setting that guidance within an overall context that caters for more formal project and programme governance and a formalised approach to process improvement. Contrary to common assumptions, MSF Agile and MSF4CMMI and not mutually exclusive opposites. Rather, there is a smooth transition path from MSF Agile to the greater formality of MSF4CMMI, with an emphasis in MSF4CMMI of fostering a culture of continuous process improvement – a concept that is hardly at odds with agility.
Comparing SEI CMMI and ISO 9001:2000
The SEI runs an appraisal scheme which is delivered through its partners. According to information on their web site, approximately 400 organisations worldwide have gained one or more CMMI appraisals since 2002, about 50% of which are in the US. The SEI appraisal scheme provides an assessment of an organisation’s, or projects team’s, capabilities. This is reminiscent of schemes such as ISO 9000. ISO 9001:2000 is not equivalent to CMMI, and is not targeted specifically to IT or software development. Because it can be applied to the widest range of disciplines, it can provide no equivalent level-based determination of an organisation’s capabilities or process maturity. Indeed, a wide degree of latitude is given to organisations to determine the scope of their certification. For example, in the ISO 9001:2000 scheme, an IT development and consulting company might decide to apply the standard only to it consulting services, rather than its development services. The chosen scope is clearly stated on the ISO 9001:2000 certificate. However, within the confines of an acceptable scope, ISO 9001:2000 does essentially establish a baseline for process maturity, and, in particular, it emphasises strongly the establishment of a cycle of continuous process improvement. Direct evidence of this must be provided to ISO 9000 auditors, and in this respect, the standard exhibits some similarity to the higher levels of SEI CMMI. Interestingly, SEI publishes a mapping of SEI CMMI to ISO 9001:2000 on their web site.
TickIT is a specialised ISO 9001:2000 scheme applied specifically to software development. It draws heavily on other ISO standards such as ISO/IEC 12207, and provides mappings to the now obsolete SEI CMM, and also to ISO/IEC 15504 (Spice). TickIT is a joint UK/Swedish scheme with just over 800 certificated organisations in the UK, and rather less than 300 further certificated organisations in other parts of the world. Again, TickIT is not a capability determination scheme. However, the achievement of TickIT certification broadly indicates a level of software development process maturity in line with the higher levels of SEI CMMI.
The impact of MSF 4.0
Any organisation thinking of adopting one or both of the new MSF 4.0 methodologies should first ask itself some searching questions. For many organisations, these will include the central question of whether a compelling business case can be made for evolving their software development process. If (as is generally the case) the answer is yes, then they should ask, as a secondary question, if there is a compelling business case for seeking some formal certification. In my opinion, no organisation should ever seek certification for its own sake (a tick in the box). They should only ever seek certification as part of a broader vision of process improvement and quality. An organisation is only truly ready to seek CMMI or TickIT certification when it commits to adoption of such a scheme regardless of achieving certification. You may consider that your process is mature enough to adequately meet the demands placed upon you, and that further evolution would not result in any significant added value. On the other hand, you may believe that a more mature process would result in higher quality, greater efficiency and reduced overheads of rework, etc, or would help to differentiate you further from your competition.
In adopting Team Foundation Server, organisations need to decide which methodologies, if any, they wish to adopt, and the extent to which they want to customise an existing methodology. As described above, as well as the two MSF templates from Microsoft, there are further templates under construction for other methodologies. Adopting the MSF approach has two obvious benefits; a) there are free templates which you could customise if you wish and b) the nature of MSF allows teams to choose between the two templates as appropriate for specific projects.
The customisation of one or more existing methodologies (e.g., the MSF methodologies) may prove an attractive option for several reasons. It can allow organisations to guard their existing investment in internal development of process, templates etc, and provide a relatively inexpensive approach to exploiting that investment within a set of modern, agile, methodologies. The selection of the MSF methodologies makes it easier to adopt a formal scheme at a later date, if desired. Perhaps the most important benefit, though, is the underlying advocacy of the culture of continuous process improvement. We will always have room to improve, and will always have new challenges to meet. MSF 4.0 and Visual Studio Team Services provide a framework that will allow our process to mature in step with the dynamics of our industry and our business.
