Home » Process

MSF Agile at a Glance

18 August 2008 4 Comments

I like to be able to scan process methodologies so I create skeletal views that let me quickly see the key activities, artifacts, principles, and practices of a methodology.  MSF for Agile Software Development is a scenario-driven, context-based, agile software development process.   Here’s my notes on MSF Agile circa 2005, which might be somewhat dated, but at least give me a quick lens into the main ideas:

Principles

  • Partner with customers
  • Foster open communications
  • Work toward a shared vision
  • Quality is everyone’s job every day
  • Stay agile, adapt to change
  • Make deployment a habit
  • Flow of value

Mindsets

  • Quality Is Defined By Customer
  • Pride of Workmanship
  • Team of Peers
  • Frequent Delivery
  • Willingness to Learn
  • Get Specific Early
  • Qualities of Service
  • Citizenship

Workstreams

  • Capture Project Vision
  • Create a Quality of Service Requirement
  • Create a Scenario
  • Guide Project
  • Plan an Iteration
    Guide Iteration
  • Create a Solution Architecture
  • Build a Product
  • Fix a Bug
  • Implement a Development Task
  • Close a Bug
  • Test a Quality of Service Requirement
  • Test a Scenario
  • Release a Product

Activities By Workstream

Capture Project Vision

  • Write Vision Statement
  • Define Personas
  • Refine Personas

Create a Quality of Service Requirement

  • Brainstorm quality of Service Requirements
  • Develop Lifestyle Snapshot
  • Prioritize Quality of Service Requirements List
  • Write Quality of Service Requirements
  • Identify Security Objectives

Create a Scenario

  • Brainstorm Scenarios
  • Develop Lifestyle Snapshot
  • Prioritize Scenario List
  • Write Scenario Description
  • Storyboard a Scenario

Guide Project

  • Review Objectives
  • Assess Progress
  • Evaluate Test Metric Thresholds
  • Triage Bugs
  • Identify Risk

Plan an Iteration

  • Determine Iteration Length
  • Estimate Scenario
  • Estimate Quality of Service Requirements
  • Schedule Scenario
  • Schedule Quality of Service Requirement
  • Schedule bug Fixing Allotment
  • Divide Scenarios into Tasks
  • Divide Quality of Service Requirements into Tasks

Guide Iteration

  • Monitor Iteration
  • Mitigate a Risk
  • Conduct Retrospectives

Create a Solution Architecture

  • Partition the System
  • Determine Interfaces
  • Develop Threat Model
  • Develop Performance Model
  • Create Architectural Prototype
  • Create Infrastructure Architecture

Build a Product

  • Start a Build
  • Verify a Build
  • Fix a Build
  • Accept Build

Fix a Bug

  • Reproduce the Bug
  • Locate the Cause of a Bug
  • Reassign a Bug
  • Decide on a Bug Fix Strategy
  • Code the Fix for a Bug
  • Create or Update a Unit Test
  • Perform a Unit Test
  • Refactor Code; Review Code

Implement a Development Task

  • Cost a Development Task
  • Create or Update a Unit Test
  • Write Code for a Development Task
  • Perform Code Analysis
  • Perform a Unit Test
  • Refactor Code
  • Review Code
  • Integrate Code Changes

Close a Bug

  • Verify a Fix
  • Close the Bug

Test a Quality of Service Requirement

  • Define Test Approach
  • Write Performance Tests
  • Write Security Tests
  • Write Stress Tests
  • Write Load Tests
  • Select and Run a Test Case
  • Open a Bug
  • Conduct Exploratory Testing

Test a Scenario

  • Define Test Approach
  • Write Validation Tests
  • Select and Run a Test Case
  • Open a Bug
  • Conduct Exploratory Testing

Release a Product

  • Execute a Release Plan
  • Validate a Release
  • Create Release Notes
  • Deploy the Product

Artifacts (Work Products)

  • Vision Statement
  • System Architecture (See DSI and Whitehorse)
  • Test Plan (see Context-Driven Testing)
  • Personas
  • Scenarios
  • Storyboards
  • Development Tasks
  • Interface Models
  • Architectural Prototypes
  • Unit Tests
  • Classes
  • Change Sets
  • Check In Notes
  • Test Cases
  • Bug Reports

Disciplines

  • Requirements
  • Planning
  • Architecture
  • Development
  • Test

Who Does What

Business Analyst

  • Capture Project Vision
  • Create a Quality of Service Requirement
  • Create a Scenario

Project Manager

  • Guide Project
  • Plan an Iteration
  • Guide Iteration

Architect

  • Create a Solution Architecture

Developer

  • Build a Product
  • Fix a Bug
  • Implement a Development Task

Tester

  • Close a Bug
  • Test a Quality of Service Requirement
  • Test a Scenario

Release Manager

  • Release a Product

Cycles and Iterations

  • Product definition, development, and testing occur in overlapping iterations resulting in incremental completion of the project.
  • Different iterations have different focus as the project approaches release.
  • Small iterations allow you to reduce the margin of error in your estimates and provide fast feedback about the accuracy of your project plans.
  • Each iteration should result in a stable portion of the overall system.

Iterations

Iteration 0

  • Project Setup
  • Plan

Iteration 1

  • Plan
  • Develop and test
  • Feedback

Repeat as needed

  • Plan
  • Develop and test
  • Feedback

Iteration N

  • Develop and test
  • Release product

Team Model

Advocacy Groups

  • Architecture.
  • Development
  • Product Management
  • Program Management
  • Release Management
  • Test
  • User Experience

Who Advocates What

  • Architecture – advocates for the System in the Large.
  • Development – advocates for the Technical Solution.
  • Product Management – advocates for the Customer Business.
  • Program Management – advocates for Solution Delivery.
  • Release Management – advocates for the smooth delivery and deployment of the solution into the appropriate infrastructure.
  • Test - advocates for Solution Quality from the Customer Perspective.
  • User Experience – advocates for the most effective solution in the eyes of the intended users

Team Principles

  • Team of Peers.  A team of peers with clear accountability, shared responsibility and open communications. Each role is accountable for a specific share of the quality of the overall solution.
  • Advocacy for All Key Constituencies.  Advocacy for all key constituencies who must be represented on a successful software project. Every perspective is represented to provide the checks and balances that prevent errors of omission and lopsided decisions.
  • Stretch to Fit.  Stretch to fit to the scale necessary for the specific project. Constituencies may be combined in small teams or further refined as teams scale for larger projects.

Governance

Concerns the control of time and money relative to the flow of value:

  • Are we doing the right thing?
  • Can we do it within time and budget?
  • Are we ready to integrate?
  • Are we ready to deploy?
  • Are we realizing the value?

Additional Resources

My Related Posts

4 Comments »

  • Sue Massey said:

    I found your blog on google and read a few of your other posts. I just added you to my Google News Reader. Keep up the good work. Look forward to reading more from you in the future.

  • Microsoft Solution Framework (MSF) at a Glance said:

    [...] technology solutions to their customers.  Note that this MSF is not the same as the MSF Agile process included in VSTS.  I like to be able to scan process methodologies.  To do so, I [...]

  • Extreme Programming (XP) at a Glance said:

    [...] MSF Agile at a Glance [...]

  • J.D. Meier's Blog : Software Methodologies at a Glance said:

    [...] MSF Agile at a Glance [...]