Implement TFS or ALM? Same or different?

Introduction

The answer to the question in the title probably varies from person to person. Some people will say that an implementation of Team Foundation Server (TFS) automatically implies an implementation of Application Lifecycle Management (ALM). Other people will say that this is not the case and you don’t get ALM by implementing TFS.

I belong to the last group of people with some nuances. I firmly believe that an implementation of TFS (and of course Visual Studio along with it) is a really good start of an ALM implementation and that some aspects of ALM almost get arranged without any effort. Unfortunately ALM implementations often stop after implementing TFS and organizations do not get the value from the product that they actually want.

The reason for this blog post is that I want to raise some awareness around the implementation of ALM within your organization. What does it mean, what needs to be done and who are involved? I feel that it is very important to set expectations about an implementation up front.

ALM, TFS or both

People know that you are not an author after installing Word or a designer after installing Photoshop. Somehow this is different with TFS. At first hand some (or many?) organizations think they do ALM after installing TFS.

I work in the profession of TFS/ALM implementations since 2006 and because of this I can easily recognize if the implementation is a TFS or an ALM implementation. It is totally OK to install TFS without doing ALM and it can in fact be very useful, but the expectations must be set correctly.

I know I am doing a TFS implementation when I get questions like:

• How do we structure Source Control?
• How to make a Unit Test?
• How to run Code Analysis?
• How do I create an automated build?

The questions are “How” questions. There is a problem or a requirement and one of the TFS/Visual Studio features can solve this. These questions are often asked by technical people. Software developers, testers and/or architects. They are directly involved in building software and see the bottlenecks in that process.

Microsoft has the tendency to target most of the presentations and marketing on these people as well. “Look at this great feature and what it can do for you!”

It is definitely an ALM implementation when I hear:

• We want to do better maintenance on our releases.
• We want an overview of open issues, because we currently do not know.
• We get a lot of bug reports. We want to increase our overall quality.
• We want traceability from requirements to code.

The big difference with the “TFS” questions is that these questions are focused around a specific problem area. The “Why” is clear at this point or is at least the starting point. Something is wrong, we know why and we want to fix it. The “Why” questions can still be asked by the same Software developer, tester and/or architect. However, often the business, product owners and Head of IT are involved as well.

Instead of choosing to use a great feature because it is a great feature, both features and process changes are sought to solve a problem. In most cases TFS/VS can help in solving these problems but sometimes TFS is not even necessary.

Make sure you know what kind of implementation you are initiating up front. Is it mainly about features or tools, start a TFS implementation. If you want to solve business problems, start an ALM implementation.

It does not matter what sort of implementation you choose to initiate, just be aware of it. Both are valuable and are the best choice in a specific situation, both have a different goal and both need a different approach.

What you need to do

If you acknowledge the advantages of Application Lifecycle Management and you actually choose to do an ALM implementation, you need to arrange more then implementing tools. Generally speaking, you cannot expect an ALM implementation to be successful when only technical people are involved.

To facilitate a successful implementation prepare yourself with the following points.

• Make sure you write down the business problems. Find out the “why” of certain questions and how things can be done differently.
• Actively involve and convince higher management, the stake holders. Write Business Cases. What does an implementation provide to the organization and to the managers?
• Involve as many roles as possible, and not only technical people. Generally speaking they are always eager to try new stuff. Involve the Project Managers, Business Analysts, Architects, Testers and sometimes even end users .
• Analyze the information needs of different roles. What, when and how.
• Target your presentations. Show different features of TFS and VS to different roles. Don’t show the source control features to the business. Show them a list of requirements in a specific release instead.
• Roll out the implementation step by step. Roll out one part, evaluate, introduce next step. Etc. Make a high level roadmap to target & prioritize problems and to make the implementation transparent.

ALM implementation is not only technical, but it is a process implementation also. Changing the process implies changing the way of working. You will notice that most people are willing to change but some people are very reluctant. Do not exclude those people but involve them. Try to give them value on their area. At a certain point things will change. Support of management is crucial here. They need to guide this process and keep everybody on board. , Understand, a business realize its needs by people, tools and process.

Conclusion

I would recommend everybody to use TFS and Visual Studio. Both are great tools that provide you with a lot of possibilities. However, make sure that you know the reasons and people behind an implementation. Is it TFS or ALM that you are implementing?

Be aware of your choice and define your strategy up front. It is perfectly OK to do a TFS implementation if that suits your situation. No matter what type of implementation you choose, make sure you manage the expectations accordingly.