Stacking Tools and Skills

We bought a new house a month ago, and have been moving for the last month, which means I’ve had tools in my hands more in the last month than pretty much any time since I was a kid working on my dad’s jobsites.

From planes (sticking door), power screwdrivers (building bookcases), impact drivers (mounting bookcases), mallets, hammers, etc. etc.

And I had two thoughts as I was doing this.

First was “What h**l was I thinking deciding to do all this myself? I’m too old for this s**t.”

Second, and maybe more interesting, I was thinking about aspects of how tool-specific skills  both stack on top of each other and inform and extend each other in enabling me to achieve goals.

Being able to plane a door depends on other skills – like being able to dismount one. It also requires the ability to see how things fit in space, which adds to other abilities, like the ability to set a lock in a door, or to assemble a bookcase that’s square without cabinet clamps or an assistant.

And it made me think about Agile and what I do professionally in a slightly different context.

If you read my stuff here, you’ve heard me talk about how Agile – specifically – evolved from a set of very application-specific practices designed to do a very defined thing very well. And those practices worked – in that context.

But as humans do, we took the success in a limited domain and decided to universalize it.

It’s the functional equivalent of my taking my power screwdriver and impact driver and deciding I’d use them to do everything I’ve done for the last month. It’s arguably possible…but not terribly effective.

Does that mean that Agile needs to “know its place” and have nothing to say about anything that isn’t small-team software delivery?

Nope. It’s waaaay more complex than that.

I’ve said in the past that reality is always more complex than our stories about it, and that our stories always overlap to describe the same reality. I had two superb science teachers in high school – Mr. Crean and Mr. Neubert – and they taught a lesson I still haven’t forgotten.

They had us sit in silence and write a description of a candle flame…the classic observation rubric. Then they asked us – “Is this physics (Mr. Crean’s discipline) – or chemistry (Mr. Neubert’s)??”

The answer of course is it’s neither and both. It’s a candle flame, which exists independently of our framing it as a physics process or a chemistry process. Each frame offers a coherent and potentially useful way of understanding the flame…and understanding both the utility and limits of each frame are pretty important.

Getting groups of people to coherently do something together is like a candle flame – it exists in multiple dimensions – leadership, aligned objectives, economic reality – and we can and do look it at through multiple frames.

Agile is one of those frames, and like all of them, it overlaps and includes elements of each. It is in some contexts – getting small groups of people to collaborate effectively on creative work – insanely powerful. In other contexts, it can be ineffective or even counterproductive.

Understanding agile as something other than as a universal solution, and rather as a set of tools might be a path forward.

And it might add to our ability to be less concerned with building agile organizations and more concerned with building fit, healthy ones

.