In Agile, there is often an insistence on using low-tech and high-touch tools to collaborate and report on task status. While these tools may work, you shouldn’t limit your choices without considering all of your options.
“Agile is a generic or ‘umbrella’ term for an operational framework or methodology that strives to keep a focus on requirements by using adaptive approaches and continuous improvement practices.” – WHAT IS AGILE?
The underlying point here is to not blindly focus on the processes and tools you use within your Agile projects. There is nothing in Agile that defines or requires which tools you have to use. Agile is meant to be an adaptive approach, so adapt your approach.
The Hypocrisy in Software Development
Agile is used heavily in software development and many IT related projects. Within that, there are people who insist on using low-tech and high-touch tools. For software development, insistence on low-tech tools is definitely hypocritical. You are going to build these impressive software-based solutions and rely on sticky notes to organize your work – while insisting that it is better than software-based solutions.
The only thing more hypocritical is if the software solutions you were building were collaboration or project organization tools.
I know we have this hipster culture going on where niche groups like old records and other old technology items; it may not be wise to base decisions on that. New technology isn’t necessarily good or bad, it is how it is used and how well it works for your needs. Think about how the tools will fit in your environment and choose the best one. It may be that the best tool is a low-tech solution, just don’t make the choice based on any prejudice towards a high-tech solution.
If you cannot afford high-tech tools, or they just are not cost-effective, that is fine. Don’t use them. But if you are insisting that the low-tech tools always make you more Agile, you are always going to be wrong.
While some approaches define some possible tools to use, ultimate agility is achieved by making the best-fit choices; this includes the choices for processes and tools. Work with what works the best, which is not always what you are most comfortable with. If you work in software development, how are you not comfortable with software-based tools? Are your applications really so bad that they cause you to not trust any software application? You should probably find a new line of work.
Advantages and Disadvantages of Low-Tech / High-Tech Tools
You can’t quickly search a large physical kanban board. It may work fine for a small team, but you are wasting time looking at that board trying to create a cumulative flow diagram or find anything at all on the board for a larger team. They have software that will do that for you.
I personally trust a well-maintained application and database more than a stack of photographs of a kanban board, and the database provides some huge advantages over those photographs. You can more easily work with the data in a database. You can search and find out what was going on for a specific day; compare days and look for trends. Granted you can do that by searching through the old photographs of your physical board, but it is a bit more time consuming (wasted time), getting worse the larger your teams become.
You want to create a graph of your progress, like a CFD or a burndown chart, you are either manually making it or manually entering all the information into a computer to make it for you. Having it high-tech to start with removes an extra step and gives you several other advantages.
- Data redundancy and centralized storage
- Access to records anywhere
- Improved searching capabilities
- Potential for data and pattern analysis
- Improved ability to handle larger teams and projects
- Works well with distributed teams, giving you access to a larger pool of talent
There are very good reasons why the world has embraced more advanced technology than paper and filing cabinets. Low-tech items are more prone to getting lost, damaged, or destroyed. Low-tech items also have a greater difficulty scaling up the larger your teams and/or projects get.
The advantages of low-tech tools:
- Lower cost
- Less training required to use them
Lower cost may be a defining factor, it can make it prohibitive. I don’t think training someone should be prohibitive. In some cases, things may move quickly and you just need to get things done and you don’t have time to train new people. It certainly makes it a consideration and an advantage of the low-tech solution.
Take the Power Away From Processes and Tools
By insisting on low-tech ways to collaborate and track project progress, rather than the best way, you have created a situation where your processes and tools control what you can do. You immediately pick a tool and force everything else to adapt to that tool. Your choices from then on have to take those tools into consideration.
My suggestion is to do the reverse. Look at everything else that you want to accomplish and find the tools to help you do that. Make the tools fit your objectives.
If you are a co-located team, and you find these low-tech tools are not able to do everything you want, but you still want to have the scrum board present in a central location in your room – you can do that. Technology has advanced to the point where we have large LCD touchscreens that can be mounted on your wall and linked to a database on the other side of the world while sharing inputs with thousands/millions of locations.
Fear of these high-tech tools gives power to these tools. Losing that power takes away a choice and it impacts all future choices.
Reflection
Agile should not define how you collaborate, track your progress, or manage your project’s data. The collaboration method matters less than ensuring that we actually collaborate and do it as efficiently as resources allow.
You only get so many choices to guide a project successfully, each choice impacts the next choice. You should make as many of those choices with purposeful intent rather than bias, fear, or false belief that Agile requires them. This isn’t 2001 anymore, we are no longer in the days that the Agile Manifesto was written; we have a lot more options now.
About the Author
Joshua Render is the owner and writer for Agile-Mercurial. He works in the technology project space, leading Agile teams to successful product actualization.