Milen Petrov Griffin Ltd. MSF 4.0 in 60-minutes Session Abstract It is exciting times for Microsoft Solutions Framework (MSF). With the Visual Studio team adopting MSF and creating Visual Studio 2005 Team System (VSTS), MSF now has an enhanced foundation (i.e., code-named MSFv4 Core) plus MSF is now embedded within VSTS enabling process automation and guidance. This creates an opportunity to mature solution delivery capabilities throughout the market. Not only does VSTS/MSFv4 extend MSFv3, but it also introduces two specializations: MSF for Agile Software Development and MSF for CMMI Process Improvement. This session will share with you an overview of MSFv4 Core and MSF Agile. Milen Petrov Griffin Ltd.

MSF for Agile Software Development Extending VSTS Templates Q&A Agenda Motivation Where MSF fits in SDLC What’s New in MSF v4.0 MSF for Agile Software Development Extending VSTS Templates Q&A The goal of this presentation is to quickly acclimate you with the various pieces and parts of MSF and how they relate to each other. MSF, the course offering, has grown to much more than courseware. It is not very integrated into the tooling provided by Visual Studio. You will have a lot to learn… hopefully this presentation will help you get started. Goal: A quick fly-by of what’s new… so that you can explore the details at a later time.

MSF for Agile Software Development Extending VSTS Templates Q&A Agenda Motivation Where MSF fits in SDLC What’s New in MSF v4.0 MSF for Agile Software Development Extending VSTS Templates Q&A Main message of this section: What problem is MSF v4.0 trying to solve?

A Brief History MSF Offering 1994 1995 1997 1999 2002 2005-06 21 Rules “Dynamics” Solutions Dev Discipline (SDD) MSF v2 Principles of … App Dev (PAD) Infra Deploy (PID) Ent Arch (PEA) Comp Des (PCD) MSF v2.5 MSF v3 Essentials + Exam Core Agile CMMI … MSF v4 MSF Offering MSF v1 MSF was born out of a movement to capture and share best practices in the industry of software engineering. That mission has not changed. What has changed is the scope and impact of MSF. MSF v4.0 specifically is a very important transition from pure “framework”, to “framework” and “methodology”. MSF v4.0 “the framework” can apply to just about any methodology, including SCRUM, RUP, etc. However MSF v4.0 specifically calls attention to two very important methodologies, arguably at opposite ends of the formality spectrum, “Agile” and “CMMI”. 1994 1995 1997 1999 2002 2005-06

Why Can’t Process Help Productivity? Framework Methodology Complete Sufficient Rules Guidelines MSF v4.0’s focus area is to address a critical problem: The seeming conflict between process discipline and productivity. Productive Predictable Repeatable

Process & Tools Integration enacts Visual Studio 2005 Team System Microsoft Solutions Framework guides How VSTS enables MSF? Productivity tools & processes Integrated tools & processes Extensible tools & processes So what type of architecture is needed to join Productivity with Process Discipine? MSF is the guidance infrastructure. Visual Studio is the tooling infrastructure.

MSF for Agile Software Development Extending VSTS Templates Q&A Agenda Motivation Where MSF fits in SDLC What’s New in MSF v4.0 MSF for Agile Software Development Extending VSTS Templates Q&A Main message of this section: How does MSF the “framework” fit with Visual Studio the “tooling”.

Framework Methodology MSFv4 Family Tree Framework MSFv4 Core Discipline Application Development Infrastructure Family MSF for Agile Software Development MSF for CMMI® Process Improvement MSF v4 has three major components: MSFv4 “Core” MSF for Agile Software Development MSF for CMMI Process Improvement. Product (instantiated) Methodology

Content Relationship MSF v4 CMMI Infrastructure Agile MSF v3 MSFv4 “Core” Discipline Application Development Infrastructure Family MSF for Agile Software Development MSF for CMMI® Process Improvement Product MSF v4 CMMI Infrastructure Build Slide Build 0: Application Development MSF v4 is an expansion of MSF v3, as well as the more detailed application of MSF to two methodologies, Agile and CMMI. “Agile” is a methodology you would choose when you want to be “light weight” in methodology. This is appropriate for smaller and less complex projects. “CMMI” is a methodology you would choose when you are more “formal” in methodology. CMMI supports the most complex projects, from both a social and engineering perspective. Build 1: Infrastructure The principles of MSF can also be used for non-application development types of projects, such as Infrastructure projects. MSF 4.0 lays the foundation for a more explicit inclusion in this area. No doubt an MSF v5.0 investment area… Agile MSF v3

Continuum of Methodologies Note: MSF is not specifically “competition” with any specific methodology or tooling. This is a frequent point of confusion. This Giga Research chart exemplifies this very well, calling “MSDN” a methodology. In addition to Microsoft releasing two implementations of MSF, Agile and CMMI, other companies are releasing implementations of XP, Scrum, even RUP.

MSF for Agile Software Development Extending VSTS Templates Q&A Agenda Motivation Where MSF fits in SDLC What’s New in MSF v4.0 MSF for Agile Software Development Extending VSTS Templates Q&A Main message of this section: Changes to MSF v4.0, the “guidance” portion of MSF

What is MSFv4? A set of foundational principles, mindsets and proven practices with an adaptable framework for successfully delivering solutions faster, requiring fewer people, and involving less risk, while enabling higher quality results. Models Team Model Governance Model MSF 3.0’s organization as a collection of principles, proven practices, etc. is successful. MSF 4.0 continues with this organization of models, expanding in some areas, refining in others. Disciplines Project Management Discipline Risk Management Discipline Readiness Management Discipline

Principles Mindsets Proven Practices Key Concepts  Mindsets Fundamentals Principles Mindsets Key Concepts  Mindsets Proven Practices MSF 4.0 makes a subtle shift in fundamentals. MSF V3 Principles Foster open communications Work toward a shared vision Empower team members Establish clear accountability and shared responsibility Focus on delivering business value Stay agile, expect change Invest in quality Learn from all experiences MSF V4 Principles Partner with customers Quality is everyone’s business, every day Stay agile, adapt to change Make deployment a habit Flow of value Mindsets Qualify id defined by customer Pride of workmanship Team of peers Frequent delivery Willingness to learn Get specific early Qualities of service Citizenship

Requirements Prioritization Planning Risk Analysis Scheduling Process Stakeholder Analysis Readiness Management Requirements Prioritization Simple Kano Analysis MSF has refined governance activities. Requirements Prioritization is an important addition.

Team Model Advocacy Groupings New: Architecture Release Operations Was: Role Clusters New: Architecture Responsibilities pulled from Proj Mgmt and Dev Release Operations Was: Release Mgmt More functional areas in each advocacy group The team model remains conceptually the same – it is a team of peers, not an organizational hierarchy. However in order to even more explicitly widen the gap between “principle” and “org-chart”, what was formerly “role clusters” is now called “advocacys”. A new advocacy has been added: Architecture. It was formerly represented primarily by Program Management and Development.

Governance Capacity Governance Capacity Governance Model Which projects should we do? Which features? How much capacity to allocate? How is value delivered? Capacity Enactment Measurable productivity Manageable delivery How to improve? Governance Capacity The concept of “Governance” has been wrapped around the capacity to deliver projects. This is very important: Governance is a process – something that is ongoing and never ends Solution delivery is a project – with an explicit beginning and end Activities that occur to support governance include determining exactly when the project will start, and what it will do. Once the project starts, the efficiency of the project team drives the delivery capacity of an organization. The more productive they are, the more capacity an organization has, and the more projects they can accomplish per unit cost.

Process Model Deploy Envision Release 1 Stabilize Plan Build Phases  Tracks Develop Track  Build Track Milestones  Checkpoints Deploy Envision Release 1 Stabilize The process model has been “fuzzified” – to draw particular attention to the notion that this is a “model”, not a “project plan”. Milestones, a project plan concept, have been renamed to “checkpoints”. Plan Build

Minimize risks by breaking large projects into multiple versions Iterative Approach Minimize risks by breaking large projects into multiple versions Risk Solution Completion Knowledge The concept of a “rhythm of development” is more explicit. Some rhythms are “in the project”, others are at the “program” level. Time

MSF Envision Track Envision Deliverables Goals Vision/scope document Project structure document Initial risk assessment document Core Team Organized Envision Vision/Scope Baselined Vision/Scope Approved The Envisioning track conceptually is unchanged – it has been clarified with more explicit descriptions of deliverables and goals. Goals Develop a clear understanding of what is needed within context of project constraints Assemble necessary team to envisage solution with options and approaches that best meet those needs while optimally satisfying those constraints

MSF Plan Track Deliverables Plan Goal Functional specifications Master project plan Master project schedule Technology Validation Complete Functional Specification Baselined Plan Master Project Plan Baselined Master Project Schedule Baselined Supporting Environments Set Up Project Plans Approved The Planning track is conceptually the same. Goal Evolve conceptual solution into tangible designs and plans so it can be build in the developing track Find out as much information as possible, as early as possible Know when you have enough information to move forward

MSF Build Track Deliverables Build Goal Completed Solution Training materials Documentation Marketing materials Updated master plan, schedule and risk document Scope Complete Proof of Concept Complete Build Internal Release 1 Internal Release 2 Internal Release n Goal Build various aspects of the solution in accordance with plan track deliverables (e.g., designs, plans, requirements) Develop solution features and components, complete deliverables and other elements of the solution Test the various aspects of the solution to assess the state of quality of the solution The Build track, formerly the “Develop” phase, is conceptually the same. However it now more explicitly includes activities that occur outside of the “developer” role. Such as marketing, training, etc.

Testing is not just for testers Testing the Solution Goal Expose issues, uncover design flaws and identify unexpected behavior Role of testing: Proactive: Leads build effort (e.g., test-driven development) Supportive: Follows build effort (e.g., design a little, build a little, test a little) Testing is not just for testers Can be performed by anyone helping improve the completeness and/or quality of work item deliverables Testing is an important area. In fact some methodologies call for “Test Driven Development”, and important part of the Agile process. Two distinct roles are called out: Proactive and Supportive.

Deliverables Goals MSF Stabilize Track Pilot review Release Readiness Approved Deliverables Pilot review Release-ready versions of solution and accompanying collateral Testing and bug reports Project documents Release Candidate n Pilot Complete User Acceptance Testing Complete Release Candidate 1 Pre-Production Testing Complete System Testing Complete Stabilize nth Functional Testing Pass Complete Issue Log Cleared User Interface Stabilized Issue Convergence Goals Improve solution quality to meet release criteria for deployment to production Validate solution meets stakeholder needs and expectations Validate solution usability from a user perspective Maximize success and minimize risks associated with solution deployment and operations in its target environment(s) 1st Functional Testing Pass Complete The Stabilize track moves away from a focus on “test” and more towards a focus on “convergence”. As one program manager at Microsoft likes to say, “Software doesn’t release… it escapes!” Stabilization strives to create the conditions which allow the solution to escape into production.

MSF Deploy Track Deliverables Deploy Goals Operations and support information systems Revised processes and procedures Repository of all solution collateral Deployment Stabilized Site Deployments Complete Deployment Complete Core Solution Components Deployed Deploy Goals Place solution into production at designated environment(s) Facilitate smooth transfer of solution from project team to operations team as soon as possible The Deployment track, added in MSF 3.0, is conceptually the same.

Governance Track Repackaged Deliverables Goals Status reports Customer/user satisfaction data Final versions of all project documents Project closeout report Customer Acceptance Operations Acceptance User Acceptance Goals Secure approval from: Users that the solution meets their needs and is sufficiently usable Operations that the solution is ready to deploy Customer that the project is complete Optimize and continuously improve team performance and throughput, solution quality and process improvement Wrapping the entire “Project” is a Governance “Process”, which is a critical mechanism which allows new projects to start, and more importantly, existing projects to reschedule functionality into a future release.

MSF for Agile Software Development Extending VSTS Templates Q&A Agenda Motivation Where MSF fits in SDLC What’s New in MSF v4.0 MSF for Agile Software Development Extending VSTS Templates Q&A Main message of this section: Agile is a methodology that has tooling support in Visual Studio.

Individuals and interactions over processes and tools Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Agile is a grass-roots movement to improving the discipline of software engineering. These are the core tenets. Choose Agile when formality is not critcial.

Time Box = Time limit in which to complete an iteration Time-Boxed Iteration Time Box = Time limit in which to complete an iteration How Reduce functionality Reschedule features Agile prioritizes schedule over features. Each iteration adds incremental features.

Personas On-site Customer Persona Actor “Personas” are an important concept that have been used in Microsoft for quite some time. They are a compromise between the overly formal Use Case Modeling, and the overly informal Extreme Programming customer involvement. Actor

Scenarios Working Software Scenarios Personas Review Refine Agile software development is a scenario-driven software development process. A scenario records a single path of a persona interaction through the system in order to reach a goal. Real Customers

The Agile Pattern Scenario 1 Scenario 2 Scenario 3 Scenario 4 Iteration 1 Scenario List Scenario 1 Scenario 2 In MSF Agile – a scenario is a major work item. Each iteration of development implements a specific list of scenarios to some degree of functionality. Scenario 3 Iteration Plan

Requirements Prioritization (Kano Model) Minimum Acceptance Level Description Developed in the 80's by Professor Noriaki Kano, the model is based on the concepts of customer quality and provides a simple ranking scheme which distinguishes between essential and differentiating attributes. The model is a powerful way of visualising product characteristics and stimulating debate within the design team. Kano also produced a rigorous methodology for mapping consumer responses onto the model. Product characteristics can be classified as: Threshold / Basic attributes Attributes which must be present in order for the product to be successful, can be viewed as a 'price of entry'. However, the customer will remain neutral towards the product even with improved execution of these aspects. One dimensional attributes (Performance / Linear) These characteristics are directly correlated to customer satisfaction. Increased functionality or quality of execution will result in increased customer satisfaction. Conversely, decreased functionality results in greater dissatisfaction. Product price is often related to these attributes. Attractive attributes (Exciters / Delighters) Customers get great satisfaction from a feature - and are willing to pay a price premium. However, satisfaction will not decrease (below neutral) if the product lacks the feature. These features are often unexpected by customers and they can be difficult to establish as needs up front. Sometimes called unknown or latent needs. Product differentiation can either be gained by a high level of execution of the linear attributes or the inclusion of one or more 'delighter' features. But, it should be remembered that customer expectations change over time, and a cup holder in a car may be today's delighter, but tomorrow it will be expected. Some users of Kano also suggest that an additional set of attributes can be classified as 'enragers' - features which enrage either through their absence or inclusion. Iteration 3 Iteration 2 Iteration 1

Visual Studio Team System Visual Studio Team System implements MSF Agile by providing the constructs for “Scenarios” and other Agile work items. The Team Explorer enables you to manage the work items associated with the project.

Using VSTS Agile : Team Explorer Window After an Agile Team Project is created, the menu allow you to add the various work items. Bug Task Scenario QOS Requirement

Using VSTS Agile : Sample Report Tracking the aggregate status of scenarios enables you to take a measure of the health of your project (if it is converging), and forecast how much work remains.

MSF for Agile Software Development Extending VSTS Templates Q&A Agenda Motivation Where MSF fits in SDLC What’s New in MSF v4.0 MSF for Agile Software Development Extending VSTS Templates Q&A Main message of this section: You can customize the methodology templates that ship with Visual Studio Team System, or build your own.

VSTS Template Key Concepts Role Work Item States and Transitions Fields Process Guidance Work Streams Groups of activities that flow logically together Often associated with a particular role Activities Described using EVTX format These are the building blocks of a VSTS template. Role Work Item Process Guidance

Project Manager Business Analyst Architect Developer Tester MSF Agile Roles Project Manager Business Analyst Architect Developer Tester Release Manager For example, Agile defines the following roles. The diagram on the right show the relationship of the roles to their advocacy groups.

MSF Agile Workstreams Capture Product Vision Create a Scenario Create a Quality of Service Requirement Plan an Iteration Create Solution Architecture Implement a Development Task Build a Product Test a Scenario Test a Quality of Service Requirement Fix a Bug Close a Bug Release a Product Guide Project Examples of Workstreams. These workstreams are for MSF Agile.

MSF Agile “Scenario” : States & Transitions Active Resolved Closed Transitions Completed Test Failed Reactivated Split etc. Example of a Work Item, which contains States and Transitions. This example shows the MSF Agile “Scenario” work item.

MSF Agile “Scenario” : Fields Work Items also have Fields. Some of MSF Agile “Scenario” fields are listed here.

MSF Agile “Scenario” : Activities Business Analyst Develop lifestyle snapshot Brainstorm scenarios Project Manager Divide scenarios into tasks Developer Integrate code changes Tester Write validation tests Select and run a test case The state that a work item is in defines which activities can occur, and who can perform the activity.

MSF Agile “Scenario” : Workstreams Role: Developer Workstream: Fix a Bug This activity affects the Scenario work item. From a role’s perspective, a workstream is a series of activities that accomplish a particular goal.

Process Template Manager Work items Work item instances Reports Security groups Project portal Documents / templates Source control settings Process guidance content Iteration structure Entry criteria and exit criteria views Source check-in policies The VSTS Process Template Manager allows you to Export and Import templates. This is the mechanism you would use to customize a process.

MSF for Agile Software Development Extending VSTS Templates Q&A Agenda Motivation Where MSF fits in SDLC What’s New in MSF v4.0 MSF for Agile Software Development Extending VSTS Templates Q&A

Recommended book for learning more about MSF for Agile Software Development.

Stay Active In Your Local .NET Community!! MSF Home Page For More Information Stay Active In Your Local .NET Community!! MSF Home Page http://www.microsoft.com/msf Randy Miller’s Blog (Agile) http://blogs.msdn.com/randymiller Rob Caron’s Blog (VSTS) http://blogs.msdn.com/robcaron/ SCRUM http://www.controlchaos.com/about/ VSTS plug-in available from Conchango Capability Maturity Model Integration (CMMI) http://www.sei.cmu.edu/cmmi/ Microsoft Services QuickPlan for Team-Based Software Development