Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,125 | Comments: 45,488

filter by tags archive

Individuals and Interactions over Processes and Tools

time to read 2 min | 290 words

This post from Sam Gentile has made me realize that I need to clarify a few things about the recent TFS vs. XYZ discussion.

This post isn't really aimed at him [that would be me] but I do find a post by him seeming to suggest that you only can use OSS tools to be "Agile" to be, well, quite disappointing

I guess that I didn't notice the conversation digress, but I really should clarify that it has never been my intention to suggest, or seem to suggest, any such thing. Tools helps, and I think that they are important. I have my own preferences, based on my experiance and the way I like to work.

I am mostly talking about OSS tools because I am familiar with them and it makes it easy to point out and show. The best project management system that I have worked with is JIRA, but Trac does quite a bit of the work, and doesn't require as complex a setup.

There is no correlation or dependency between the tools that you use and the way that you work. And you most assuredly can use TFS to be agile.

I do think that tools can be of significant help, you can certainly be agile without them, but it is easier with them. My issues with TFS has nothing to do with agility, and everything to do with seamless usage, a whole seperate issue alltogether.



Ralf Kretzschmar

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.

Ayende Rahien


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.

Comment preview

Comments have been closed on this topic.


  1. The design of RavenDB 4.0: Physically segregating collections - 4 hours from now
  2. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - about one day from now
  3. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 4 days from now
  4. The design of RavenDB 4.0: Voron has a one track mind - 5 days from now
  5. RavenDB 3.5 whirl wind tour: Digging deep into the internals - 6 days from now

And 12 more posts are pending...

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    03 May 2016 - Making Lucene reliable
  2. RavenDB 3.5 whirl wind tour (14):
    04 May 2016 - I’ll find who is taking my I/O bandwidth and they SHALL pay
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats