Team System : know what you want your process to be to maximise the benefit

I'm talking to a lot of companies about Team System at the moment, both existing users and potential users - in both cases I try to get the message across that Team System will help reduce the burden on individuals to support a given process, be it CMMI, MSF Agile, SCRUM or an existing in-house process.That's one of the great things about Team System - it's extremely powerful, but still flexible enough that ultimately you can use it to support any process.

But here's the thing - the other part of the message is that you can also use it to support a broken process or a process that is not appropriate for the particular project that you are working on. If there are inherent flaws or gaps in the process such as too-low acceptance criteria / flawed release processes then ultimately what you deliver will be graded "Could do better". It may be that your existing process is perfectly adequate - in which case great and you can use Team System to support it or enhance it. If not then the decision to use Team System needs to be followed by a decision on what process or processes it should support, and this doesn't have to be a one-size-fits-all approach since you can use different processes with different Team Projects.

The experiences documented in Implementing Visual Studio Team System in the Microsoft OEM Division's IT Center of Excellence back this up : for example, OEM IT had existing defect tracking processes which they ported to Team System and enhanced. They also paid particular attention to their test case management processes.

My suggestion would be to take a similar approach - don't jump in as soon as the install is complete (although by all means have a scratch Team Project so people can get accustomed to the new system). Spend some time hammering out the finer details of your process or think about how Team System can enhance your existing process. Know what your branching strategy will be. Decide how best to take advantage of reporting and create custom reports if needed. Do read http://www.codeplex.com/TFSGuide. And refer back to it over time. Use the process editor tool. Update the prescriptive guidance. Be vigilant in closing the gaps in the process, refine or change it if you see oversights.

In summary, don't assume the job is done when Team System is installed. Yes, at that point it will still give you savings in areas like time spent on automated builds, traceability etc. But wouldn't it also be nice to use it to help reduce rework and test case regression, to help you refine your estimates for subsequent iterations?

 

Cross posted from ronan's blog