I recently completed (or contributed to the completion) the first phase of a Team Foundation Server (TFS) implementation project. For the most part the implementation was successful and we managed to move a relatively large code-base and complicated build across with only a few minor hitches that slowed progress rather than stopped it.
The code base that we migrated had been around for around seven years and given its age it had been fairly well maintained. The migration to TFS unearthed a few skeletons but because of the level of consistency in the code base we could get around it fairly quickly.
As part of the migration we needed to create a Team Project in TFS which forces us to choose a methodology that we want to govern that particular code base by. Out of the box we get the choice of MSF Agile or MSF CMMI and I had installed the Conchango Scrum Process Template to add a third option.
The Tyranny of Process Templates
I always get a bit nervous about selecting a process template, not because I don’t know what they are, but because I’m stating right up front how this code base will be managed from this point forward. If I had to complain about one aspect of the process template system in TFS it is that you can’t easily transition from one methodology to another without creating a new Team Project (the alternative is manually applying Work Item Type definitions and updating process guidance and reports – hard work!).
From a project perspective it is quite reasonable to select a process up front. At Readify for example we are quite happy to head into a project stating up front that we will manage this project using the Scrum methodology, but is Scrum appropriate for the maintenance period that follows the bulk of the project work?
Project Lifetime vs. Application Lifetime
The problem stems from the fact that applications have much longer lifetimes than the projects that may have spawned them and that at the end of the project the resourcing levels tend to drop down dramatically. Once deployed, many applications don’t have any development resources assigned to them and it can be hard to form a Scrum team.
Of course, as time progresses an application might have more than one project that influences it but there is still a gap in-between which we can call the maintenance period.
So here we have a problem with tooling where the concept of “project” reigns supreme and the concept of sustained engineering is an afterthought that we tack on to the end of projects.
One current solution to this problem is creating a new Team Project when a code base transitions from project-mode to maintenance mode and then select a different process template, but we loose a lot of intelligence about the code base and the requirements when we do that (not to mention that it is a fair bit of work to set the builds up again). Then do the same when we transition into project mode again.
From a project management perspective, Team Foundation Server has some of the best tools I’ve seen for visualising what is going on in your software project. The challenge is getting it to scale down to a slow bubble of maintenance work.
I’m interested in hearing what other people do around managing general maintenance work within Team Foundation Server. Do you try to stick to the rules of the process template that you selected when the project ramped up or do you just return to a basic Task and Bug list and ignore the advanced features like scope management using PBIs and SBIs?