The Tool is the Method
In a recent post in dev2ops, Damon Edwards examines the role tools often play in the context of a desired cultural change. To quote Damon:
Did you ever notice that our first inclination is to reach for a tool when we want to change something? What we always seem to forget is that web operations, as a discipline, is only partially about technology.
Damon’s states the following view on the right balance to be struck:
The success of your web operations depends more on the processes and culture your people work within than it does on any specific tooling choices… We see this repeatedly in our consulting business. Time after time we are called in to do a specific automation project and wind up spending the bulk of the effort as counselors and coaches helping the organization make the cultural shift that was the real intention of the automation project.
While I am in full agreement with Damon on the phenomenon, I would like to highlight two nuances that in many cases make the tool is the method an effective approach to rolling Agile:
- The rise of professional procurers in Global 2000 companies (see Selling is Dead) changes transactional aspects of Agile engagements. Professional procurers typically focus on negotiating the best possible deal for the tool(s). Moreover, they tend to determine the preferred tool(s) in the early stages of negotiating the engagement.
- Tools might not change culture, but they can and often do change behavior. Think, for example, about the way numerous folks use Twitter. What starts as “having a little bit of fun” often leads to major changes in the way one collects, stores, analyzes and assimilates information. The changes happen not due to an explicit intention to change, but as part of “playing” with Twitter.
Between these two nuances, a typical progression for an enterprise level Agile initiative tends to be as follows:
- A tool is chosen
- Teams start using the tool
- The tool induces behavioral changes
- These behavioral changes prevail, overshadowing cultural change initiatives
Hence, in many circumstances the tool indeed is the method. 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.
See the presentation entitled Four Principles, Four Cultures, One Mirror for additional details on the subject. A short summary of the presentation is given here. Related views are summarized by InfoQ here.
The Agile Executive 
Tools often become *a* method, but whether they become the *desired* method may be a completely different question.
jrep
July 8, 2009 at 11:18 am
Agree. The point I am trying to get across is subtly different: think once, think twice, think thrice about the tool you are choosing for the Agile rollout. The tool you pick is likely to be stronger than the cultural change initiative you might start.
Israel
Israel Gat
July 8, 2009 at 5:47 pm
Totally agree that the right tooling is essential to teaching and enforcing that behavior.
The issue I was addressing in my post was that many operations organizations ignore that they have a cultural or behavioral problem and assume that a better tool will fix the symptoms (rather than addressing the root problems).
In your example solution progression you leave out one key step…. they made the conscious decision that undergo an “Agile” initiative! That means they made the decision to change organizational behavior and culture.
Imagine they hadn’t made that decision. What if they just said, “our development has problems… let’s fix it with new project management and build tools.” Dropping a Scrum tool and a Continuous Integration tool into those environments without the will to change culture or behavior would be disaster.
Damon Edwards
July 11, 2009 at 2:27 pm
I would distinguish between three levels of intervention:
Ignore the problems – yes, indeed, one is likely to fail.
Acknowledge and introduce the right kind of tool(s) – fair prospects of succeed.
Acknowledge and embark upon an explicit culture change initiative – hard and lengthy process.
Perhaps I was unintnetionally a little terse in my articulation. The full rationale for the recommendation made in the post is given in my Agile Roots keynote presentation (http://tr.im/rT2h).
Israel
Israel Gat
July 11, 2009 at 3:34 pm
I don’t think you can use Twitter as an example of a tool changing culture. Twitter is a new modality and process of communicating that was instigated by the new technology. that’s not just a tool.
If one introduces a new developer workbench for the same programming language does that drive change in beahviour? No. usually the users force the new tool to fit their existing processes and negelect the best benefits of the new tool.
if you introduce a new source management tool without introducing new processes and changed attitudes to source lifecycle does the tool on its own change developer behaviour? Never.
Twiotter is more than a tool. new tools don’t change people.
if you fix the culture, the peopel will change the processes. if you fix the processes you will identify wqhere new tools can help the process. None of that flow works the other way around. You can’t buy a shrinkwrapped fix to culture or process.
He Tangata
July 11, 2009 at 5:06 pm
@He Tangata: actually, IME, introducing new tools nearly always changes developer (user) behavior. A problem is that the introducers often intend a different process-change than the users spontaneously adopt. A common (and generally painful) pattern is trying to do things the old way with the new tool, and then inventing elaborate processes to emulate what the old tool was doing instead of finding and applying the unique strengths of the new.
In moving from CVS to Subversion, for example, users often want single-file tags, which CVS can do easily, but Subversion’s “cheap-copy” model makes all tags universal. Rather than benefit from the change management advantages of universal revisions, users often create elaborate procedures and scripting to get something like a single-file tag, and then more process and scripting to reassemble a collection of single-tagged files into a build tree.
I think Israel’s point, in these terms, was something like “watch out: people will do perverse stuff like that.” His suggestion is, I think, to choose new tools with an eye to the processes people are likely to perceive or invent around them. I think the general process-engineering idea, for some time, has been “you can’t possibly guess in advance what users will do, you must train their expectations, as well as deploy the tool.”
jrep
July 12, 2009 at 3:31 pm
Yes we are all violenty agreeing 🙂
behaviours will change with a new tool, but in unpredictable ways in order to preserve the momentum of existing processes.
that is because it is not the tool you want to change it is the process andf the behaviour/culture – otherwise why spend the money on the tool.
The mistake we make is to budget only money for the license and the implementation, not for the associated process and people improvements.
in fact, the real mistake we make is to start from the tool: “ooh nice features”. We should start from a desired business benefit and work from there INTO people process and technology. if that ends up requiring a new tool, so be it, but often it doesn’t – we can make better use of existing technology once we fix the process and the ABC: attitudes, behaviour and culture.
of course this approach is harder and more expensive. the fact that it works while just changing a tool doesn’t, won’t stop IT people from prefering to chase a shrinkwrapped solution 🙂
then in two years time, they’ll say “Well THAT tool didn’t work – let’s go look for another one”
He Tangata
July 12, 2009 at 3:48 pm
I would think we will see more and more tools like Twitter. The “… new modality and process of communicating…” He Tangata mentions are not unique to Twitter – they are characteristic of Web 2.0 infrastructure, applications and tools. A good recent example is Google Wave.
Various applications, including software methods, are likely to change as a result of the new ways by which information flows and collaboration takes place. For example,in a recent tweet #bmichelson indicated “phase capital talking abt potentially applying digital signal processing to separate signal from noise on twitter as CEP feed.” Such a change will affect both tools and behaviors. If Complex Event Processing can change in such a dramatic manner, why not software development?!
Israel
Israel Gat
July 11, 2009 at 5:49 pm
yes but…
I still don’t see twitter or wave as “tools”. there are thousands of software tools. they are mundane things that vendors sell us. transformational technologies like twitter and wave are rare things that need no selling. when we talk of tools I don’t see us talking of them
He Tangata
July 11, 2009 at 8:52 pm
Would not tomorrow’s tools utilize Twitter or Wave as part of the underlying layers? If so, the capabilities of the tools will change dramatically…
Israel
israelgat
July 11, 2009 at 9:03 pm
For perspective: Twitter and Wave are the latest generation in a progression that’s been going on for some time. The previous generation was chat (such as Instant Messanger). Before that was Jabber, and before that was IRC. There are clear differences at each of those generations, and some have had process-significant impact.
From IRC to Jabber, one key change was that Jabber keeps the conversation history even when you’re not connected. When you connect up again, you have context just as if you’d been connected the whole time. This allows you to come up to speed more quickly. This is a small change, but it has noticeable impact, in that users don’t feel so tethered to their dialogs. They sometimes even pay attention during meetings, instead of frantically following IRC!
Jabber to Chat, a big change was a strong shift away from bull-pen conversations and toward one-on-ones. This has a profound influence in undermining the group-training advantages of overheard conversations. Open-source communities, as a result, relatively rarely use Chat as their primary conversation channel, because they depend on osmotic training and recruitment. Enterprises, with a natural hierarchical organization and formal hire/fire recruitment, has a somewhat stronger affinity for Chat. This established history allows you to make a forward-thinking choice, of the sort the OP suggests: do you want to encourage group training and generalist thinking, or discourage it? In an Agile context, bull-pen osmotic generality is often highly prized, and it may be therefore that Jabber or IRC should be preferred over Chat.
Chat to Twitter is as yet unproven. Twitter retains the history, like Jabber, and it retains some bull-pen as well, but it has a very different form of self-organization. The asymmetric friending model in Twitter is quite a hot topic, these days, but as it stands, I’m dubious it can be much help for a team. It’s presently a strikingly new and effective outreach / marketing / support tool, rather than a dev tool. People are experimenting with multi-channel Twittering (emulated through searches, or multiple Twitter accounts, or in proposed extensions), but we can’t even say “the jury’s still out”: we have no evidence yet to present.
jrep
July 12, 2009 at 3:47 pm
[…] comment » Colleague Annie Shum sent me her thoughts on the e-discussion that evolved around The Tool is the Method and Four Priciples, Four Cultures, One Mirror. As always, her thoughts connect a lot of dots. Here […]
Tools, Behavior, Culture « The Agile Executive
July 12, 2009 at 9:47 am
I am gratified by the discussion and would like to thank all contributors.
I am intrigued by the lack of any reply on the sales aspects indicated in the original post:
“The rise of professional procurers in Global 2000 companies (see Selling is Dead) changes transactional aspects of Agile engagements. Professional procurers typically focus on negotiating the best possible deal for the tool(s). Moreover, they tend to determine the preferred tool(s) in the early stages of negotiating the engagement.”
IMHO this is a major factor in determining the nature of Agile engagements. It tilts the balance toward the tool(s).
Israel
Israel
July 12, 2009 at 4:28 pm
On the impact of professional procurers …
Without a copy of the book, I’m not certain I understand your whole point. A part of your point seems to be that high-cost tooling is becoming difficult or impossible to sell. I think that’s a real phenomenon, but it’s met by the rise of open-source and cloud served tools, which lower the cost dramatically. Disclaimer: I work for CollabNet, a vendor of open-source based, cloud-served Agile tools. We — our sales team — see a lot of interest that seems to come from people fleeing high-priced proprietary tooling, but we think there’s plenty of low-priced, procurer-friendly Agile tooling as well. So the specific effect on Agile processes doesn’t seem so significant.
jrep
July 12, 2009 at 5:39 pm
See “Between R&D and Sales” (http://tr.im/s2Bj) for some thoughts of mine on certain aspects of the book (Selling is Dead) in the the context of Agile. I do not know that I can do justice to this excellent book here. Basically, it is about the new dynamics of the sales paradigm – high cost, low cost, or zero (nominal) cost.
Israel
Israel
July 12, 2009 at 6:19 pm
[…] a comment » The post The Tool is the Method generated a lively discussion. Whether you agree or disagree with the post, you are likely to find […]
A Note on “The Tool is the Method” « The Agile Executive
August 5, 2009 at 6:55 pm
IMO, people should learn the process first and start to implement it with the simplest tool that could possibly work. A tool shouldn’t hide the rationale behind a process or people just won’t get why they are doing things like the tool ask them to do. This is especially true during an adoption phase. Once the process is well understood, let people find out if a better one is needed and let **them** choose it.
Pascal Thivent
August 9, 2009 at 9:55 am
[…] The Agile Executive brings up the point that tools are valuable for enforcing new behavior. I definitely agree with that… but still […]
Tools are easy. Changing your operating culture is hard. - dev2ops
October 17, 2012 at 1:31 pm