Becoming more Agile involves significant changes in the way that we work on a day-to-day basis. One of the central reasons that many technology professionals embrace Agility is its best practices which enhance the Quality of an application effort. Agile practices cut straight to the reasons that many projects fail. Of course, many organizations have also seen that adopting Agile practices does not automatically guarantee them improved Quality either. What practices should you focus on to ensure that your development efforts benefit from Agile's wisdom in terms of improved quality and productivity?
What's productivity have to do with Quality?
Recently, I had the pleasure of hearing an esteemed colleague speak about the tradeoffs between quality and productivity. His view is that quality and productivity compete for the same resources and you really can't focus on both at any one time. If you want to have zero defects, it does take commitment - often in terms of time, resources and budget. Quality may be free in some circles, but I have seen QA budgets in the millions of dollars. Most QA teams are stretched thin and face a challenge with every release to complete their battery of regression tests within the time allotted. Getting the code out faster often requires tradeoffs that can threaten to adversely impact code and systems quality.
Many projects fight a never-ending battle of trying to meet their deadlines, including implementing enough "critical" features and still staying within budget.
Agile cuts straight to the challenge
Many projects - both Agile and non-Agile - exist in a gray area where their development managers try to get a handle on what needs to be done, the complexities of ever emerging technologies and the battle to produce quality code. When we (as technology professionals) fail, systems crash, functionality does not work as needed and we hear that, once again, a technology effort was over budget. Agile cuts straight to the core of the issue by focusing on techniques which yield running systems that meet the requirements customers really need in the fastest possible time frame - aptly called "sprints" by Scrum enthusiasts. The imagery is compelling as we see small technology teams plan short iterations that yield components which really work and allow us to kick the tires of a running system in record time.
Why does Agile work? How does it really improve Quality?
A lot of people know that I am not a hard-core Agile enthusiast. I am the guy who has said that Agile needs to mature into a more comprehensive framework or else risk losing its relevance in the software development community. I have certainly come to love many of the Agile practices as being the best solution to the tough challenges that technology professionals face every day. One of the reasons that becoming Agile works is because it cuts straight to the challenge of dealing with shifting requirements that are hard to understand, codify and will, most surely, change before the project is done. Successful requirements gathering is critical to any technology effort. Obviously, some requirements are easy to specify and are not likely to change. Other requirements are almost impossible to understand and even harder to document and maintain. Agile holds the banner high with the view that requirements documents should not just be binders of shelfware. Requirements must be maintained as living descriptions of what the customer really needs and wants. Of course that's not easy to do unless the specifications are implicitly part of the quality assurance process.
Test Driven Specifications
All requirements are not alike. Specifying the requirements for a life support system are very different than a large scale SOA business application. The algorithms for a trading system must be specified and documented or else Agile cannot be used in some of the most important financial systems. Test Cases must be kept current or else releases will be deployed with the same defects over and over again. One good way to improve quality is to make test cases which are robust enough to meet the needs of a requirements document. Building testing into the beginning of the