Although the fundamentals have mostly remained the same, Microsoft is refreshing MSF to clarify and adapt terms and concepts to be more understandable to a broader, global audience. Key changes, additions, clarifications, and enhancements to MSF v3 are highlighted in the following section. Please note that these concepts are discussed in detail in subsequent chapters.
Key changes to MSF v3 that are implemented in MSF v4 have been in the following areas:
A few miscellaneous changes are also highlighted.
The following summary maps the principles currently found in MSF v4 to those currently in MSF for Agile Software Development and MSF for CMMI Process Improvement as well as in MSF v3. In some instances, a couple principles have been merged or recast as a key concept (now called mindsets).
MSF v4 Principle | Agile and CMMI (v1) | MSF v3 |
---|---|---|
Foster open communications | Same | Same |
Work toward a shared vision | Same | Same |
Stay agile, expect and adapt to change | Stay agile, adapt to change | Stay agile, expect change |
Invest in quality | Quality is everyone’s business, every day (This applies to an individual’s behavior and is therefore a mindset—merged into pride in workmanship mindset.) | Same |
Partner with customers | Same | New |
Deliver incremental value | Flow of value: incremental delivery of value Make deployment a habit: implies team readiness Frequent delivery | Always create shippable solutions: implies solution readiness |
Make mindset | Focus on business value: make sure what is being delivered has value (This applies to an individual’s behavior and is therefore a mindset.) | |
New | Same | |
Establish clear accountability and shared responsibility | New | Same |
Learn from all experiences | New | Same |
Key concepts have been renamed as mindsets, but they are still key concepts. To help clarify the difference between a principle and a key concept, and especially because these concepts apply to individual behavior, calling them mindsets seems to represent better that understanding. As with the prior table, the following summary maps the mindsets in MSF v4 to those currently found in MSF for Agile Software Development and MSF for CMMI Process Improvement as well as in MSF v3.
MSF v4 Mindset | Agile and CMMI (v1) | MSF v3 |
---|---|---|
Foster a team of peers | Same | Extended to include trust. Trust is essential for many of the aspects of MSF to work properly. |
Focus on business value | Quality is defined by customer: "Everyone on the team should be...focused on delivering something that the consumers need, want, and will derive value from." | Transferred from principles and merged with: Customer-focused |
Keep a solution perspective | New | Solution mindset |
Take pride in workmanship | Pride of workmanship Quality is everyone’s business, every day (transferred from principles) | Quality mindset Zero-defect mindset |
Learn continuously | Willingness to learn | Willingness to learn |
(Merged into deliver incremental value principle) | Frequent delivery | |
(Moved to proven practices) | Get specific early | |
Internalize qualities of service | Qualities of service | Design principles, but there needs to be more awareness so it needs to be internalized—too often considered after design is done |
Same | New | |
Deliver on your commitments | New | Fixed ship date: Stimulate creativity by removing the option of moving the ship date |
A very welcome change is that role clusters remain. To help emphasize that the Team Model has always been about advocating for different aspects of delivering a solution and for their respective stakeholders, role clusters were renamed to advocacy groups.
As we reexamined the model, it made sense to make the most significant change to MSF Team Model, namely, adding an Architecture Advocacy Group. This group should seem familiar because most of the relevant aspects of this group were extracted from the Program Management Advocacy Group and the Development Advocacy Group.
The Release Management Role Cluster was renamed to Release/Operations Advocacy Group. This change was made to emphasize the critical need for the solution delivery team to be closely coupled with the Solution Operations team. Because not all solutions are deployed to an operations environment, the term release was retained in the name.
As part of reexamining the Team Model, we clarified and expanded the functional areas within each advocacy group. Added to this, we clarified, distilled, and expanded some of the key responsibilities and activities of each of the functional areas.
The MSF v3 Process Model underwent the most change. Although the underlying concepts have remained the same, it made sense to separate the process and activities of building a solution (i.e., enactment) from the process and activities of running a project (i.e., governance). As such, Process Model was renamed Governance Model.
Other changes were made to help emphasize the agile, overlapping, and iterative nature of MSF v3. Namely, the five phases are now call tracks (e.g., Plan Track)—as in tracks of activity. To emphasize that MSF v3 has always had a broader applicability to more than just the software development domain, the Developing Phase was renamed Build Track. Although the term milestone is commonly used in project management circles, to emphasize the agile nature of MSF v3, the term checkpoints is used instead. The Governance Model still has major and interim checkpoints.
The Process Model was changed somewhat to better emphasize the iterative name of MSF v3. For instance, some clarity was added about decomposing the major tracks of activity into work streams and further still into swim lanes.
A few miscellaneous but important changes are as follows. The term defects has been replaced with issues—a term more fitting our litigious society. To emphasize the applicability of MSF v3 beyond software development, the term bug has also been replaced by issue. Accordingly, the two bug-related interim checkpoints have been renamed. The Zero Bug Bounce checkpoint has been renamed Issue Log Cleared. The Bug Convergence checkpoint has been renamed Issue Convergence. In the Build Track (formerly called the Developing Phase), the Proof of Concept Completed interim checkpoint was renamed Prototyping Completed to better reflect that not all projects include a proof of concept; however, most do include prototyping efforts.
A few key elements have been added to MSF v4 that often build off of or clarify a topic lightly covered in MSF v3, namely, the following:
Although not new for the project management community, an approach to scheduling that reflects the MSF principles and mindsets has been added into MSF v4. The real value of this section is the numerous lessons learned that accompany the explanation of this process.
Although not a common practice in the project management community, it is a practical addition to MSF v4. It enables more options for a cost-conscious approach to risk mitigation.
MSF continues to be a strong proponent of empowering team members. However, not all team members are ready or able to be empowered. Empowerment readiness is a means added into MSF v4 to assess the degree to which each team member is ready to be empowered to perform a given task.
Many aspects of MSF v3 have been clarified and/or extended. A few key aspects of note include these:
Readiness Management Discipline and Process
Risk Management Discipline and Process
More projects plans for Master Project Plan
Supporting environments: more than just development and test environments
Stakeholder analysis
Defining high-level requirements
Decomposing and refining requirements
Added qualities of service (QoS) requirements
Acceptance criteria: user, operations, and customer
Clarified differences between conceptual, logical, and physical designs efforts
Types of testing: regression, functional, usability, system
18.118.31.67