TFS - Process Template Types and the selection thereof ...
Continuation of the post http://dotnet.org.za/willy/archive/2007/12/02/tfs-sdlc-guidance-or-dictatorship.aspx.
What is a Process Template?
The TFS process template is a set of XML files which define the team project environment and associated artifacts, such as team roles and permissions, reports, version control, SharePoint project portal, process guidance and work item tracking. In essence the process template defines the “process” that the team project will be guided through, which can be based on a custom process or on one of the following common process templates:
So what process template should we select?
Once we have explored and created the scaffolding as explored in the Post-Implementation Planning posts, we can proceed to the actual selection of the process template type, in other words the methodology.
Diagram: Post-Implementation Planning Scaffolding Artifacts
The core learning over the years has been that any methodology and process must empower the team. Otherwise, the passion, the enthusiasm and finally the commitment evaporates in front of the solution stakeholder’s eyes. Too often, a great concept or solution is compromised by dictatorship, i.e. a military style project manager dictating who does what, when and more importantly how, or by Swiss democracy in which every team member must cast their vote before the project can advance to the next milestone. If we force artifacts on Team members, it is hard to take responsibility for and ownership of them, whereas we automatically, take responsibility and go the extra mile to meet estimations that we helped define.
View Methodologies and process, as supporting artifacts and do not enforce them as policy. Empowerment of the solution team promotes passion, enthusiasm and commitment, which in turn leads to innovative, reliable and invaluable solutions.
So “Which methodology do we recommend?” you must be asking yourself. The answer is unfortunately the typical IT answer … “it depends”.
It is obvious that methodologies are emerging, changing and disappearing at an increasing pace, which can possibly contribute to the fact that methodologies are not cast in concrete, but evolving to suit existing environments. We as humans enjoy our comfort zone and trusted ways of doing things, which is probably the downfall of any rigid methodology, no matter how much potential it may have for the short to long-term.
We recommend that you review all methodologies available to you and choose one that suits and is capable of evolving into your ecosystem. The methodologies we encounter most often these days and therefore include in our decision matrix are Capability Maturity Model Integration (CMMI), Extreme Programming, Agile (including MSF Agile) and Scrum.
The following graph shows the decision tree we use when evaluating which methodology is suited for a solution team as a base methodology. Why base? Well as eluded to many times before the teams are empowered to customize the methodology to suit their ecosystem, building on what adds value and avoiding what adds overhead to the team.
Figure 4 - Methodology Decision Chart
Refer to book 3 “Software Engineers on their way to Pluto”, section “Call to Action”, for an overview of what we see as the seven important artifacts that create the foundation for a successful methodology and process template.
Although the Team Foundation Server environment is an adaptable and customisable environment, we recommend that you either start with the standard process templates or use them as a base to create your customised process template.
The rule of thumb is that you should start with a simple process, unless the project dictates a high level of governance, process reengineering and improvement and auditing.