Can Microsoft development be Agile?

For two years now we’ve been rolling out and upgrading our Java development process to follow the more important principles and practices of [tag]Agile[/tag] development. When the time came to make a similar transformation in our Microsoft development, we found ourselves with some interesting choices to make.

Thatcher and St. Francis of Assisi

It should have been very straightforward:

foreach (development tool) {
    replace "j" with "n" // or similar
}

The experience should have been analagous to the prayer of St. Francis of Assisi that Margaret Thatcher famously recited on the steps on Downing Street on her election as UK’s Prime Minister: Where there is jUnit, may we bring [tag]nUnit[/tag]. Where there is ant, may we bring [tag]nAnt[/tag]. Where there is Cruisecontrol, may we bring [tag]Cruisecontrol.Net[/tag]. (The prayer goes on to bring hope where there is despair, two emotions that every software engineer is intimately familiar with).

Redmond, hear our prayer

But it wasn’t that simple. There was an extra factor in play that changed everything. [tag]Team Foundation Server[/tag]. This new offering is Microsoft’s answer to the question “How the hell am I suppose to create enterprise systems with an agile team using VSS and VB6!?” Under one hood it combines enterprise source control, work-item tracking, centralized builds, and more. We couldn’t ignore it.

In our Java development environment we reduce the risk of vendor lock-in by abstracting ourselves and our processes away from the IDE and other tools (often through opensource tools, and noteably through Spring). In the Microsoft arena, vendor lock-in is the starting point. Deluding oneself by abstracting over your monopoly provider is a waste of energy. Or to put it in more Java-partisan terms, if you’re going to embrace the dark side you may as well use both hands. After 3 months or so in this passionate clinch, I can start to make some observations about [tag]TFS[/tag] and Agile development on the Microsoft platform.

  1. Team Foundation Server works and it works well. Are you surprised? I was. The toolset is stable, and while it is not feature-mature, it handles very well indeed.
  2. Team Foundation Server is very extensible. Again, I was surprised. Microsoft is not dictating our use of their tool – they have made it openly and relatively easily extensible.
  3. We’ve only scratched the surface. One of our very experienced Microsoft developers has just come back from a TFS event in Dublin, and there is much more under the hood than we are presently using.

Our [tag]C#[/tag] developers are writing unit tests using [tag]VisualStudio 2005[/tag], and these tests are being run as part of the Continuous Integration running on TFS. However there are more steps than necessary to get the unit tests run as part of CI and the CI itself does not come out of the box and needs to be added on as a custom extension.

We’re using [tag]TeamBuild[/tag] to manage central and reproducible builds, but we have to write an amount of custom build code to manage our release builds.

In summary: So far so good. Our challenge over the coming months will be to decide how to continue to put more and more DSI direction on this powerful engine.

– brendan lawlor

  1. Limitations of Branching and Merging with TFS at DeCare Systems Ireland Blog

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: