1. Unit Testing

Moving toward Agile should begin with the development team creating unit tests to prove that new functionality works properly and have reasonable confidence that existing functionality remains intact. A developer should not consider code to be complete until new and all existing unit tests run without error. Creating testable code builds reliability into new functionality and proof that at any point in the future the functionality still works.

A test-driven approach should be considered. Test-driven development usually produces a better software design where smaller components are designed to work (and be tested) separated from other components. Breaking unessential dependencies between components inevitably produces a higher quality product that is easier to maintain.

2. Leverage Version Control

Few shops live without one, but in an Agile environment, version control becomes even more important because of the reliance on build snapshots by development, QA and Product Management. When automated builds or automated testing starts to fail, a version control system will provide a history of recent code changes that will shorten the time needed to find the offending code.

A version control system should also allow for creating branches which will allow a good build to be captured for customer review while a development team continues to check in code that may break the build process or the automated tests.

3. Scripted Builds

Agile places pressure on QA to stay current with the latest snapshots for fast testing of latest completed features. Relying upon a manually built application can lead to bottlenecks and result in inconsistent packagings that may not be usable. A scripted build will provide a mechanism for producing a build on demand and should wrap the cummulative knowledge of builds into a single script. The scripted build should compile code and produce any packagings needed for deployment of the product.

4. Automated Installs or Deployments

Some applications are trivial to setup to run, but others may take a great amount of time to manually deploy and be very error prone. With QA and customers reviewing many snapshots before release, wasting time installing the application can greatly reduce the efficiency of the testing team. Confirming that the product runs can be critical for manual QA testing and having a reviewable product for customers and other employees within the company. Automated installs and deployments also aid during release – when it is necessary to install the product for customer use.

5. Scripted/Automated Testing

QA should start moving manual testing toward automated testing. For some types of applications, this can be more challenging. QA that depends upon lengthy manual testing will not produce the periodic usable product that will be needed for customer feedback. Developer unit tests can provide the first line of automated-test defence, but additional testing manually performed by QA should be pushed towards automation. If automation of a good portion of QA testing will be impossible, then some thought should be given to staying away from a pure Agile methodology.

6. Continuous Integration

Tie together scripted builds, unit testing and automated QA testing into Continuous Integration. Devote a computer to grabbing the latest code from Version Control, building the application, deploying the application, running unit tests and then running automated QA tests. This will catch problems with recent code quickly and make determining the offending code easier when something does break. Continuous integration should provide confidence that the current code snapshot is close to releasable, and at the very least, ready for demonstration to customers and stakeholders.

7. One Feature at a Time

Agile prods developers to work on one testable feature at a time. That feature is accepted and then the developer starts the next feature. Juggling multiple features at a time works against getting customer feedback quickly.

Prioritizing features and transforming them into user stories should be tasks that an organization should master. Poor prioritization could result in untestable features when completed. For instance, working on reporting mechanisms will be difficult to test when the reported data can't be entered into the system.

8. Create Product Benchmarks Goals

Start dividing development effort into shorter benchmarks when certain features are complete. For features, what is the minimum implementation that can be completed to demonstrate where we are at? Try to keep time between benchmarks relatively short, perhaps a couple weeks to a month.

9. Customer Feedback at Benchmark

Once quality benchmarks are achieved, customer feedback can be solicited to make sure the product is heading the correct direction. If a customer can't be found for feedback, then the feedback of the product stakeholders should be gathered. Once the feedback is given, it should be prioritized and tracked as new work on the product leading to the next benchmark review.

Its easy to start worrying that a customer review can end up delaying development, because these reviews will cause changes or more features to be added. This customer feedback can actually be a time saver. Better to know earlier if development is heading the wrong direction – reaching completion of a product to find out it is unusable is the worst outcome. Many times, customer feedback needs some triage. The customer really wants a new feature, but development will require a great deal of time. Once the customer finds out how much time, or money a feature costs they may decide they can live without the feature, and work can stay on track to get a version 1.0 out the door.