When Do You Need a Tool?

I recently listened to a podcast about scaling agile. I was sort of okay with what they said until they said this: “You need a tool to do this thing right.”

Uh, no. Not at all. (I actually yelled at the podcast. Sheesh.)

You don’t need a tool to accomplish what they suggested. In fact, when people start with a tool, they too often fail. Argh.

That work is complex and interdependent. Starting complex knowledge work with any tool defines the mental models, filters, and process for everyone very early. We become stuck in the tool mindset, not thinking enough about the problem. The tool creates an anything-but-agile approach, where we don’t adapt to the current circumstances. Too often, the tool forces people to think in very mechanistic ways. We think there is simple logic with simple answers.

I don’t see simplicity in organizations. I see “mess,” that oh-so-interesting mixture of culture and humans.

I do find some mechanistic tools helpful. When I need to hang something on the wall, I like a hammer to bang the nail (or whatever) into the wall. I don’t use a screwdriver for the banging, I use a screwdriver to tighten or loosen screws. I use a rollator to walk because I am more stable with a rollator than without. I also don’t use the rollator for banging nail into walls or for tightening or loosening screws.

That’s a simplistic approach to mechanistic tools.

Here’s the problem. All tools shape our thinking, not just about the result we want, but about our perceived problem(s).

Maslow’s Law of Instrument gave us the quote that “If all you have is a hammer, everything looks like a nail.”

In my experience, the more complex the problem, the less we can use tools that are more hammer-like. If the problem is complex, it’s possible we need several tools, each for the various steps in the process.

And, some tools get in the way of actually doing the work.  (Don’t get me started on Word for writing. I don’t have enough time to count the ways that tool has failed me recently and over the years.) I don’t know about you, but I don’t use many of the features of the electronic tools I have. So many of the features don’t apply to me.

In software, we love our tools. Back when I was a young developer, we had structured design and programming. Then we moved to UML and CASE. Then object-oriented was going to save our tushes. Now, we have frameworks galore, for code and test, and for our process. Some tools help, given the context. No tool was or is a silver bullet.

We don’t need any more freaking tools.

We need ways to work where we can make our mental models clear to ourselves. We might need a tool to help us see the problem itself. We might need a tool to help us evaluate choices. Once we have a tool—if we decide we need one—we might need a way to define experiments and see the results.

I like to think of small tools that will help us make a decision now, and then help us see alternatives for our next steps.

That is the question this week: When do you need a tool?

4 thoughts on “When Do You Need a Tool?

  1. Edith

    Hi Johanna,

    your post gave me an interesting shift in my thinking.
    We are currently introducing a new tool in our company, and I get SO tired about telling people “no tool in the world will do your thinking for you”.

    I think that what you wrote applies to us, too – the mental models are not clear, so we want the tool to solve them for us, but then can’t decide on how to use the tool, since we get stuck in the confusion.

    Now I just need to figure out how to use this enlightenment in our project…

    1. johanna Post author

      Edith, terrific! I often start with paper instead of a tool for: a board of any kind, the process for decision-making for risk management, project portfolio management. Literally, cards on the wall or cards on a table. When I helped a large org start to make their project portfolio, we started with one small group, which supposedly only had five projects. They had about 30, which is why they were multitasking. The tool they had attempted to use disguised all that data. The reason? The cells in the table were too small to see anything. After a year of stickies on boards (super stickies), they tried a tool for a month and realized their stickies worked better. The tool allowed people to add more work than they could do.

      Try paper and see where that gets you. Good luck.

  2. Jim Grey

    Two key times I’ve found that tools are needed are (1) when paper or whiteboard doesn’t scale, and (2) when management needs visibility and isn’t able to get to the paper or whiteboard.

    (1) is simple enough to handle: when you have too many stickies to manage it’s probably time to look for a tool that can be adapted to the process you are following.

    But (2) is insidious, because management too often wants a tool that provides the visibility and, often, the feeling of accountability they want — even if it means changing the processes the team follows because the tool prescribes those processes. Then the team is a slave to the tool. Meh.

    1. johanna Post author

      Jim, when paper doesn’t scale, it’s possible the team/managers/org is talking about too much work. It’s a challenge. How do you help people see the details and gather to see the big picture? IMNHO, too often, we use the same tools to drill down and back out. The tool allows people to add more work to the portfolio, roadmap, or backlog without thinking about it.

      I do see occasions with distributed teams, where the tool enables conversation and collaboration. Just not often enough.

      Yes, your point 2 is exactly what I see, too.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: