Search

Do you really know your toolbox?

How much do we really understand the tools and techniques at our disposal?

The other day I found myself explaining to someone that a particular project sponsor didn’t understand Agile, but that they would readily see the value of delivering value incrementally. Since the project in question didn’t involve software development, I had to stop to think what the difference was between the Agile way of thinking and incremental delivery. It’s nothing to do with backlogs or stand-up meetings or burn-up charts, because the project in question didn’t require any of those things. I decided in this case that it was about understanding the consequences of not using Agile, and therefore about how deeply (or superficially) that ethos ran throughout the project.

At the same time I was reminded of someone who said “I don’t believe you really understand a tool until you know at least three ways it can be misused.” (I’m sorry, I’ve forgotten where that came from.) I think that writer was talking about JUnit, but it’s a nice quote that can be applied widely.

And this got me thinking: what does it mean to really understand those things we use every day? Here are some suggestions that push at the boundaries of what we do and don’t know about our tools:

Understanding what it is. Being able to define or describe something is clearly an essential first step.

Understanding what it isn’t. Some things are similar to others. Can you distinguish them? Scrum is similar to kanban, but it’s not the same. Is your understanding nuanced enough to tell them apart?

Understanding why you would use it. Do you know what problems it solves? Are you using the tool for the right reasons? If you thought it was necessary could you persuade others?

Understanding how you could misuse it. Would you know if you were misapplying it? For example, when do you stop using a unit testing tool and start introducing a mocking framework?

Understanding the pre-conditions for using it. Not every tool can be used equally well in every situation. For example, a significant move to Agile requires culture change as much as anything.

Understanding the consequences of not using it. This is where we came in. If you don’t really understand the consequences of not using a tool then you will not be driving its use sufficiently deeply, and will not enjoy the successes promised. Superficial Agile will not deliver the benefit likely to be promised. Unit testing only where it’s easy will still lead to regression bugs.

I’m sure there are more angles to test understanding. For now, I find this a good cheat sheet.