I love tools. I am the kind of person who can wander the aisles of Home Depot and I just know that I need every tool, gadget and gizmo there - if only I had an idea of what they did. Why use a hammer when a nail gun is so much cooler? Or a simple paintbrush when once of those paint sprayers would be certainly come in handy if I ever got around to actually painting something larger than a repaired nail hole. I am sure that a table saw would be really handy, but I don't have anything that I actually need to cut.
Even more than physical tools, which I really don't know how to use, I love software tools. I have probably used, tried or demo'ed just about every development environment, coding language, IDE, project management, todo list, calendaring, email... well you get the idea. If it is free or free to try, I have probably wasted time looking at it. Some of the tools are great and I still use them. Others were discarded or replaced. Some I willingly pay for because they continue to make me more productive.
This love of tools is not unusual among software developers. That is one of the reasons that we got into the business in the first place. Like any artist - and software development is an artistic activity - we love to build thing. We love elegance and grace. We thrive on solving the problem of making something both useful and beautiful.
Our love of tools, when it comes to Agile, can be our undoing. One of the early mistakes that many managers or those they have tasked with moving the organization to Agile make is to start by looking at tools. We get enraptured by the wealth of Agile tools from simple ones like Trello and Cardboard to more complex tools like Jira, Rally and VersionOne. Just like the tools at Home Depot, we assume that if the tools exist, then they must be serving a valuable purpose, if only we knew how to use them.
This urge to look at shiny new tools violates the first Agile principle,. which is " Individuals and interactions over processes and tools." While processes and tools are useful, it is much better for a new Agile group to adopt the simple, manual approach of post-its, index cards, and copious wall space in a team room. A physical Scrum board with a just three columns of "To-Do", "Doing", "Done" populated with well-written User Stories will provide enormous value to your team:
- A physical Scrum Board is easy to use and maintain. You don't have to worry about the learning curve or hardware compatibility or connectivity or user administration. Just put some tape on a wall and your are ready to get down to work.
- It keeps your information radiator in front of your team and is quick and easy to see. It works even better when the scrum team is located in a single large room and the Scrum Board is right there with them all day. But even if your team room is not the same as the working space, it provides a central location where your team members will get together and have talk about what they are doing, which brings us to the primary benefit.
- A physical Scrum Board is far more likely to encourage conversation - the interactions between individuals - that Agile was intended to promote. When your team members are looking at their own view of an electronic Scrum Board, they lose the face-to-face interaction that is so helpful in identifying gaps in understanding and generating new ideas.
Having your Scrum Board on a wall in the team room makes the act of committing to an Item - moving it from the To-Do to the Doing column - a physical activity, engaging not just the mental intent but the whole body. Moving an item from Doing to Done is a physical success. Pointing to a User Story on the wall and having a discussion about it promotes a level of understanding and agreement that is much more effective than responding to emails or reading off a screen.
None of this is to say that there isn't a role for the many different tools that are available. As your team becomes high-performing or as you start to scale up Agile across a larger organization or more complex Product Backlog, tools will become essential. Tools can help you prepare reports and track long-term trends in your team productivity. They are useful as communication mechanisms with stakeholders outside your Scrum team or organization. But, you should start without these tools and introduce them only when the simple, manual, physical methods start to impede your team's work.
So, if you are manager trying to move your team to Agile or you are a Scrum Master working with a new team, put down your tools, back away from the computer and put your hands on the wall. You will be much better off for it.