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.
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.
Agile not hypersensitive to all tools
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.
So why can't you do these with virtual boards?
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:
 5 Reasons Why Physical Boards Are Better Than Electronic Boards - toolsforagile.com/blog/archives/762/5-reasons-w...
 5 Reasons Why Electronic Boards Are Better Than Physical Boards - toolsforagile.com/blog/archives/760/5-reasons-w...
 5 tips to make your electronic board more visible - toolsforagile.com/blog/archives/932/5-tips-to-m...
Re: So why can't you do these with virtual boards?
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).