Software project failures coupled with rapidly changing business needs are forcing organizations to revisit the way they go about building software. Agile development has emerged as one possible solution to the woes of the software industry. Agile enthusiasts claim significant increases in productivity and quality, while detractors cite instances where the reverse is true. It seems to me that probably both are right – some of the time anyway.
Agile means many different things to different organization. There is a long list of agile tenets but not every method of agile applies all of them. And some organizations have cultures which adapt well to agile methods while others don’t. All of these things affect the ‘success’ of applying agile practices to your organization.
Not all agile practices inherently improve productivity. The long term application of agile within a cohesive development team should definitely improve their productivity but this would probably be true of the same team if they were applying some other philosophy.
There are agile practices specifically focused on improving the quality of the software that is delivered
Test Driven Development
No code is written until there is a test. Business Analyst build tests that coders use to determine if the code meets the requirement. Only enough code is written to make the test pass. As code is refactored (improved) over time, the test remains to ensure that subsequent changes do not degrade the initial requirement.
Continuous Integration and Automated Testing
Builds are run with each change to the code base or at regularly scheduled intervals during the day. Suites of automated tests are run against each build. When tests fail making them pass because a number 1 priority of the test
Pair Programming
All production code is written by two coders one at the key board and the other navigating, correcting and thinking of better solutions. Sort of like just in time peer reviews. Pairing occurs regularly throughout the development – with no set pairs but rather pairs that make sense at the moment. Driver and navigator roles should shift often.
Customer involvement
Customers (or their surrogates) actually participate on the development team helping the business analysis develop the right tests and testing and reviewing the frequently released versions of the software
While these practices are included as tenets of agile, a shop need not be ‘agile’ (in the purest sense of the word) in order to incorporate one or more of these quality focused practices into their software development processes.