A reader recently asked if IÂ’d write on how agile handles quality assurance. Because the agile framework that my team uses is Scrum, IÂ’ll describe the process in relation to Scrum, but keep in mind that most agile methods treat QA similarly.

First of all, the Scrum process does not demand that developers use any particular engineering practices. But most agile engineering techniques will integrate well, including test-driven development, continuous integration, and pair programming. If Scrum does not dictate which engineering processes a team should employ, it implicitly asks developers to address quality every sprint. Because Scrum asks teams to deliver a potentially shippable increment every sprint, some of that time must be dedicated to ensuring the product functions. In theory, the team should be able to demonstrate the progress it has made to the customer at the end of each sprint. So it follows that the team would want to eliminate as many bugs as possible before presenting its work to the customer.

So how does quality assurance take place over the course of the sprint? One way to accomplish this is by writing robust definitions of the acceptance criteria for each story at the Sprint Planning Meeting. This is an important first step toward ensuring the work lives up to the customerÂ’s standard of quality by fully defining what his or her expectations are. Of course, defects will be detected over the course of the sprint. When that happens, the team can either write more stories to address these problems in a future sprint or resolve them within the sprint that theyÂ’re discovered. I recommend that teams attempt to fix the bugs as soon as they find them. ItÂ’ll mean more work during the sprint and may lead the team to take on less work (lower effort estimates) for ensuing sprints. However, the extra work is worth it because the development team always knows where it stands: Even if the progress it makes is less than the team has averaged historically, the code is clean, bug-free, and ready to be presented to the customer.

To help a team compensate for the extra work of addressing bugs (which will only grow along with the size of the codebase), I recommend automating as much of the testing as possible, including end-to-end (system) testing, load testing, Â“negative testing,Â” and security testing. When the team is capable of automatically testing the system to quickly assess if itÂ’s broken or not, it will be able to make more sweeping design changes than manual testing would allow. The importance of breaking the habit of working in phases is further described in this introduction to Scrum.

Yes, this is a demanding process that appears to add a lot of work to a teamÂ’s regular sprint goals. But thatÂ’s not really the case. Instead, this agile approach to QA simply revises when QA takes place. Rather than building in a linear fashion and resolving bugs at the end, Scrum and agile prod teams to address defects as soon as theyÂ’re discovered. Such conscientious coding might add work in the short-term, but it ensures that the team is always working with clean, functional code and vigilantly eliminating bugs, which significantly cuts development time overall.

You might have noticed: American auto makers are in a little pickle. Interestingly, Japanese manufacturers are doing just fine. WhatÂ’s that have to do with agile? Well, if you trace agileÂ’s roots back, one place they lead to is lean manufacturing, a production practice that attempts to eliminate waste in an effort to create more value for the end consumer. The majority of the lean philosophy is based on the Toyota Production System, which employs two foundational concepts: Just-in-time or Â“flowÂ” and Â“autonomation.Â” In the case of the former, manufacturers work to reduce hiccups in the manufacturing process, thereby creating an interrupted Â“flowÂ” of production. Many would argue that if an organization can optimize its Â“flow,Â” then all other improvements will naturally follow suit. For example, if flow is maximized, then there will be no surplus inventory. Likewise, if manufacturers only focus on the features that customers value the most, this simplifies product design to the extent that only those customer-valued features are produced. The second point, Â“autonomation,Â” attempts to integrate mechanical automation with human workers in such a way that the machines are optimized to help humans do their jobs best.

For those of us working in agile development environments, there are a number of discernible similarities between lean manufacturing and agile. First off, what the team builds is driven by customer demand. This shows an understanding that independent speculation over requirements is, of itself, a useless endeavor. What matters is creating the right productÂ—and the key to that is by paying attention to what customers want. Secondly, lean distinguishes between its Â“resourcesÂ”: Machines and humans are very unique entities with particular strengths and weaknesses. Strangely, those distinctions often disappear in production settings. LeanÂ’s optimization of mechanical counterparts to aid the team is similar to a ScrumMasterÂ’s mandate to remove impediments. Clearly, when a team is empowered to do what it does, the productÂ—and end consumerÂ—benefits.

At this point, saving the American auto industry is not as easy as turning to lean manufacturing or even agile development for the answers, but, moving forward, it could certainly help these companies reduce waste and stretch what resources they still have.

Victor Szalvay, CTO of Danuber Technology, makers of ScrumWorks, tells a story about his hope for the future of Agile in the next 2 years. “I think the coolest thing for Agile is if the core principles are still intact and hadn’t been corrupted by this push, this press for codification at the enterprise scale.”