Customizing TFS
As I previously mentioned, I've been collecting data from current TFS users to understand what sorts of customizations to TFS they are currently making in preparation for my upcoming TechEd talk. I've received quite a few responses (thanks to everyone who responded!) and while no two are identical, patterns have emerged which are pretty interesting (at least to me). Hopefully you agree.
Here are some of the reasons offered up for why people customize TFS...they appear to fall into two broad categories:
- Integrate with existing tools, systems and process
- compatibility with existing process
- comply with external regulations
- enact company standards
- Innovate incremental process improvement
- track new kinds of work
- establish deeper integration and traceability between artifacts
- automate process
Let's look at each in turn:
Integrate with existing tools, systems and process
Very few of us live in a world where we can start completely from scratch and store everything we need in a single place such as TFS. Instead, we're part of larger organizations which influence and, in some cases, dictate how we need to operate. I'm sure it'll come to no surprise to anyone that we have many existing tools and systems here at Microsoft. Before adopting TFS to track our work, we used something known internally as Product Studio. Some of the teams within DevDiv still use that system so for now we mirror bugs between both systems using a predecessor to the Migration and Synchronization toolkit. To keep those systems in sync with one another, we had to customize our definition of "bug" to track the corresponding ID in Product Studio. This is a simple example of a very common sort of customization we're seeing.
Many teams are actually a small part of larger organizations which have existing process already in place. It could be as simple as having a tradition of tracking a bug's severity instead of it's priority. So, in order to use the MSF Agile Process Template, the customer would first want to make that change to the "bug" work item within the process template. Internally, because our process has evolved over many years and is influenced by the many teams involved in our divisional releases, our process around bugs is quite complicated. It seems that each team has their own specific needs which we have worked hard to support within our overall definition of bug. Here's a glimpse at our current bug form:
Some customers have to comply various external regulations such as SOX or something known as CFR 21 Part 11 (related to medical research). In these cases, the the customer's ability to influence the standard is often much lower and the criticality of compliance is much more important. Often, this implies additional levels of work flow often implemented as additional work item states. In some cases, only a handful of approved team members are allowed to change the work item state or assign work items to other team members. All of this can be achieved through the customization of work item types.
Another common customization pattern we've seen relates to the initial state of newly created Team Projects. Some companies have established a standard version control tree that they want to be used for each project. Others have established a common set of area and iteration paths for projects depending on the overall type of project. These changes are encoded into the Team Project templates which helps ensure consistency across all projects without requiring significant work after creating each project.
Innovate incremental process improvement
Many customers come to us looking for advice on how to improve their development process. As you might expect, we encourage them to start with one of the variants of MSF which are available as part of TFS. For some, that's sufficient. Others are interested in building their own process from scratch while others want to take advantage of existing process implementations such as Conchango's SCRUM, or Ivan Jacobson's Essential Unified Process. You can see a more complete list of TFS Process Template providers here.
One of the innovations that we've observed is to use TFS to track more work than the standard set of work items in MSF allow. For instance, within my team, we use TFS to help us track exit criteria for each of our major releases such as betas during a product cycle. This allows us to effectively track many aspects of our release readiness by aggregating data from the many involved teams regarding many different aspects of our quality gates. I wrote about this in detail a few months ago if you'd like to learn more.
We also track our feature development through a series of new work item types and reports. This has been done in conjunction with a sweeping change in the way we plan, develop, test and track features. As we've implemented these process improvements, we've iterated on the associated work item types, reports and guidance necessary to successfully make the cultural shift.
I collected the following list of custom work item types currently running on our dogfood server to give an idea of the breadth of additional aspects of the software development lifecycle which we track:
Exit criteria OGF Test case Test issue Experience Feature Product idea Value proposition Backlog Help topic KB article Release note Patent Build request Change request TAP site
Another reason customers customize TFS is to establish even deeper integration and traceability between artifacts. I've seen examples where customers annotate their code and tests with Requirement work item IDs and then are able to identify which requirements have sufficient amount of testing based on code coverage results. Needless to say, as we look forward, we want to enable this type of traceability out of the box since the progress and readiness reporting that this enables would be super valuable. We've also seen customers implement various types of work item hierarchies which helps them understand and manage the relationship between work items. This is another area that we want to enable without customization in future releases.
I'd like to hear from you on this topic. Are you seeing these patterns as well? Are there other forces at play that should be called out?
Also, now that I've discussed the 'why customize' question, it's clear that I need to discuss the question of 'how to customize' as well. Look for information about that in the near future.