The responsiveness of Agile teams results from disciplined execution of best practices. When executed consistently, these practices - particularly automated testing, continuous integration and iterative delivery - create integrity of completion for every unit of work delivered. There are specific tools that reduce onboarding time and automate these practices, making them becoming part of every day activity. However, the tools offer no shortcut to Agile adaptation: while the tools make the practices more efficient, they do not themselves provide value without fundamental practices in place.
Why Would I Want Developers To Start By Writing Tests? They Should Code!
Given the extent to which unit testing doesn't happen, perhaps the first question to ask is, why do we write tests at all? From a business perspective, having thorough unit test coverage provides an insurance policy. Project teams don't develop static solutions to a static understanding of the problem domain. They code a dynamic solution to a dynamic understanding of the problem domain. That means the code is going to change. The "insurance policy" comes from having a comprehensive harness of unit tests available such that changes in code that violate assumptions are reported and captured at the time they are created.
Advertisement
This is a tremendous benefit to greater efficiency by eliminating time wasted chasing down problems and reducing risk by lowering the probability of transaction and catastrophic failures created by undetected effects of code change.
Still, unit testing isn't as widely used as might be expected. Perhaps this is because most project teams work to the happy-path outcome (e.g., assuming the code compiles, builds and satisfies the business requirements the first time and for ever), or because of the historical absence of developer-specific mechanisms for certifying code-complete on a unit basis, or still because the act of coding is the most visible part of development and assumed to be the only one that delivers value.
Regardless of the cause, the absence of tests creates a fallacy in development: without tests, code can be considered complete because a developer asserts it is complete. This means completion of each unit of functionality is a matter of opinion, not fact, which obfuscates the actual state of a project. While unit tests don't guarantee "completion" - the tests themselves may be incompletely defined - they create strict, measurable, technical criteria by which methods and classes can be declared to be in compliance. The more accurate and robust the testing harness, the greater degree of certainty of completion. As stated above, this applies at both the moment in time the code is created as well as over the life-span of the code. This creates a static cost of change over the lifecycle of an application as a high degree of errors introduced by change are made visible.
Tests also document system behavior and tolerances more accurately than traditional documentation. Unit tests fail when the code is out of compliance with them, requiring adjustment. As a result, the code and tests tend to stay in synch. Updating traditional documentation does not have a blatant triggering event.
But why write tests first? Testing has greater impact on the underlying software when tests are defined before coding: starting with acceptance criteria is a change in fundamental thinking in how to solve a problem through code. Writing code to satisfy acceptance criteria will, typically, result in a more accurate solution than writing a test to describe the behavior of existing code.
So how do we test? The unit test code itself is simply Java or C# code written to test specific lines, methods or classes of a specific codebase. This, in turn, is compiled and executed over the code base; JUnit and NUnit are open source frameworks for J2EE and .NET platforms, respectively. These include command line and graphical utilities that execute unit tests over compiled code.
There are related commercial tools, notably Agitar, which will create unit tests from the code itself. For existing applications without coverage this creates a great deal of test coverage. However, debate remains whether it is better for developers to write tests first as opposed to automating the process of creating the tests: again, writing the acceptance criteria leads to a change in the code; producing code post-facto may not yield the same results in how the software itself is created. One would also review automatically created tests for completeness and not accept generated code.
There is also automated user interface (UI) testing. Tools like Selenium and Marathon are open-source solutions that provide browser or client based testing solutions that test functionality from the UI. UI scripting typically follows creation of the UI, and in highly dynamic systems UI test coverage is typically far lower than unit test coverage: changes in the UI make UI tests more fragile. In practice UI coverage very often peaks somewhere between 20% and 40% of the project.
The bottom line is that testing is still a practice. These tools are enablers of the practice of testing but do not themselves perform the act of testing. That act is still performed by developers.
The Software Is Done When It's Coded, Right?
Just as automated unit and interface testing provides a greater degree of certainty that the code does what is required, continuous build provides confidence that code committed is structurally complete relative to the entire codebase. In increasingly complex and integrated development stacks, the rate of change across the codebase introduces a greater degree of risk of failure or breakage with every code commit.
As with unit testing, it is interesting that there are still quite a lot of projects with manual build processes. This typically means there is no automated testing (and therefore no benefits of testing rigor) or metrics consistently applied to code. This also makes the build process a hidden task that introduces delay to QA and production releases, latency in feedback cycles that reduces quality. This also reduces the certainty with which committed work can be said to be "complete" and the state of a project becomes a matter of opinion as opposed to fact: work can be said to be closer to complete if the entire project successfully compiles and builds; work is not complete if substantial effort remains to be performed to get it into that state.
By comparison, continuously building (e.g., with each code commit), code is complete and known to build such that the application under development can be released to an environment for testing or production. A greater degree of technical tasks are therefore completed when the code is committed, and time for "compile and build" is not mortgaged into the future.
Continuous integration makes everybody responsible for keeping the software in a deployable state. If the build is broken, it is the team's top priority to fix the build. As a result, developers don't produce code they assert to be complete only to leave somebody else responsible for integration at some later date. Developers instead produce code that must work with all other produced code, and that makes the state of the build (and therefore stewardship for success) everybody's responsibility.
CruiseControl is an open source tool that enables continuous integration for both J2EE and .NET platforms. CruiseControl operates as a background process typically on a dedicated "build box" that looks for changes in the source control repository and executes a build (e.g., Ant in the J2EE world) script. Errors are produced to a console, build status can be reported as an icon in developers' system trays, and physical notifications can be triggered (e.g., via X-10 interfaces), such as a siren or flashing light, notifying a team very forcefully that the build is broken.
Perhaps one reason why so many projects lack integrated build is because it is disruptive to change from ad-hoc build to continuous integration. It is useful to consider "build maturity." The entry point is for teams to have a consistent, repeatable build process to execute manually. Once a repeatable build is scripted it can be automated using CruiseControl, and the fundamental behavior of "build-state awareness" is introduced. Once established, automated unit and user interface testing (as describe above) and code analysis metrics using open source tools such as pmd and checkstyle can be introduced to the build. Initially these can report statistics showing, for example, the percentage of code coverage or the number of coding standard violations in the codebase. In a high state of build maturity, these "reporting" events become "gatekeeper" or "compliance" events -- code that doesn't comply to a minimal technical compliance is rejected, the build broken and the repair immediate.
Just as with automated testing, the tools themselves do not create a state of build integrity. There must first be the ability to execute a build repeat-ably and on-demand, which is automated for greater efficiency and shorter latency in feedback after code commit.
Iteration Tracking Tools: Keeping An Eye On Things
Iteration tracking provides unparalleled, fact-based transparency of the course, speed and direction of any project or program of work. Iteration tracking is a powerful project management technique that provides transparency into the plans, activity and performance of the teams. The results of the time-box just completed are immediately reflected into the state of delivery, allowing for accurate assessment and projection. This, in turn, leads to better business decisions in projects.
Unlike traditional project planning and status reporting, which gets by on statements of opinion that any given task is "x% complete," tracking is done to independent granular units of work which can be estimated and which are either done or not done. The sum of the estimates and the number complete provide a better assessment for how complete a project really is because the underlying tasks themselves are identified, exposed, tracked and reported.
Iteration tracking is often fitted to the specific problem domain - for example, a software asset in a long cycle of evolution has a different definition of scope management than greenfield development of functionality which must be completed by a specific date. Similarly, part-time teams or teams with highly dynamic staffing will introduce difficulty in capacity analysis. This tends to defy hard-and-fast definition in tools.
XPlanner, an open-source tool, provides a web-based story repository with iteration tracking capability. Commercial tools, notably Rally and VersionOne, provide Agile release management and program management capability. Perhaps because iterative tracking definition and reporting needs vary (sometimes dramatically) with each project, there needs to be flexibility in tracking and reporting. These tools are among the least well developed in the Agile community. Despite the availability of iteration tracking tools, the bulk of iteration tracking is done in spreadsheets that offer a "language" and reporting capability with which most people performing iteration management are familiar.
Once again, an iteration tracking tool is not a guarantor of disciplined, successful execution. Iteration tracking is only as effective as the completeness of the work being performed. The more disciplined the execution to best practices in the work being tracked, the less likely there is to be rework or hidden tasks that delay project delivery.
It's Still People Over Process
Clearly, the tools make a difference by being non-burdensome enablers of greater quality and responsiveness. However, the tools themselves do not an Agile team make. They add value - they reinforce organizational values, they create consistency especially during onboarding, they create efficiency in execution - but the tools themselves do not create the benefit of the practices. While the tools create efficiency, it is first up to the organization to value - and a team to execute -the best practices of testing first, continuously integrating and iteratively delivering. The tools are the incarnation of the value system and enablers of the practices which contribute to greater responsiveness to change, "greasing the wheels" of execution and making it more difficult not to do these things. However, tools do not obviate the need for the fundamental behavior changes that introduce these practices and the commitment to their ongoing execution.
About the Author
Ross J. Pettit has over 15 years experience delivering complex development projects and managing multi-national operations as a developer, manager, and consultant. He holds a BS in Management Information Systems and an MBA. He is currently consulting to global clients implementing Agile practices as a Client Principal with ThoughtWorks.
Articles 
