A Note on “The Tool is the Method”
The post The Tool is the Method generated a lively discussion. Whether you agree or disagree with the post, you are likely to find the experience reported by Rod McLaren in Jira, Greenhopper, Lighthouse: tools vs practice in Scrum of interest. Here is an excerpt from Rod’s post:
Our biggest problem with Jira/Greenhopper was that it isn’t as well-aligned to our developing practice of scrum as we needed it to be. The tool got in the way of our learning the practice, and started behaviourally skewing our view of scrum (‘The chosen tool becomes a factor of the first order in determining not “only” how Agile (or any other software method) will be practiced, but what mindset will evolve in the course of the rollout’). We were trying to fit scrum to the tool we had, and were talking more about how to use the tool well than we were about whether the sprint was going well.
I don’t know that the debate tool v. method could or should be resolved here. Absent resolution, the perspective on the subject Annie Shum expressed in Tools, Behavior, Culture is quite a good one to keep in mind:
In thinking about tools in the context of impacting large scale cultural changes, one can’t help but immediately think about the computer/digital computing. By all definitions, a computer is a tool – in fact, I would venture to characterize a computer as a “universal tool” that can, in theory, perform almost any task. Moreover, I can’t think of any other tool that can surpass the computer and digital computing as the most disruptive transformation agents of our society and cultural shifts in the 21st Century.
The Agile Executive 
Just a side note, and one I would think should be obvious to us in the IT profession.
All software (or non-software) tools will affect your process. Some (like whiteboards and such) don’t get in the way as much as they are very simple. Others, such as software applications, require you to change your process to conform with how you work or expend a good amount of resources (time, money, or people) to make them conform with yours; often you’ll meet half way in this conformance. ERP applications, for example, require either a huge reengineering effort or a huge customization effort. Even something as simple as Word requires some conformance or expense (if you were used to “bolding” with a pen by writing the letters 2-3 times and now had to highlight and click the bold button, while trivial is still a change from what you may have been doing).
Piloting such a system on a project and then standing back and each iteration retrospectively looking at what things you have to do to conform or change within the software tools you have chosen may allow you to come to a conclusion on whether to go forward or not with the tool.
If you choose to customize, then you could run this within your chosen Agile framework trying out the changes and be your own Product Owner!
Cheers!
Paul
Paul Boos
August 6, 2009 at 7:10 am