Confusing methods and tools: The problem with ‘We want to Scrum, so use Tool X’
Something has been bothering me a bit recently. It has everything to do with confusing tools with methods. For many people, there seems to be an implicit assumption that working will ‘tool X’ will result in ‘working with method Y’. Or that ‘working with method Y’ requires ‘tool X’. A simple example of this was a job opening that involved making a number of teams use JIRA Agile correctly as part of their Scrum process. Closer to home, someone asked me if I knew any good online Kanban boards to help a team that was having trouble making decisions and finishing work. Another example was someone who asked if I knew any resource planning tools because his company was having trouble planning people and teams. Or take the person that wanted to get started with the personal effectiveness method ‘Getting Things Done’ and immediately went for DoIt.im. A more subtle example is a MoSCoW analysis where 95% of the functionality was considered ‘Must Have’.
I understand where these people are coming from. I’ve been guilty of this myself on countless occasions. In all these cases, we’re actually confusing methods with tools. The implicit assumption here is that online Kanban tools will improve the decision making, that some resource planning tool will improve resource planning, that DoIt.im will make someone more effective or that JIRA will make teams work with Scrum effectively. Although I’m certainly not going to argue that tools are never beneficial, tools by themselves will not make it all magically work.
New method = new mindset
In all these examples, we’re really talking about moving to some other method or process because the current one isn’t working. Another way of getting work done or making decisions. That is what a method — in this context — is all about. It is about a new paradigm, mindset or philosophy that translates into a number of key principles and decision making rules. A new method translates into different behavior as a result of this. Not because of some tool that enforces the aforementioned principles and rules. If people don’t get the paradigm or the philosophy behind the new rules, they certainly are not going to be more effective. In the end, the new method will probably be discarded as another failed experiment and end up along the roadside. The search for a new tool will begin all over.
So, if a team is finding it hard to make decisions and getting work done, a Kanban board will only be of help to them if they understand that Kanban is about limiting work-in-progress and visualizing work, thereby improving flow. And they should actually do it. If someone wishes to improve their personal effectiveness with ‘Getting Things Done’, they have to understand that it’s really all about making decisions about what is important now and what can be done tomorrow, this week or someday. And they should actually do it. Doing a MoSCoW analysis is only useful if functionality is actually prioritized into ‘Must Have’, ‘Could Have’, ‘Would Have’ or ‘Should Have’. And they should actually do it. We can’t work on everything at the same time, after all. And if a team wants to work with Scrum, they have to understand why change is inevitable and why the ‘fail early, fail often’ principle is the only way to deal with complexity. And if someone is having trouble with resource planning, it might be wiser to start by analyzing why it is difficult, exactly. Maybe resource planning is not necessary if teams are more fixed in composition? If you don’t get the new mindset yet, starting with a tool is not going to make you effective. It’s more likely that the old method will be continued in a tool that doesn’t support it well.
A new method can be easily implemented without any tools. In fact, maybe you should even start without any tools. Just to make sure you learn, on a deep level, why you’re actually doing it like this and why the new method or process works better than the old one. Moving a tool to the forefront makes it easy to skip over that very important part. Scrum can (and probably should) be done with just a whiteboard and a few post-its just fine. Same goes for Kanban or Getting Things Done. The advantage is that these approaches provide you with far more flexibility than any tool is ever going to give you. Tools like JIRA, TargetProcess, Rally, DoIt or Kanbanize — no matter how great they may be — are always going to limit your flexibility. They force you to work their way. It’s very tempting to spend many evenings finding out how to best utilize a tool to ‘it’s fullest’ or looking for ‘use cases’ (the ‘how’ part), thereby foregoing a methodology (the ‘why?’ part). A smarter approach is to start without any tools, get the hang of the method with a few whiteboards and post-its, and eventually — if you really still want to — find a tool that really works for you by supporting your method and process.
So, are tools always a bad thing? Some of us may think so. But I don’t agree. I strongly believe that tools can really help. As long as they support (but don’t force) a method or process that’s already there and supported and understood by those involved. As a matter of fact, we’ve been using (parts of) JIRA Agile for a long time at NowOnline now. But we can easily work without it. For us, it helps to work together as a team when people are working from home or from remote locations. In that case, the tools make our process more effective. But it didn’t start with the tool. It started with a good method (Scrum). And that’s when — in my opinion — using tools is a not a bad thing.