The growth of agile development practices has turned the software development life cycle on its ear.

As the special report in this issue spells out, the way requirements are gathered has changed. In agile shops, no longer do business analysts spend months working with the customer to develop a huge requirements document that can only be changed at great cost. Agile processes demand that practitioners accept, even embrace, changing requirements throughout the project’s life.

The way testing is done has changed. No longer do QA teams wait for a completed project to run their tests, when finding defects is most costly. Programmers working in agile environments are using tests to drive development, performing unit tests and functional tests as they go.

The way code is built has changed. No longer are overnight batches run so that development teams must spend half their morning deciphering build reports. Continuous integration has become the coin of the agile realm.

Even the way code is written has changed. Developers are working more collaboratively than ever—even those separated by great geographic distances—to produce working code under shorter iterations.

So, too, the tools development managers and their teams use to create software have changed. Many ALM tool suites now include critical project management elements for tracking work and assets. The development environments programmers use are now including more social elements such as wikis, worker profiles, message boards and the like. Testing and build tools are evolving to meet the changing needs of developers producing pieces of projects that must work with other elements, and be changed as needed without “breaking” the software.

For years, we’ve been chronicling the disconnect between developers and tool makers. Developers say they just need help porting an application to a different platform, for example, while tool makers try to foist a methodology upon them that just so happens to be the foundation for their products. This time, it seems, the tool makers are getting it right. They seem to be listening to users rather than leading them down a path they might not want to travel.

The response by software tool providers to this changing development landscape will push the adoption of better development practices even further, and that’s a win for all concerned.