Method Is a Tool, Not a Toolbox

Fleeting

method is a tool, not a toolbox

Recently, I was having a semantic debate whether or not we use a method. It got into whether or not it is useful to cherry pick only pick this or that part of the method.

I was told the following analogy:

“A method is like a toolbox. You can pick whatever tool you need from it, without needing to pick all the tools. You can use the hammer, or the screwdriver, or the saw.”

To me, in addition to introduce a ¹ that I won’t develop here, this analogy is not accurate.

It suggests that whoever created the method did not think of it as a whole, but as separate parts independent of each other.

I assume that this might be true in some methods, but in the ones I have investigated, such as gtd or scrum, there are a lot of connection between the elements of the method.

For instance, the daily scrum is strongly related to the sprint goal, the sprint backlog, which themselves are strongly related to the notion of sprint. Also, it relies on two of the three pillars of scrum: inspection (scrum) and adaptation (scrum).

To my mind, simply picking the idea of having a conversation on the morning and discussing whatever we are working on is not at all picking the daily scrum tool from the scrum toolbox. It is rather using the same word to do something quite different.

Therefore, in that analogy, I would suggest that a method is not a toolbox with independent tools, but rather a tool, with several connected parts. Using only a part lose some of the intent of the method.

My phrasing of this analogy is then:

“A method is like a tool. It has been made to fulfil a purpose and is composed of very connected parts. You can try to use the part separately, but you will likely lose some of its interest”

I can imagine that in some methods, you can follow the connection and see not only one whole tools, but a few of them with weak connection between them. I think it needs a deeper understanding of the method to be able to extract all the parts that come together and still taking advantage of the method.

Also, at least in scrum and gtd, I feel like those methods have evolved with time, trying to remove the extra parts that were not essential (lean). The current state of the method is still evolving, but is likely to contain only a kernel of strongly related components. This reinforces my belief that it is highly probable that it makes little sense to use only a part of the method and claim reaching its objective.

To be noted that sometimes, the claimed objective of the method and your objective might differ. In that case, it sounds perfectly reasonable to create your own method and picking into the part of other method as inspiration. But in that case, it would be intellectually dishonest to pretend applying the method and reaching the same objective.

Notes linking here

• bad analogies

Permalink