January 7th, 2015 by Adam Sandman
In this series of blog articles we examine some of the essential factors required for the successful implementation and use of software tools. In today's article we look at the importance of process and how the success or failure of a new tool can depend greatly on the process that has been put in place.
Put Process First
There is an old saying which goes something like: “A bad workman always blames his tools.” It seems that old proverbs can apply to new technology because when projects go bad – and even sometimes when they don’t - there is a tendency to blame software tools. Is this really fair or should the focus be elsewhere? Blame is like the ultimate renewable energy, there is always more to be had. Blame falls ⃰ on team members, management, clients, working environment and almost anything else from bad weather to a broken coffee maker. Putting all these excuses aside, let’s examine the sibling rivalry between tool and process and the blame that bounces between them.
Bad Processes do not make Bad Tools
Despite evidence to the contrary, ‘process’ is a four letter word in some circles, with people seeing it as cumbersome handcuffs that stop them from doing their job. There is a misconception that Agile projects try to avoid process in favor of people banding together to do whatever it takes to get the job done. In reality, Agile methods are light on process, but the processes they do have are critical. When working with a broken process, people will struggle to make headway until they find a way to circumvent it and, as a result, create one that works. A bad process may cause bad software tool utilization which can then create the impression that the tool is part of the problem when the truth is the tool doesn’t stand much of a chance.
(Insert reference TO FUTURE MYTH ARTICLE on PROCESS)
Good Tools still need Good Processes
To give a new tool a chance it must be introduced with a practical process otherwise it will struggle to gain a foothold. Regardless of how much tool gurus hammer away at the software, given a weak process, only really passionate users will adopt it, others falling back on tried-and-trusted methods they used before. The process is more important than the tool itself so, it is fortunate that process can be improved between iterations, which is far easier to do than switching tools!
It would be disingenuous to claim that the tools are never to blame, but when they are, it should be the job of the iteration review to identify where the tool is inadequate and to find something else to support that particular need; don’t replacing the tool wholesale, just the capability that is poor. It is unlikely that a tool is all bad, so find its strengths, use those and replace the rest. Put the process first and find a combination of tools that will support it.
⃰ “Blame didn’t fall, it was pushed!” T-shirts available in all sizes!
You may also be interested in: