And, going full circle, some manufacturing companies are now starting to in turn adapt the same agile practices that have emanated from IT.

The parallels between software and manufacturing are quite striking.

Clearly, software development, like manufacturing before it, was broken.

Studies, such as the Standish Group’s well-publicized Chaos reports quantified the problems that became all too cliche: that software development teams usually deliver project late, over budget, and short of their original specifications or promises.

Other studies have quantified disturbing trends in software quality that were compounded as development teams began embracing distributed systems and rapid application development techniques that often regarded QA as afterthought.

Like IT, for many years, manufacturing was a protected industry and profession until offshore competition applied practices developed in the western world to produce faster, better, cheaper. In manufacturing in the 1980s, it was the Japanese who adapted principles of continuous improvement from Americans like W. Edwards Deming and Joseph Juran. Those practices were enshrined in the famed Toyota Production System, which became the role model of enlightened manufacturing.

Initially practiced as lean manufacturing, where you produced to demand with only just enough inventory to satisfy current demand, it was later broadened to encompass ideas of agility based on increased collaboration.

Fast forward 20 years, change the sector to IT, and the offshore colossus to India, and the parallels are incredibly similar. Incorporating principles developed by the Software Engineering Institute (SEI), Indian firms lined up for their CMM Level 5 certifications, combining labor arbitrage with promises of more disciplined software delivery.

However, drill down deeper, and it becomes evident that the opportunity for agile was rooted in the reality that software teams grew too disconnected from their clients, a problem that offshore development didn’t necessarily solve. Those are similar problems that on the manufacturing side were addressed by lean and agile production, and then adapted by co-authors of the 2001 seminal document, The Agile Manifesto.

Specifically, while lean manufacturing allows you to have a long range forecast for inventory requirements and demand, it forces to you to work with only enough stock to fill firm orders that are in the short-term pipeline. Likewise, agile software development allows you to have high-level requirements and roadmaps for a software project, but only gets specific with stories that are developed for each iteration, or sprint.

Similarly, agile manufacturing encourages cross-functional teams that collaborate in product design, using design for manufacturing principles. Agile concepts are similar in their call for cross-functional teams that assemble just enough developers, testers, architects, and business representatives, who stay in constant contact through each self-contained iteration of development.

Other similarities include lean requirements, which agile calls stories, where you collect just enough information on business needs to get you through the next project iteration or two. And, akin to agile manufacturing’s design-for-manufacturing, many agile practices encourage principles such as design-for-testing. Or XP (eXtreme Programming), another extension of agile, it calls for development of tests based on functional requirements or stories before any code is developed.

According to Paul Hodgetts, CEO of agile consulting and coaching firm Agile Logic, agile development approaches could indeed benefit from some of the practices that emerged with the collaborative product development aspects, rather than the production side of lean manufacturing.

In an email correspondence with us, Hodgetts pointed out that agile practices currently fall short when it comes to engaging business management, marketing, and product management, and they also fall short when it comes to actual deployment. Those are the areas that Hodgetts feels lean manufacturing principles could not only offer some answers, but offer answers that could enable agile methods to spread their footprint from project to enterprise level.

In turn, some at the conference were voicing the idea of having agile go full circle: applying principles of agile development to enterprise business management. Jeff Sutherland, who co-created the Scrum project methodology (an extension of agile) while at Easel Corp. in the early 1990s, delivered a presentation on how agile principles could be extended to product development.

At Headwaters Inc., a manufacturer of high tech products for oil and gas production that grew through M&A from a $20 million firm in 2000 to a $1 billion company today, those principles were applied in practice to development of innovative products such as carbon nanospheres.

Business agility must be one of your core competencies, because that is key to how you can establish leadership in the marketplace, explained CIO and strategic planning director Niel Nickoliasen.

Nickoliasen explained his approach. First he creates a 4-quadrant matrix for determining how much and how fast to invest in a new product idea, with the axes being alignment with the company’s core mission, and the other being degree of differentiation.

Products that score high in differentiation and alignment get preferential budgeting, whereas others that are aligned with the company’s strategy that are not differentiated may be funded, but at lower priority. He implies that the same strategy could be applied to software development or procurement.

Then, as a product is developed, it uses the same kinds of cross functional teams that are the hallmark of agile, as well as the same kinds of short project iterations or stages. And it uses the same kinds of daily planning sessions, and the same adaptive planning from one project stage (or iteration) to the next.

Nickoliasen admitted that there was more than serendipity to this approach. Being based in Salt Lake City, which was also an early hotbed of agile development, I was able to meet frequently with the principals and was able to develop a corporate strategic planning model that was highly adaptive itself.