Process and the tool

Microsoft has a very competent ALM story that is being backed up by the Microsoft Visual Studio ALM “suite”. Don’t take my opinion for it though; Microsoft must be doing something right in this space to be one of the leaders in Gartner’s “Magic Quadrant for Application Life Cycle Management, June 2012”.

One thing I can point out in the diagram is that Microsoft is not the only player in the ALM space; there are a fair number of people with varying degrees of success battling it out.

The thing you should be aware of is that the tool itself is not the be all and end all of a “proper” application life cycle. I have come across a number of companies that are looking for a “tool” to solve a process problem.

The company feels pain in the way that they are doing things and then starts looking for a tool that will “solve” the problems. When the tool does not fulfil the need 100% they start looking at the next one (in some cases they have literally been looking for years).

The problem is that in all likelihood they will never be able to find the “right” tool, regardless of how complete a story the tool caters for, or how competent or proven the tool may be.

“Then what should we do?”

Glad you asked.
Firstly, take a deep hard look at your current process, highlighting the problems. It is important to be honest with yourself in this step. You will base your plan of action on the outcome of this step. (You may consider doing an ALM assessment that may give you some clarity on your situation or level of maturity https://www.microsoft.com/assess/almassessment/default.aspx ).

Next, find people that have had similar problems, or look at best practices that are being adopted and how they may solve your problems.

Next you need to make some hard decisions.
How are you going to change to relieve the problems? Something needs to give; some decisions need to be made. You cannot expect to follow the same process and somehow the problems will reduce or disappear (as Albert Einstein once said "The definition of insanity is doing the same thing over and over again and expecting different results"). The best development team can only do so much; the rest is up to the process that governs the day to day and week to week actions.

Finally you can start looking at the toolset that will support the process, taking note of the following (just to name a few) aspects:

• How do the various aspects of ALM integrate with each other?
  Do you have a single up to date and accurate “high level” view into the various aspects without needing to dedicate a person or resources to compile these reports or statistics?
• What value can you derive from the tool?
  Does it provide you a rich functionality with regards to reporting, accessibility, integration and/or usability?
• How well integrated is it in your day to day activities?
  Is it available when and where you need it to be with as little as possible context switching between applications or environments?

In conclusion, it is important to note the following:

• You cannot solve a process problem with a tool
• The tool needs to support and automate your process, bringing together information from every aspect of your project!

 

In need of process, ALM or Team Foundation Server adoption guidance?
Give us a shout!