different processes depending on iteration

As I understand it, you define what an iteration is. For some, an iteration may be a fixed unit of time, such as a week, or a month. For others, the iteration may be defined by some abstract unit of time, such as a particular release goal (alpha, beta, final, etc.). Or, it could be both. For example, in Scrum, an iteration is called a sprint and lasts 30 days.

As noted in MSF for CMMI Process Improvement, "Small iterations allow you to reduce the margin of error in your estimates and provide fast feedback about the accuracy of your project plans." Also, "Each iteration should result in a stable portion of the overall system." However, it doesn't state how long that iteration should be.

It does make sense to adjust the definition of "iteration" based on team project. What are the goals of the project? How frequently should the project be stabilized to ensure you're on the right track to delivering a finsihed project? Both MSF for Agile Software Development and MSF for CMMI Process Improvement are flexible enough to support your definition of iteration.

RobCaronMSFT at 2007-9-9 >

So, the answer is that you can change the process from one iteration to the next. You'd want these changes to be incremental such as adding a new field to a work item or a small change to the process guidance. In an agile process, such as MSF for Agile Software Development, this is called adaptation. As you encounter new situations on the project, you "make stuff up" to deal with them. In this way, a process lives rather than grows frail and brittle. This is also part of our agile philosophy of "stretch to fit".

Now, you wouldn't want to completely change the process from one iteration to the next. Could you imagine the effect that this would have on a project? But you don't want developers to have to "consult the process tome" every time a special cause variation is encountered ("special cause variation" is a great phrase that my friend David Anderson uses to describe "events out of the ordinary"). These are the rare events that we see once in a blue moon on a project that cause our processes to achieve the "shelved tome" status when it tries to cover all of them. "See we did cover that on page 2037" is what the process experts say when they occur. Nobody ever read past page 30 if at all. Process by intimidation.

Adaptation in agile processes use the principles and mindsets (some call these values) to find a solution to a special cause variation and then quickly move on. There are also times when a change is incorporated back into the process itself. For example, you may find that you have governance such as SOX that requires a special review. You can certain add a new checkin note for SOX review (yes/no).

So, the answer is yes. You can change your process in VSTS and MSF from one iteration to the next. You don't do it the same way that you originally create the process in the first place. You don't upload a new process template but migrate work items from one version of the process to another. You replace the process guidance on the team protal.

RandyMiller at 2007-9-9 >