Hypersensitivity To Tool Use In The Agile Community

In a recent post on CM Crossroads, Steve Ropa, questioned whether some agilists were contradicting themselves by asking others to accept the software they create, but refusing to use software in replacement or augmentation of whiteboards, index cards, and face-to-face communication.

When folks started moving to agile development around the turn of the century, they first moved away from using certain automated tools. They did this mostly in order to get rid of project management tools and focus on face-to-face communications. This was a reasonable reaction to what had turned into a world of silos and automated workflow management. We developers were ridding ourselves of the mechanisms that produce all of that ceremony and reams of design documents. We would only use index cards and hand-drawn charts on a whiteboard. We didn’t want any tools to get in the way of the real work we were doing.

While this mindset is understandable, we need to evaluate whether this Neo-Luddism is really in our best interest, as the agile methodologies emerge and grow to be adopted by larger organizations. After all, why should we ask our customers to trust the software that we create while we appear not to trust it ourselves?

We reached out to Steve for more conversation on this topic.

InfoQ: Some agilists may object to using software tools to augment workflow and human interaction, but do they have a point that the rest of the world should embrace: too much technology can slow innovation rather than speeding it up?

Steve: Absolutely. The point that we should all embrace is that we need to choose what tools work for us, and to choose them carefully . If a tool no longer works for you, pick another one and move on. Another analogy I like to use is my choice of tools as a woodworker. Sometimes, I need a table saw, which is a very powerful tool indeed. Other times, I can just grab my trusty hand saw. It all depends on what I intend to do. And the most important aspect of this, in my mind, is that I NEVER let my tool determine how I work. That is the key here. If the tools we are using become the driver rather than the software we are delivering, we are in fetters.

InfoQ: You also seem to be suggesting that agile scalability depends on the successful adoption of software tools and telecommunications equipment, but would these lead us down the same path of silos and automated workflow...or have we learned our lesson and this time it will be different?

Steve: Hmmm…I don’t really mean to be suggesting that agile scalability requires those things. What I really mean to say is that some of these things can make scaling easier, and we shouldn’t disavow them just because they are tools. With that said, I would never want automated workflow, and I look very closely at project management type tools to ensure that their goal and actions are to facilitate communications, not to limit them.

Brad Murphy, CEO of GearStream, had this to say in support of software tool use in agile software development:

Specifically, at Gear Stream we are investing substantial sums of money to fully automate our end-to-end build/test/deploy tooling chain in the cloud... A tooling chain that supports our own point of view on what highly automated Agile should look like... Our model is flexible and open to continuous improvement and change, so we're not locked into a fixed model, but make no mistake, we BELIEVE big-time in automation.

We also believe the Agile movement has had (on balance) a negative impact on innovation with it's hyper sensitivity to tools. At Gear Stream we're so "all in" on the value of automation that we're building an entire manged services outsourcing model that could not exist without the highly automated and fully integrated tooling chain we're currently building.

But agilists who persist in using index cards, whiteboards and face to face communication insist on the benefits of these tools and techniques over software tools. Nigel Shaw wrote a post on the benefits of physical agile boards over software tools in 2011 highlighting nuances of information conveyed by a physical board versus a virtual one. He came up with this list:

You can tell whose card is whose with a glance.

You can see the complete history of each card’s edits at a glance.

You can tell who made what edits by the handwriting.

Important things are bolded, underlined, or otherwise highlighted.

Unimportant things are small.

You can tell the age of a card by how worn it is.

You can prioritize by rank and by iteration with a single move.

You can move two cards at once (swap position).

It’s big enough for two or more people to discuss over. You could fit three to five. Try that at a monitor.

It can accommodate “extras” in the form of stickers, stars, fridge magnets if you have a metal board behind it, tacked on notes if it’s cork.

You can merge two stories by overlapping.

You can split a story by ripping the card in two.

A story can overlap an iteration border and you can have an agreed meaning for that.

You can delete instantly.

You can add nearly instantly.

You can undo any number of deletes.

You can stand up in front of it, which gets you up and gives you energy.

Agile loves tools that automate testing and deployment. Do continuous integration servers even make sense in a non-agile shop? And agile developers love tools that enable pairing and swarming in teams forced to be non-collocated.

The hypersensitivity comes into play with tools for communication in the areas of requirements, tasking and tracking. As far as I can see, that heightened skepticism has been justified over and over.

I found this article to be a little lacking in research depth on both sides of the issue. It seems like a few google searches with the first hits quoted here :(

The first part of the article seems to focus on tools only as a means of scaling agile, which seems to imply big, heavyweight, "enterprisey" tools. The post also seems to imply that the main purpose of tools is to setup some sort of hyper-automated, integrated, end-to-end enterprise workflow. This is true in some cases, but it is far from the only use case. Small teams, colocated teams, distributed teams -- People use tools for a whole lot of purposes besides scaling.

The other side is also IMHO rather incomplete. For example, the benefit of physical boards mentions: You can tell whose card is whose with a glance, it can accommodate “extras” in the form of stickers, stars, fridge magnets if you have a metal board behind it, tacked on notes if it’s cork, You can delete instantly etc. Well, you can do all these things with electronic tools too. If the author had taken a little while to read the comments on Nigel's post which is quoted here, he would have seen many interesting comments from Dave Rooney, Alan Cooper, and myself, and a good discussion below that.

The real benefit of physical boards is that they are always visible. You see it when you look up from your monitor. You see it when you walk through the room. When someone is passing by, it might catch their attention and they might come in for a closer look, sparking some sort of conversation.

I recently blogged about how you can achieve the same benefits with electronic boards (see below).

Overall I'd like to see a more researched & nuanced article that considers the different reasons why tools should or should not be used, what are the different ways it can be used, and in which contexts its a good idea and when its a bad idea.

Here are three blog posts on similar topics that I've done in the past:

You'll notice that most of the tools agilists object so strongly too are rarely the programmer-tools (e.g., the IDE, built/test-automation), its the more traditional tools for somehow managing or controlling the project and how it captures and communicates knowledge.

The big objection given was how it goes against the agile values. But the more fundamental root of those objections is that the overwhelming majority of those tools at the time were based on more traditional ideas of what the work is supposed to be and how it should be done (e.g., phases, handoffs, separate dedicated, teams/people and repositories per functional discipline, etc.)

The bottom-lin is those tools were fundamentally based on a non-agile paradigm of working.

But it's more than a decade later now and there are now many tools that ARE based on the agile paradigm of working and do a darn good job of supporting that paradigm and the agile values.

Of course the trick is to be able to separate the tools that legitimately do that from the "posers", and not be lulled into forgetting those agile values (which can be quite challenging for some teams that are still in initial stages of agile adoption/maturity and don't get have those values and that paradigm properly "hardwired in" to their mindset).

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.