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.
• You can put things in the space around it.
• You can hang a bottle opener off it. 

While the debate over individuals and interaction over processes and tools may continue in the community, the increasing use of agile planning tools continues to grow with the adoption of agile practices.