Moving toward Agile - 9 Steps to Success
The most important motivation for moving toward Agile should be to gather frequent, if not continuous, customer feedback during development. This more frequent feedback requires a high standard of quality be always maintained during development of the product - making it usable throughout the development lifecycle.
Grabbing frequent snapshots for review will allow the customer to provide the feedback that is coveted by an Agile approach. A snapshot that lacks quality will result in a missed opportunity for the customer to steer the product direction, or worse, the problems will results in a frustrated customer who may become less willing to devote time for future feedback.
At any time, the customer should be able to see the latest features in the product and check for the integration of all features working together. This approach usually differs from a traditional approach which doesn't require quality until final regression testing prior to release. The recommendations here should help move from a traditional waterfall-style methodology toward a customer-centric Agile process.
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.
Agile Practices in Open Source - Developers are the Customer
Agile methodologies are much more common within the better open source projects than many would think based upon the primary tenets of Agile. Agile covets customer feedback during development of a project which is incorporated in subsequent releases or benchmarks of a project. Some might argue that open source projects lack the frequent customer feedback loops required for a true Agile approach. After all, benchmarks between open source releases are rarely seen by any end users, managers or stake holders in a company.
I would assert that the role of the customer for open source projects is the developers on the project. Most Agile projects, many of them developer libraries, succeed because a group of developers find a common need where they can collaborate to create code that each can use within some larger software project or within some larger IT system configuration. Each developer will be working on the open source project in the context of a larger project satisfying some sort of business needs. The larger project is where the end user feedback is important, more often than not, the open source project is a building block. Developers understand the building blocks; end users/customers understand less abstract, more tactile elements such as GUI's, emails, etc.
We cannot demonstrate Hibernate, Spring or JBoss to most customers or end users; these are tools that developer utilize to build or deploy applications that end users can test. A developer would provide the feedback for these open source projects and it would be rare to find a developer working on any of these projects, who is not also the consumer of the projects. In essence, the developer is the customer or end user for the open source project and will judge the usefulness of the project by its ability to save work, provide intuitive interfaces and other technical criteria.
Given that the open source developer is the customer for open source projects, then perhaps we can conclude that open source projects are truly Agile, perhaps even hyper-Agile; particularly when it comes to the customer feedback aspect of the Agile methodology. The developers do see the benchmarks regularly on an open source project and can provide one another with feedback quicker than is often gathered from end users.
Agile Quality Assurance
Agile development processes grow in popularity both within companies and also within successful open source projects. Agile places a priority on customer feedback and better accommodates the manner in which engineers naturally work. But what about quality assurance in an agile world? A few edicts of agile development have a large impact on the way quality assurance operates:
1. Agile requires quicker and smaller increment releases that steers away from the long QA cycles required at the end of a waterfall process.
2. Agile requires instant feedback to the development team about the most recent enhancements or fixes. Development should not move to other tasks until the quality of the previous task is assured.
3. Agile emphasizes customer feedback. Customers should play a large role in the quality process and should see the product at least once per iteration.
The quicker and smaller incremental releases and the need for instant feedback to the development team will present the largest challenge to a traditional QA team. A traditional QA team would demand full-regression testing every time functionality is changed that could impact the system. The agile process usually cannot afford a week of testing for every iteration. Developers need instant feedback, and should not continue on new tasks until testing is complete. For all but trivial software application this quick testing feedback cycle can only be accomplished with automated testing.
Certainly a project can remain agile without automation; if the project has enough dedicated testers to perform full-regression testing as each developer assignment is finished. For most projects this impractical: ten QA testers waiting for each engineer to finish will usually not be affordable.
Given that automation is almost a certainty in an agile environment, what is the best approach to automation of testing? Usually the first line of defense is unit tests created by engineers. A unit test will force engineers to prove that new code works properly and will also create a development atmosphere where code is better designed in order to allow it to be more testable. Even with unit tests in place, when all components are placed together, the resulting integration may fail.
Automated functional tests are the next line of defense in assuring quality and providing quick feedback to the developers. It is my opinion that functional tests should be added as new features are completed, but in most case not added until the customer has approved of the latest features. Once fully automated unit tests and functional tests are in place, full-regression testing becomes turn-key. If full regression testing cannot be automatic and quick, then the project may not fit into the agile paradigm.