blog

Choosing a Process Template for your Team Project

Published on
9 minute read

Over the years I have had many discussions about Agile vs Scrum process templates with both TFS and VSTS and migrated many Team Projects from Agile or CMMI templates to the Scrum Template.

TL;DR - Select the Scrum template if you have an agile team and want to reduce friction. Don’t create unnecessary friction for your move to agility by selecting either the CMMI or Agile templates that suffer from the legacy of the Microsoft Solution Framework (MSF).

When you create a new Team Project in VSTS or TFS you are asked which Process Template that you want to use. This is a decision that you need to make at the time you create your Team Project and you cant change it later. You want to choose the template that is closest to what you are actually doing, or more accurately what you want to be doing.

Choosing a Process Template for your Team Project Many teams and organisations make very good and seemingly rational arguments for choosing either the Agile or CMMI templates, however I feel that if you are trying to achieve any type of agile implementation for your team then this is the wrong choice. There are two key frictions that I think affect your choice:

Having the right rules to follow is valuable for figuring out the right path:

Making the wrong choice can cripple your teams ability to inspect and adapt by making their biggest problem trying to avoid the friction that your choice in template has created. While I also believe that any  team following any process could, with significant discipline, use any template,  if your team is an agile one then both the Agile and CMMI templates will create significant friction. Let me explain; there are three templates available out of the box:

However every single one of these templates supports both “agile” and “CMMI”, however only one embodies agility and minimises prescription and constraints, and its not the “Agile” template.

Why you should not select the Agile template

I have had a number of… arguments discussions with the folks that own “MSDN: Work with team project artefacts, choose a process template” about its inaccuracies and false choices and some changes have been made. However I have issue with one particular statement in there:

The Agile template is designed to support Agile development for teams that don’t want to be restricted by Scrum.

Lets forget for a moment about Scrum and look singly at the contents and expected use of the templates. I completely disagree that the “Agile” template is suitable for agile teams and I vehemently disagree that the Scrum template is restrictive. I believe that the opposite is true.

I believe that the “Agile” template (as well as the “CMMI” template) is in fact not agile and enshrines many common anti-patterns for agile teams. Its not really a surprise as the “Agile” template was not designed by agilest for agile teams. The “Agile” template is properly called the “MSF for Agile Software Development” template and the MSF part is important.

Microsoft Solution Framework (MSF) was designed by Microsoft Consulting Services (MCS) to help them deliver software to customers when consulting. The MSF for Agile template was originally an attempt to implement that non-agile methodology (don’t let the word Framework fool you) in a more agile manor and it failed (oh it gave managers a false sense of agile; vanity agile. Lets call things agile and do the same old thing we have always done.)

There are main issues with the Agile template:

In addition to the main issues there are a great number of paper cuts as well. While individually small they add up to significant friction:

Forcing people into using these complimentary practices is silly and creates that friction. These practices are not required to be successful at agile however being able to break walls between departments and triage bugs with the rest of our backlog I would argue is. Don’t get me wrong, I like practices like Story Points and User Stories and they are right for some teams, although not all.

If you really want to be able to “let the team decide” on the practices that suit their circumstance, experience, technology and choice then you need to stay away from MSF templates entirely.

So what is the answer? What if I am not doing Scrum, but there are only two other choices, both of them MSF based. Well I would recommend that you use the Scrum Template anyway, and create your own agile process with this as the foundation. For folks that really want to have the Agile template, because they hate the word Scrum and anything associated with it. I kind of lie. I download the Scrum Process Template from TFS and change the same to “Agile for Company X” then reload it.

Why you should use the Scrum Template

Rather like the Scrum Framework itself the Scrum template was designed to be as light as possible while still embodying the common lexicon of Agile. Wither you like Scrum or not, it is an implementation of Agile and uses the same terminology. The thing that differentiates Scrum from other agile implementations is the Sprint and the Sprint is not really part of the Scrum template. You can easily change the Iterations to be any flavour you like.

Bugs are on the backlog, one state for the team working on something, no push to a particular practice.  Almost universally the terminology and workflow of the Scrum framework is understood by teams doing any flavour of agile. And if you have a team that needs a little legacy love you can easily add a column to the Kanban boards without enshrining dysfunctions in the template.

I always recommend that folks start with the Visual Studio Scrum template as a base and customise from there. There are a few customising that I like to see teams make if they need them, especially to help adoption:

These customisations are non-intrusive and have a limited impact on reporting and upgradability. I spend a lot of time at customers migrating them from the Agile and CMMI templates to the Scrum template and while it is not that hard to do it does take time and money.

Conclusion

Choose the Microsoft Visual Studio Scrum process template if you don’t want to be limited by MSF. What other customisations do you make to your Scrum template to support your lean-agile process?

devops tools-and-techniques blog microsoft-visual-studio-scrum msf msf-for-agile-software-development msf-for-cmmi-process-improvement process-template tfs tfs2012 tfs-2013

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

Xceptor - Process and Data Automation Logo
Ericson Logo
Emerson Process Management Logo
Qualco Logo
Healthgrades Logo

CR2

SuperControl Logo
Flowmaster (a Mentor Graphics Company) Logo
Illumina Logo
Akaditi Logo
Cognizant Microsoft Business Group (MBG) Logo
Freadom Logo
Schlumberger Logo
Microsoft Logo
ALS Life Sciences Logo
Capita Secure Information Solutions Ltd Logo
Brandes Investment Partners L.P. Logo
Teleplan Logo
Department of Work and Pensions (UK) Logo
Royal Air Force Logo
Washington Department of Enterprise Services Logo
Ghana Police Service Logo
New Hampshire Supreme Court Logo
Washington Department of Transport Logo
Big Data for Humans Logo
Philips Logo
Akaditi Logo
New Signature Logo
Trayport Logo
Freadom Logo