Some thoughts I had after attending a presentation on Team System…

Benefits of Team System (besides the functional ones)

The fact that this is a product from Microsoft and not from the open source community means that the barrier to use unit testing, continuus build etc will be a lot lower than it is now for some companies. While using open source products in a Java project is almost a sine qua non, there still seems to be a bit of a distrust against open source in some .NET projects. (relatively speaking, compared to Java projects)

This also means, trusting the gigantic marketing machine that is Microsoft, that Team System will probably reach a lot more (MS) developers than the agile community has been able to so far. Because don’t be mistaken, there are still a lot of people out there who haven’t even heard of the concept ‘agile’, or of unit testing, testdriven development, or even of an issue management system (certainly not only MS developers!).

Everybody will be Agile!

So that would seem like a good thing right? More and more developers/project managers/testers/... are being exposed to agile practices, isn’t that what we want? Well…not exactly.

Practices serve a goal, and the same practice may not always be appropriate in every situation to achieve that goal. If you don’t know or understand the goal of the practices you are following, you may be in for an unpleasant surprise somewhere along the road.

What about MSF for Agile?

In this article by Randy Miller, he explains that MSF for Agile is actually an implementation of the agile philosophy (the agile manifesto), adapted to specific circumstances experienced over the years by Microsoft teams where the classical implementations of Agile were deemed unsufficient.

It [MSF for Agile] also presents alternative practices to those commonly found in many agile processes.

For example, while Microsoft recognizes that having an on-site customer is a key factor for a successful project, they also know that this isn’t always possible, and offer personas (invented by Alan Cooper) as an alternative.

MSF for Agile provides you with a lot of guidance and building blocks, all beautifully integrated with Team System, but it doesn’t provide detailed instructions on how to handle day-to-day stuff like SCRUM does for example. You still have a lot of freedom to determine how the project will be run, and that’s where a good understanding of agile is needed. Using MSF for Agile won’t magically make you agile.

The danger

I think there is a danger that people who have no previous knowledge about agile will start equalizing ‘Agile’ and ‘Team System’. I’ve already seen this happening on a team using a custom build Team System-like product, where project managers were way too rigorous in following the practices laid out by the tools, forgetting (or not even knowing) why the practices were there in the first place, effectively crippling productivity and quality.

What can you do to avoid this?

Start learning Agile. Read about MSF for Agile. I have the feeling that Team System gets most of the attention, but in fact you can’t view at Team System without looking at MSF too. They are intended to be one system.

• There is a list with good books on the Systems Thinking wiki where you can start reading.
• If you live in Belgium you can start attending the XP BE user Group Meetings, I’m sure there are similar user groups in your neighborhood.
• Read blogs.
• Doing a project with someone who knows agile won’t hurt either, but may be a bit more difficult to arrange.