There are a couple of variations on agile development methodologies in use in the groups that develop applications for Microsoft.com. Most groups utilize the old traditional Waterfall approach, which can be summarized as:

1. Initiate the project -- Sell the basic idea of what the project will be about to management & other stakeholders. Get funding and set a very high level projection on project timeline.
2. Plan  -- Gather requirements, produce a vision/scope document (also known as business requirements document) that lays out the goals and objectives of the project. Key components of the planning phase are a description of the business value being returned by the project and associated metrics.
3. Design -- A functional specification is created, which covers, in detail, the functionality that the application will have. A separate technical design specification is also created, which describes how Development plans on implementing that functionality.
4. Build -- The Development team turns the technical design spec into actual code.
5. Stabilize -- The Test team verifies that the code built matches the specification.
6. Deployment -- The Release Management and Operations teams put the app into production.
7. Production -- The Operations team maintains the application and customers use it.

Another common approach is essentially what is included in MSF for Agile Development. It's an iterative process in which several mini build/stabilize cycles ("iterations") take place inside of the Build phase. The functional spec starts out as a kind of skeleton and is fleshed out and updated at the conclusion of each iteration, with the PM often working on adding the work from iteration 3 into the spec at the same time Dev & Test are working on iteration 4. At the end of each iteration, a review meeting takes place with stakeholders at which the progress is reviewed, and any changes / updates in requirements addressed before the next iteration.

Both Waterfall and Agile work well for applications on microsoft.com because they have a high degree of predictability. Since many of our applications run in shared environments (www.microsoft.com, for example, has literally hundreds of applications on, or associated with it), operational, security, and architectural reviews are critical. If these are not planned for in the development methodology, then they can only be done at the end -- which may be too late to avoid having to introduce design changes that may require additional iterations before the application is ready for deployment to the operational environment. To track progress, and help monitor compliance and accountability, the Release Management and Operations teams collaborated on release checklists -- one is created for each project, and the RM tracks the progress and agreements in the appropriate checklist. We also developed Microsoft Project templates that include the checklist items and other basic high level work breakdown structures to assist the Program Managers in planning and tracking the effort and schedules for their projects.

There is another agile development methodology that some teams in microsoft.com have started to use, called SCRUM. SCRUM is very different from either Waterfall or other agile methods, since it is very dependent on dedicated and co-located resources. I'll go into more detail on how we do SCRUM in a future post, but the main points are:

• No functional spec -- instead, a queue of "User Stories" are worked through
• Instead of iterations, there are planned 30 day long "sprints".
• At the end of each sprint, a full-day sprint review meeting is held, at which the results of the sprint are analyzed, and a high-level plan for the next sprint, including which user stories will be worked, is done.
• Every morning, the team comes togther for a face-to-face meeting, in which the plan for the day is set.

SCRUM only works for projects where the entire development team is located in the same place -- in fact, industry SCRUM resources suggest a "bullpen" approach, where all are literally in one big room.

The other interesting thing about SCRUM is that you do not know in advance where the project is going to end up -- which can make architectural reviews, capacity planning, and other tasks very difficult for applications that will be deployed to operational environments (as opposed to, say, information worker applications on desktops). To work around this, we did create a checklist that ensures that operational and security needs are included in SCRUM projects. It's included in the download mentioned earlier.