Methods as tools - not as solutions

Methods are important to be able to work in a structured way. Methods restrict me in my flexible work process. Methods are essential to maintain an overview. Methods are a hindrance because they force my project into too strict limits. Methods help me to plan and track my work steps: All these statements are true and yet they contradict each other. One person swears by methods, the other prefers to go "freestyle". The same person is incredibly methodical in certain tasks, but completely rejects methods in other tasks. In addition, there are an infinite number of methods. Good and bad, simple and complicated... Thomas Michl, organization scout and Agile coach, has thought about methods on the website "AgileVerwaltung.org" and comes to the conclusion that methods simply should not be seen as a solution to a problem, but that they are a tool for problem solving. What is the difference? What does he mean by this? Let's take a closer look.

Michl points out that a method can only ever do what a method does: it can be used to manage or tackle a task. However, it cannot solve a complex problem. Often, methods reveal the problems waiting behind the actual task, whereupon the users of the method demonize the method and accuse it of having only increased the problem. So, first of all, every user must realize that methods do not solve problems. This misconception is widespread because methods are often touted as comprehensive problem solvers. The bad news: As a project manager, you are still responsible for solving your problems. The good news: However, methods can help you to do so.

Based on his many years of experience, Michl complains that many users - especially of agile methods - have not understood this fundamental fact. They blame Scrum and Kanban for the fact that their project does not have the desired success. In fact, these methods only make visible the problems that need to be solved anyway. But this is a great thing: The methods help you to identify your problems. In order to solve the problems (even with the help of different methods), the first step is to identify these problems. So now - thanks to the applied methods - you see the problems, or rather the indicators of problems. You recognize that there is a problem to be solved. Here, in Michl's eyes, it is often necessary not to jump immediately to a solution and not to fight the symptoms of a disease, so to speak, but to go in search of the roots of the problems and to fight the disease directly. Easier said than done, because project managers in particular are trained their entire careers to find solutions - and to do so quickly. So we all tend to pounce on a supposed solution when it comes into view. Michl advocates using methods to get to the root and dig deeper.

The second widespread misconception Michl points out is that many project managers think there is a suitable tool for every problem that solves it. This is probably also due to the fact that advocates of methods such as Scrum and Kanban often praise them to the skies. Agile methods are great. They promise success, accelerate projects and increase productivity in companies enormously. But that doesn't mean you can just apply agile methods and be done with it. Scrum, for example, is a great project management framework that can structure complex tasks with teams of up to five people. But it's not designed to help handle routine work. It behaves like a hammer and a screwdriver. Both are super tools, but they have very different applications. A hammer inevitably fails if it is to be used to drive a screw into a board.

Michl in no way wants to discourage the use of methods. On the contrary. However, with his article he wants to draw attention to the fact that all method users should think in advance about which method is suitable for which task. Kanban is for example so much more than only a visualization on a Kanban board. Nobody learns Kanban over night and also not after a single project, which was accomplished with Kanban. Practice makes perfect and this is true for the screwdriver as well as for PM methods - and especially for agile methods. So please don't despair: read, learn, try, look it up from the pros. But use the methods that are out there and try to get a little better at finding the right method for different tasks on each project and then, of course, apply it. The more methods you know, the easier it will be to find one that fits. Good luck!