It’s the Process, Stupid!

The most important to keep in mind about Team Foundation Server is that it’s all about improving the software development PROCESS. Yes, it’s great to get rid of Visual Source Safe, to automate builds, and get a lot of nice reports—all easily accessed and integrated in Visual Studio, Office, and so on.  Developers love shiny new toys and TFS’s tooling is super cool.  But the key thing is to not lose track of the big picture–and in this case, it is the process.

Back in early December, the first thing we did on my current project was to bring in Steve St. Jean from Magenic’s Boston office. Steve is a VSTS MVP and knows the product better than anyone I’ve ever met.   We were able to get the client’s key players—the director, applications manager, architect, and change control manager—to dedicate most of their time to the project during Steve’s four-day visit.   While the putative purpose of Steve’s visit was to determine how the product could best be used by the client, what REALLY happened was that we put the client’s software development process under a microscope and determined the “why’s” behind what they are doing.

As I mentioned in my previous post, the client has a very tightly integrated environment that extends all the way to deploying the “bits” to production servers.  They do a lot of reporting, SOX compliance, and change control in addition to the typical task of building the applications.

The client is very excited about this new tool, but the classic trade-offs exist. Over and over, we had to ask, “Do you want to modify the tool for the process, or the process for the tool?”  While TFS is clearly designed to be customized, a) it’s still a relatively new product and b) not EVERYTHING can be customized. 

So these questions remained: “What is the process? Why do you do things the way you do?”  In many cases there are things that MUST be done and for good reasons.  Other things were perhaps done to match their previous tools.  But while talking about tools, automation, builds, work items, and reports, it’s important to remember those are just trees; the forest is the development process and it’s critical not to lose sight of that.

At the end of those four days, everyone was VERY satisfied at what we accomplished.  We ended up with a better understanding of the process, which gave us a firm grip on where we want to go with the tool.

I STRONGLY recommend that any company considering adopting TFS to go through the exercise of examining their process, really determining needs vs. wants vs. nice-to-haves.  It isn’t easy for key managers to dedicate a significant part of a week to such deliberations, but the alternative is a set-up for failure.