Which comes first, the Process or the Tool?
Prologue
I was just going through my email and came across a question on one of our discussion aliases that asked if it was possible to deliver an ALM assessment for a customer without worrying about the tool set they currently use. The customer wanted to have the assessment focus on their process. The person asking the question wanted to make sure we could conduct an assessment in that manner. At first, I was surprised that the question had been asked since I figured the answer is so obvious (after all, this was an internal Microsoft discussion alias). Then it hit me. The answer is obvious to those of us who perform the assessments, and do the training, and work with dozens of different customers each year. But the general IT industry often looks at things differently. The question on the alias was:
“I need someone who can do the ALM assessment where the delivery is tools agnostic”
One of my teammates replied:
“Indeed the ALM assessment doesn't even care about which tools you use.”
I replied to his answer as follows:
“I would take it one step further and state that any ALM assessment that does focus on tooling is done incorrectly. ALM is a process, the tools are…..well, tools. The process should always dictate the tools. The tools should NEVER dictate the process.” Now I do believe the tools SHOULD SUPPORT and BOLSTER the process, but that is not the same as dictating the process.
The Process should come first
I bring this up in my blog because I find myself repeating this sentiment all the time. I delivered an ALM Testing workshop a couple weeks ago (a 3 day high level class that focuses on several different aspects of testing within an ALM based shop). I found myself repeating this message 3 or 4 times per day in response to questions that the attendees were asking. I use this message when I am teaching ALM. I use this message when I am doing an ALM assessment. I use this message when I am delivering a Testing Readiness Assessment. I use this message when I am developing a Performance Test Plan (see this post). I can use this message just about anywhere that I am planning or assessing (unless the assessment is something like “Assess how well we are taking advantage of TOOLSET X, which would be a customized offering and not subject to normal rules).
The simple message that I want to make sure I convey is that “The process should define the tools. The tools should NEVER drive the process. ” In other words, you should:
- Define your process
- Pick tools that fit your process.
- Then enter into a lifecycle maintenance loop:
- Evaluate the process/tools feedback loop
- Is the process still relevant?
- Are the tools supporting the process?
- Lather, rinse, repeat.
Don’t Ignore the Tools
One customer I was recently working with had different tools for source control, development and project management. In order for them to add code reviews to their workflow, they had to create a shelf set, then go to the source control tool to request a review. Then they had to manually add a task to the project management. All of these had to be updated separately and manually upon completion. They were actually avoiding doing regular code reviews because of “lack of time” in their WIP estimates. I showed them the feature of code reviews that is integrated into TFS and Visual Studio [if you have pending changes, you can simply click on the “actions” dropdown, select “Request Review,” and choose a person from the list. That’s it. TFS will make the shelf-set, create a work item task and assign the task to the person.
This is a good example of considering the tools and using them to drive EFFICIENCY. The customer can definitely benefit from the way TFS handles code review workflow. HOWEVER, it is important to know that even if they do not choose to start using TFS, they are still going to be enforcing code reviews as part of their process.