Many people find themselves using MSF Agile in their Team System server simply because the process template comes rolled in the box. The MSF Agile process isn’t the issue here, but the practice of using it to support other processes. Would it make sense, for example, to use a RUP Process Template if you were on an XP team?
I have seen more than one team attempt this and the result has always been less than ideal. The reason it hurts is quite simple, really. It is language.
The Team Lengua
We talk a lot about ubiquitous language in software development, but have you stopped to think you might be usurping your own team language? If you are using Scrum, for instance, guess what you should be working on.
- Product Backlog Items
- Sprint Backlog Items
- Bugs
Scenarios? Nope.
Requirements? No.
Task? Actually, no.
How about User Stories? Well, User Stories make great descriptions and details for Product Backlog Items, but are actually only part of a complete Product Backlog Item.
“But, we’re using MSF Agile and Scrum (or ProcessX)and it works out fine.”
Right, because you have probably made the following associations in your culture.
| Scrum Term | MSF Agile Term |
| Product Backlog Item | Scenario
Risk Quality of Service Requirement |
| Sprint Backlog Item | Task |
It’s a Task Switch
And this works on the surface, but how many times have you wasted a few mental moments doing the map in your head in the middle of a conversation? The shear number of Agile processes and terms in each leads to constant shifting of terms anyway, violating the core Agile ideal that everyone on the team speak with a common language.
Does it grate on your nerves when you hear someone enthusiastically report that they are “doing Agile” with “User Stories” to learn that they are using bad requirements on index cards in a waterfall project and calling it good? If so, this language impedance should stir you a little, too.
But We Customized It
No doubt. Odds are it now looks closer to the process template you could have downloaded and used in the first place, but has fewer features.
By definition, Process Templates enact certain structures, queries, and reports that directly support the process or methodology they are supporting. Odds are, customizing a template meant for one methodology and using it to support another will simply not give the full compliment of features one realizes from a Team project optimized for the process the team is using.
Just Try It. The First One’s Free
It really isn’t difficult to install a new process template. Cruise over to CodePlex and check out the huge selection of process templates and other tools free for the using, or see the ones on Microsoft’s own page.
The teams that bothered to customize the template are already doing way more than I’d expect on most teams.
Those teams have at least one (in practice, at most one) dev that has read enough of the documentation or tinkered with enough of the options to realize they can reduce the impedence mismatch between what they practice and MSF Agile.
This exemplifies just how important the “out of the box” experience is. Because 9 times out of 10 that’ll be the only thing the users will ever experience.