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 our application through a debugger without having to move to a separate debugging process helps us to stay in that “groove.” Similarly, visual cues like syntax highlighting and even being able to provide a rudimentary level of auto-completion gives a programmer the freedom to concentrate more on the creative process than on the basic syntax of the language. One other feature that many modern IDEs now include is a refactoring engine, which allows the IDE to do a lot of the cut, copy, and paste that is a part of many refactoring methods. Having this engine find all of the instances of a changing variable or all of the places that an extracted class might need to be used is a boon to productivity. Additionally, it makes us comfortable with creating changes that are vital to maintaining suppleness in our code.
Automated Unit Testing Framework
It is now generally accepted throughout the development community that test-driven development is a necessary and useful practice. Test-driven development (TDD) drives design toward highly cohesive, loosely coupled code. The practice also builds a certain level of quality verification into the actual code, providing that most elusive of benefits, high code coverage. Most unit test tools are based on the xUnit foundations, although there are some notable exceptions. Some IDEs actually build in the unit testing platform, allowing the programmer to create unit tests right in the same environment as the production code, whether as a plugin or as an integrated module. In this case, you should consider how easy it is to write the tests first, as opposed to generating tests from existing code.
Automated Acceptance Testing Framework
Just as automated unit tests are helpful for identifying that we are creating the intended code, automated acceptance tests help to ensure that we are creating the software that our customers are expecting. These acceptance tests are an executable expression of the requirements, or acceptance criteria, for any given story. We can confirm with the customer that the acceptance criteria are actually what the customer is looking for, and then create automated tests to ensure that the software is fulfilling those criteria.
Continuous Integration Server
The best way to maintain a low cost of change is to have very tight feedback loops. This way, we find out quickly if we are going in the right direction. We also have a smaller set of changes with which to work if we find that we have in fact gone the wrong direction. We check our tests and code into the repository continuously throughout the day, and the continuous integration server picks up the changes, builds and tests them, and reports the results. This gives us a small change set to worry about if something goes wrong and a quick warning rather than waiting for nightly—or worse, weekly—builds.
Project Visualization
In most organizations, there are many people who are interested in the state of the development project. Sometimes they can just walk into the team room, but often they can’t. Perhaps they are not physically located in the same building, state, or even continent as the team. In some cases, they are just so overwhelmed with other work that needing to get up and go check the team room whenever they want to know how things are going is an onerous burden. Project visualization tools help you communicate where in the process things stand, which user stories are done, and where things might be blocked. They don’t replace face-to-face communication, but they create charts and graphs for visual representation and provide a transparent, distributed way to show the state of affairs. Be sure to select a tool that articulates how things are going but does not enforce a workflow; only the team can do that.
All of these tools are useful and, when utilized in concert, make the business of developing software much more effective. You can live without them, but their proper usage enhances your agility. Each supports but does not supplant your work. If you find yourself changing the way you work in order to support the tool, rather than because it makes sense development-wise, then you should re-evaluate whether the tool is right for you. Let your tools work for you, so you can focus on the “meat and potatoes” of software development.
