Scrum and Application Lifecycle Management

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?


5 thoughts on “Scrum and Application Lifecycle Management

  1. Dr8k

    This is an issue our team has been starting to address only very recently. I don’t have any suggestions yet (sorry) but am very keen to see what others have to say!

  2. Dave

    I currently don’t use TFS. Does TFS have the ability to branch code? If so can you branch it into another Team Project? I currently use Perforce and we create an initial mainline branch. We then create the project branch that we use until we deploy our code. Now comes the merge back to mainline and then create a deployment branch (that we lock and never touch again). We also push to a maintenance branch for bug fixing. If we do find a bug we fix it in the maintenance branch, push back to mainline and then create another release branch.

    If there are no other new projects then the above cycle continues for the life of the product. If we need a new project we create a new branch from mainline. The process begins all over again, with the key being a new maintenance and release branch in the end. If there are bug fixes during the project they get done in the maintenance branch, merged up to mainline (new release branch) and then merged down to the project branch.

    This strategy may seem a little excessive but it has worked for us for a long time. It does create a lot of overhead. Some lessons learned:

    – Name you branches clearly with type (dev, main, maint, and release) and project name if applicable.
    – Avoid direct merging between project branches. All merges should happen from mainline. As always situation dictates for example if you have two projects running simultaneously, you need to share code, but don’t want to corrupt mainline. Cross project merging will create complicated merging when you get back to mainline.
    – Be vigilant in merging….get everyone involved.
    – Archive old branches especially release and project branches.

    As I said I don’t use TFS so I don’t know if this process is possible. But it would alleviate the need to specify a methodology for the life of a product. You can specify the methodology for each branch.

  3. Dr8k

    TFS definitely supports branching. One mistake people make when investigating TFS is to assume it uses source safe for its source control. TFS has an entirely new source control engine that Microsoft purpose built for TFS. For those coming from a subversion experience (like me) there is very little difference in functionality. The branching, merging and conflict resolution is all excellent. It is also possible to branch code from one TFS project out to another. HOWEVER, when branching BETWEEN different TFS projects, the action acts as a one-way copy. Without some command line trickery it isn’t possible to merge back the other way.

  4. Miguel Madero


    What about modifying the process template. We faced a similar problem. During the Project period our company used Scrum and the Product Backlog was maintained by the PO and the SB amongst the team Sprint after Sprint. Once we finished the project the customer wanted to take care of the maintenance phase and a new team with their own budget was formed to do this.

    One of our options was to add new Work Item Types and stop adding Sprints and assigning PBIs to Teams and SBIs to devs and rather use Bugs and Tasks with worflows and other concepts familiar for their maintenance process.

    We didn’t go this path, because the customer decided to keep using TFS only for Source Control, but not for managing the project.

  5. Ryan Dorn


    This is one of the most insightful articles I’ve seen so far on this topic. All of my search queries lead me to maintenance and backup of TFS itself. Were you able to find a more elegant solution than creating separate team projects? I’d be interested in any additional information.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s