When folks started moving to agile development around the turn of the century, they first moved away from using certain automated tools. They did this mostly in order to get rid of project management tools and focus on face-to-face communications. This was a reasonable reaction to what had turned into a world of silos and automated workflow management. We developers were ridding ourselves of the mechanisms that produce all of that ceremony and reams of design documents. We would only use index cards and hand-drawn charts on a whiteboard. We didn’t want any tools to get in the way of the real work we were doing.
While this mindset is understandable, we need to evaluate whether this Neo-Luddism is really in our best interest, as the agile methodologies emerge and grow to be adopted by larger organizations. After all, why should we ask our customers to trust the software that we create while we appear not to trust it ourselves?
I’ve come across many teams working extraordinarily hard and spending gobs of money in order to be able to say they are not using a tool. Perhaps the most amusing example I’ve seen is when a team, while recognizing that they would rather be co-located, had a contingent on the other side of the globe. While this might have seemed like an appropriate time to choose a good agile application lifecycle management (ALM) system in order to manage the backlog more visibly, that would have violated the “no tools” principle. So, rather than use a tool, they bought an expensive webcam (because cheaper cameras didn’t have the resolution to capture the story index cards). They then aimed the camera at the manual board and set up an online video connection with the “remote” office.
This solution worked great for the team that had the manual board, but the remote team still had to find someone to move the cards for them. Usually this would happen at the next standup meeting, even if the story itself had been done the previous afternoon. While the team had not used a tool that was sold under the heading of ALM, they created a tool that worked for them, which was great. However, this solution is somewhat awkward, because it not only requires a lot of extra steps, but it also establishes that one team is the “home team” and the other is the remote or satellite team. This does not create the inclusive and cooperative environment that we hold so near and dear to our hearts in the agile community.
While the principles of the Agile Manifesto state that “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation,” when we can’t actually be in the same room, we want to use a tool that allows us to understand each other with the least amount of interruptions. To this end, there are quite a few tools out there, both free and for purchase, depending on your needs.
But, project management and visualization tools are really just an array of possible additions to an already impressive toolbox for the agile world. There are many tools that we need to be truly successful and able to embrace change and excellence. Let’s identify what other tools should be in a well-stocked toolbox.