Do you need a tool to be agile? Or is the process more important?

Cross Post from the Agile and Lean Software Development Linkedin Group.

I’ve used tools in my traditional delivery days (I’m recovering nicely, thankyou) and in Lean/Agile days. I’ve demanded them, introduced them, trained them, rejected them and removed them at various stages and in various contexts. So I have a few thoughts on the matter:

Of course we value people & interactions over processes and tools. But we still see value in processes & tools, which become more significant with complexity/scaling factors.
Pure face to face conversations are easy to manage when there are 7 of you in one room. Co-ordinating large numbers of people with spacial distribution and stringent audit trail needs: not so easy.
Knowledgework is invisible: it's just a bunch of people sitting in front of computers.

Knowledgework is invisible

Electronic Tools have the problem of hiding status – which is already an endemic problem with knowledgework.
As one friend put it: JIRA’s like the mould in your roofspace. You can go and look at it at any time (but you don’t). To make a tool work, you need to have it open pretty much at all times. I had a web-based Kanban tool when running a team, and had it open in a browser window all the time, and flicked into it whenever I was switching tasks. Big Screens can help this, but a physical visual management system (NB: that’s up to date) is amazingly powerful.
Physical systems are very malleable.
You don’t like the process? Fine, take up the tape/rub out the lines on the whiteboard and you remake it. With electronic tools, you will tend to fall into working whatever way is easiest with the tool – changing the tool is often much harder. This can be A Good Thing, but isn’t necessarily so.
Physical systems are still tools.
Any task that’s dull, repetitive and needs to be done correctly every time is a stupid job to give to humans. However, in carrying out that job, the human may gain insight.
Compiling burn down charts is a good example. Manually compile them for a while and you gain a really  good handle on status, progress (rate of status) and attention to detail of your team. Only view the summary? You miss all of that and start implicitly trusting your data. Which is a fool’s errand. Actually, simply having done the compilation job may be enough (which is why all delivery leaders should have had a spell in a PMO, to understand the limits of available metrics)
Any task that requires creativity, connections, communication and intuition is a stupid job to give to a machine.
Anyone who asks What’s the tool? when meeting a new way of working for the first time believes in silver bullets.
I have this bridge for sale. Perhaps we should talk…

Coming back to the start, it’s not about the tool, it’s about how we work together. A tool supports this, not replaces it.

  Recommend this post
Follow me

Martin Burns

Transformation Consultant at CA Inc (formerly Rally)
Previously: Leader of software delivery portfolios in large scale orgs.
Specialism: Transforming complex delivery organisations to be more Lean/Agile.
Mindset: Continuous Improvement Obsessive
Follow me

Latest posts by Martin Burns (see all)

CC BY-NC-SA 4.0 Tools and Agility by Martin Burns is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

%d bloggers like this: