+972 52-548-6969
Individuals and Interactions over Processes and Tools
This post from Sam Gentile has made me realize that I need to clarify a few things about the recent TFS vs. XYZ discussion.
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.
Comments
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.
@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.
Comment preview