TFS and Baby Steps

I just finished attending ObjectSharp's SMART (Software MAnagement Round Table) session on the impact of quality assurance on the development process and had a couple of observations to share.

First off, the biggest takeaway from the session is the need to move quality to the front of the development process. In this way, quality is a lot like security. There is no way to create a really secure application by adding security features at the end of the development cycle. In the same way, there is no magic powder that can be sprinkled on a completed application to greatly improve its quality. The overall quality of an application is found in its architectural choices, whether it was designed to be testable and the approach taken by the development staff with regards to testing.

However, one of the conversations I had with an attendee regarding Visual Studio Team Systems was just as interesting. He had just installed Team Foundation Server and had created a team project using the default Agile template. The team project he created was going to be for a working application. I found this approach interesting, not the least because (by his own admission) there was no "process" for developing software currently in play.

The interesting aspect (for me) was the supposed lack of software development process in his company. I would strongly suggest that there really was a process in place. Even though you might not think a process is in place with your development team, doesn't mean that a process doesn't exist. In any kind of team development environment, processes will form. It's just a question of how formal the process is. So your 'lack of process' (call it an unprocess) is really just a lack of documentation and formalization. Because of its lack of formality, unprocesses frequently operate below the radar of even the people involved.

If you haven't worked with Team Systems before, let me preface my comments by saying that it absolutely introduces structure to the development process. If you plan on using it 'out of the box' with no customization, you will need to use the process described by one of the canned templates. For those who don't currently have a process, the Agile template is the most likely starting point. But the Agile template includes process. There is a workflow for tasks. There is a workflow for defects. And workflow equals process.

I can appreciate the idea behind starting out with the canned templates. Its presence would indicate that it's a process with proven success. And using the product as it arrives is a first, small 'baby step' into the world of development process. The problem is that the first step you're taking isn't a small one. Instead, you have taken a giant step into the world of Agile development. Complete with all of the process that is codified in the Agile template. And Agile has more process than most people think. The result is that the first 'baby' step can be a killer for Team Systems.

If someone new to a development process truly wants to take baby steps with TFS, they should start by thinking about the unprocess which is currently being used in their organization. Spend a day or even a few hours talking to someone who is familiar with development methodologies, to identify the flows that are currently at play. The default template should be customized to follow this unprocess. Then, over time, the structure originally defined by the Agile template can be added back in, if needed.

Does this require a little more effort on your part? Yes. But the steps involved in modifying the template are both well documented and fairly easy to follow. By taking this approach, you truly can learn Team Systems by taking baby steps. And this is a lot less painful than trying to make the leap from unprocess to Agile.