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.
Integrated Development Environment
There are a few choices here, mostly based on the language in which you are developing. Most modern IDEs provide some valuable features that allow us to us spend our time creating rather than on the more mechanical aspects of coding. There is a fine line between becoming overly dependent on the IDE and letting it support what you do, but that line is best defined individually. Some useful features that we sometimes take for granted include syntactic highlighting (Garanimals for Programmers), easy links to the debugger, and some level of code/project organization. You can still choose to write code in VI, but these features make our lives much easier on the whole. Many studies have identified that one of the biggest drains on productivity and creativity is context switching. Every time we need to leave one environment and switch to another, we have to switch context. Being able to run