The Agile software development methodology has been building steam over the past two decades, and more especially since the Manifesto for Agile Software Development was issued by a group of software engineers in 2001. The American Society for Quality (ASQ), for one, has embraced it, as the group's members have made it a hot topic because they support its benefits in improving quality assurance and preventing defects and see it being applied outside software development.

Scott Duncan, an Agile development coach and executive subject matter expert at engineering software company Intergraph, who has held various roles at ASQ's Software Division, is an evangelist, using the methodology to develop critical, graphics-intensive software for designing large facilities such as power plants and oil refineries.

Intergraph wouldn't be in business if Agile didn't work. "Our customers include the world's biggest oil companies and construction firms like Fluor and Samsung Industries," Duncan told Design News. "Intergraph develops some of the world's most complex software using the Agile approach."

Agile's quality benefits come from the shift from error-focused quality control (QC) to prevention-focused quality assurance (QA). There is also focus on collaboration and frequent product iteration under the methodology, which results in errors getting revealed during development rather than after months of coding.

Writing for Software Quality Professional, Duncan (with David Peercy, quality engineer and scientist at Sandia National Laboratories) says that the values of the Manifesto released back in 2001 can be summarized as:

Agile teams tend to deliver working software in frequent iterations, rather than using a waterfall model employing lengthy phases. Agile projects involve daily collaboration of developers with customers, business units, and other stakeholders, emphasizing face-to-face interaction and frequent testing and readjustment.

"One of the key things Agile tries to do is to get more frequent feedback both from interaction with customers and from the software itself," Duncan told us. "The idea is to work in small batches and get frequent feedback from stakeholders. You'll have developers, quality assurance people, technical writers, and user experience designers all working on the same team. That way, you avoid the 'hand-off' mentality." This is also referred to as "throwing it over the wall," as each discipline finishes its phase and throws the project over the transom to the next group.

READ MORE ARTICLES BY AL BREDENBERG:

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly," Duncan writes. The collaborative attitude fostered in Agile teams, he says, "manifests itself in everyone feeling responsible that all the work is completed to a commonly shared level of quality."

Under Agile models, teams integrate testing concurrently with development, even testing software daily in many projects, Duncan told us. There is a heightened watch over project "artifacts," such as test cases, test plans, design reviews, and code revisions, as soon as they are created in the name of maintaining quality.

Duncan said the reason why large, waterfall-style software projects have been thought of as the standard goes back to the requirements of large government contracts many decades ago, which called for processes that purchasers considered more rigorous. Even so, the best developers were employing methods that were similar to the modern Agile model, Duncan believes. "Officially, people were supposed to be following the larger waterfall government contracting approach," he said, "but behind the scenes they were actually using these iterative methods 50 or 60 years ago."

Duncan also thinks the Agile methodology is closer to the general processes used by all design engineers. Design errors can cause cascading quality problems downstream in the manufacturing process. "Once you get on the assembly line, you can't have anything wrong, because you have to start cranking out thousands of parts," he noted. In software, the cost of programming errors can mushroom the later they are identified.

"Design engineering doesn't build the correct thing the first time," he said. "It can take years to come up with the right design, as you iterate over the prototypes." In this way, "software development is less like assembling a car and more like designing a car."

Al Bredenberg is a writer, analyst, consultant, and communicator. He writes about technology, design, innovation, management, and sustainable business, and specializes in investigating and explaining complex topics. He holds a master's degree in organization and management from Antioch University New England. He has served as an editor for print and online content and currently serves as senior analyst at the Institute for Innovation in Large Organizations.

Like reading Design News? Then have our content delivered to your inbox every day by registering with DesignNews.com and signing up for Design News Daily plus our other e-newsletters. Register here!

Design engineers and professionals, the West Coast's most important design, innovation, and manufacturing event, Pacific Design & Manufacturing, is taking place in Anaheim, Feb. 9-11, 2016. A Design News event, Pacific Design & Manufacturing is your chance to meet qualified suppliers, get hands-on access to the latest technologies, be informed from a world-class conference program, and expand your network. (You might even meet a Design News editor.) Learn more about Pacific Design & Manufacturing here.