﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Ayende Rahien commented on Individuals and Interactions over Processes and Tools</title><description>@Ralf,
  
I agree that agile and fighting the tools is something that usually don't go together. I also had similar experiances with TFS regarding its perfromance, although I managed to ditch that sooner.
  
My main point wasn't about TFS itself, it was about non-OSS tools. I didn't want to give the wrong impression about OSS tools being the One True Path to Agile.
</description><link>http://ayende.com/2345/individuals-and-interactions-over-processes-and-tools#comment2</link><guid>http://ayende.com/2345/individuals-and-interactions-over-processes-and-tools#comment2</guid><pubDate>Mon, 30 Apr 2007 17:26:49 GMT</pubDate></item><item><title>Ralf Kretzschmar commented on Individuals and Interactions over Processes and Tools</title><description>Well, just my 5 cents of input to that: 
  
I've been working with TFS since August 2005. We've been building up a development shop from 5 people in the beginning to 25 people when I left the project last month. 
  
I have a couple of experiences with TFS standing in your way when trying to be agile.
  
* Compiles running under the "supervision" of the Team Build Service take significantly longer than doing the same compiles via msbuild from the command line. I am talking a one figure number of minutes. If you're thriving for a quick ci-build that bites quite a chunk out of your ten minutes that James Shore suggests.
  
* MSTest is soooo sloooow with its deployment (actually that might have been a problem of our software having to many dependencies)
  
* You have to change Microsofts Buildscripts on each build machine (read: ci-boxes and dev-boxes) if you want a failed test to break the build. What does that tell you about MS's perspective towards Automated Developer Tests?
  
I think I could make the list much longer but I'm on vacation now and on my next project people are not willing to spend the money for TFS, so I do not have to worry about that any longer.
  
Back to your post. I disagree: There is a correlation between the tools you use and the way you work. Being agile means having quick feed back on every level, so you have to pick tools that do not slow you down - even when doing a build or running a test. 
  
I think it also means that you are able to switch tools if the old one does not fit your needs. Try switching after you have done a vendor lock in with TFS.
</description><link>http://ayende.com/2345/individuals-and-interactions-over-processes-and-tools#comment1</link><guid>http://ayende.com/2345/individuals-and-interactions-over-processes-and-tools#comment1</guid><pubDate>Mon, 30 Apr 2007 09:21:05 GMT</pubDate></item></channel></rss>