There is a fairly meaningless battle that goes on in many shops (even here at Northwest Cadence) when it comes to Team Foundation Server process templates and customization. The prevailing viewpoint is that most customizations are evil and wrong; they will cause only pain and suffering in the future when upgrading to the newest release of TFS from Microsoft. Visual Studio Online tends to be the model, where customizations are strictly forbidden – for now. However, even the most ardent “no customizations” consultant, when pressed, will admit that customizations are as inevitable as rain in Seattle. As you may have guessed, I am not adverse to TFS customizations. In fact, I am all for them. I have both practical and self-serving reasons that support my viewpoint. The most important are the practical. I’ll get to the selfish later. The basis for all the practical reasons for customizations is the fact that there is no way Microsoft could design a template with the exact attributes and workflows that every organization would find most conducive. I would agree that no customizations are necessary if the organization implements their development process exactly as Microsoft has envisioned and uses nothing but TFS and the Microsoft applications that seamlessly integrate with TFS to manage every aspect of software development and delivery, but that is rarely the case. A secondary fact is that if Microsoft didn’t want organizations to customize, they wouldn’t have made it so dang easy.
The question I hear the most from clients is, “will this customization impact our ability to upgrade TFS in the future?” The answer I invariably give is “No, not at all.” However, in the words of Aladdin’s genie, “There are a few provisos. A couple of quid pro quos.” First of all, customizations generally will not cause any problems with the upgrade of TFS as an application. TFS will continue to work just fine and continue to support the existing team projects as they are. What may occur is that the automatic mechanism Microsoft provides to upgrade the process template to support new features will fail. If an organization has customized a process template to the point that the upgrade process cannot determine the source template, the automatic upgrade or feature activation won’t work. This is where the selfish motivation comes in: Northwest Cadence has a great deal of experience helping organizations upgrade these troublesome templates in order to gain access to the newest features offered by TFS. If the customizations were useful and helped the organization be more productive or efficient, but they cause challenges later after an upgrade, that is a small price to pay. Give us a call. We’ll be more than happy to help manually upgrade those artifacts and templates so that you get access to all the cool new features and get to keep the customizations you rely on.
The next question I hear from clients is, “What customizations are the least risky and what ones are likely to interfere with template upgrades in the future?” Before I answer that question I always give the clients a question of my own concerning potential customizations, “Will the customization increase effectiveness, transparency and traceability? Or will it simply enable or promote continued dysfunction?” Adding “waterfall” enabling customizations to the Scrum template will not help in an agile adoption, nor will it bridge the gap between agile and waterfall. It is much more likely to provide a mechanism to continue a flawed process. With that in the open, let’s examine the different customizations and their inherent risk. The least risky of all customizations is the addition of attributes or the addition of values to the list of existing attributes with the exception of the work item State, which determines workflow. Many, if not most, organizations find they need to add some values to the built in work items. Whether it is an identifier from a third party ticket tracking tool or the line item from a business requirement document, it is convenient and efficient to be able to loosely link the TFS work item with the external artifact by including an attribute on the appropriate work item.
Figure: Examples of Low Risk Customizations
More risky customizations are those that involve the renaming of built in work items and the changing of work item state workflow. For example, one client decided that they really liked the workflow of the scrum template, but did not like the names of artifacts. Product Backlog Items became Requirements, Impediments became Blockers and Features were renamed to Initiatives. Depending on how the upgrade logic was developed, these changes might prevent an easy automatic upgrade of the template or activation of new features that requires template artifact modification. That doesn’t mean that the team project will be broken. It just means that until the artifacts are manually modified any new features will not be available. Another impact of these customizations was that a large number of the built in queries and reports needed to be modified as well. Changing the workflow states of work items, specifically those in the task and requirement category can cause unexpected challenges in existing functionality as well as future upgrades. Changing a task workflow requires modification of the taskboard configuration as well, likewise changes to requirement types (Product Backlog Items and Bugs for Scrum, User Stories for Agile and Requirements for CMMI) will require modification of the Agile or Kanban board. They will also most certainly prevent an automatic easy template upgrade. Changes to the bug artifact, which is very common, can cause process template specific challenges. With Scrum, bug workflow modifications impact the Agile board, while with the Agile and CMMI, bug workflow customization is less complex and less likely to break existing functionality.
Figure: This will cause some interesting challenges with the Scrum Template!
Remember that TFS is extensible and customizable. It was designed that way for a reason, to provide you, the customer, with the richest environment possible and to be able to meet the needs of the organization. Are there truly evil customizations? Not really, but there are, for lack of a better term, silly customizations. Modifying the scrum template (which besides being my personal favorite, also supports the agile process in near perfect elegance) to the point that it no longer even remotely supports agile or the scrum process framework is silly. I recently worked with a client who modified the scrum Product Backlog Item workflow so that the available states and transitions were no longer recognizable. I finally convinced them it wasn’t the best idea and we handled the mini-state transitions with a custom attribute instead.
Figure: Silly Customization
The bottom line is that customization should be well-thought out and the repercussions of the customization fully understood prior to making any changes, but they shouldn’t be avoided at all cost due to a perceived challenge to future upgrades.