The Power of Low-Tech

This industry is obsessed with tools. Planning or tracking, the first impulse for any business is to reach for a software tool to handle their new agile project. While I can understand their reasoning, I think it's wrong to believe that a software tool is going to help achieve any agile goals.

I sometimes get asked to assess the software tools market and make recommendations on an agile tools mix for the best way forward. This implies that software tools are required for successful agile transformation. That is not true. 

If your team is using Scrum, Kanban or XP correctly ("by the book"), you don't need to use any software tools. It's rather the opposite: Start out as simple as possible using nothing but pen, paper and some whiteboards. 

This may sound a bit odd to some of you, so let me explain the reasoning below.

Our goal is to make the agile transformation as smooth as possible. Using low-tech tools can help with that.

As an example, using whiteboards and index cards for planning helps the team collaborate in a way no digital tool can do. Team members are forced to talk to each other, to be present in the planning and problem solving. It encourages them to gather around and engage in constructive discussions. It is also much easier to prioritize and group the work in whatever way they want: just by placing work items out in a row on a big table invites great discussion and participation from the team.

Software planning tools have lots of knobs and switches for tracking hours, defects, members, velocity, lines of code, releases etc. That may be useful, but it can also lead to micro-management behavior which takes energy from the real development work. For example, instead of spending time tracking how many hours each member has spent on each task, use the burn-down/up chart on the wall to see if the team is on track or not. Finally, software tools have a tendency to gather lots of work items that we don't need (cruft), which only serves to confuse and divide attention from the actual work ahead.

Transforming to agile requires a mental shift from documentation to discussion. 

Many organizations are used to producing requirement documents with lots of details and minutia. The problem with such documents, apart from keeping them up to date, is that there is a big chance they get interpreted wrong. They are also very authoritarian, making them easy to accept as written in stone. All this results in huge rework efforts later. Instead, consider user stories written on small index cards. This physically limits the amount of details we can add and this helps the team to create a shared mental understanding of the problem instead. We are effectively transferring information from the (unwritten) document to our brains. All this helps with the mental shift from documents to discussion.

Some may wonder how we can keep track of hundreds of hand-written stories manually. The answer is that we don't have to. Implementing hundreds of user stories in the near future is not possible anyway, so why bother? Just keep the most important handy when the need arises, and you'll be all set.

I also see a tendency to use software tools to avoid having to deal with the actual underlying problem. For instance, using a bug tracking tool to record bugs may is probably no the best way to deal with quality issues. The problem is not how to manage bugs, but how to avoid creating them in the first place. Another example is switching version control system to one better suited to handle merging conflicts (git/mercurial), instead of fixing the root problem: bad planning which causes developers to step on each others work.

In all these cases, the organization is solving the wrong problem and is (un)knowingly sweeping problems under the rug. I'm not saying you should use simpler tools just for the heck of it, but make absolutely sure you are solving the right problem.

In summary: Use low-tech tools to help the transformation to agile thinking and be wary of using tools to fix symptoms rather than the real cause. Use more advanced tool when and if you have a real, tangible need for them.

Quoting Mike Cohn from his book:

I would never go so far as to say you cannot be agile when using a tool. I will, however, say that you can be more agile with pen-and-paper than with a tool. Whenever this low-tech option is possible, use it.