Israel

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.

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

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”

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.

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.”

Israel