If you’ve been reading this blog for the past few months, you know I’ve ben pulling a number of findings from the PLM Study that we conducted in January. The most interesting of those findings have had nothing to do with technology, but have provided insight into the organizational performance of engineering. In this post,
Should mechanical engineering companies adopt an agile-oriented paired design approach?
That question has been raised a lot lately and it’s a pertinent one, as agile has gained an enormous amount of popularity in the world of software development over the last 12 years.
At first blush, the method appears a natural for product design. It’s used for complex projects that have ever-changing needs and requirements, which can’t be fully predicted or estimated at the project’s beginning.
At second blush, the method’s potential move from software development to product design raises some questions. The agile approach calls for teamwork, collaboration, and adaptation. It breaks tasks into small increments that don’t call for long-term planning. Iterations are short, and cross-functional teams work on all parts of the task, including planning, analysis, and design.
Agile doesn’t fully mesh with the mechanical engineering world. Product developers need to build in lead time for parts procurement and work with suppliers who aren’t part of the development cycle. While software developers can work in tandem on projects and in cross-function teams, that’s not true for mechanical engineers, where products might include electrical components, molded parts, circuitry, and experts from many other fields. Engineers also need to be in touch with those in the manufacturing, to be sure the part can be built as designed. Teams with such disparate members can’t realistically work in sync.
But the method can certainly be customized to the initial design approach and I’m guessing would eventually be met with the same enthusiastic response it gets in the software development world.
Design and analysis
Certainly agile can be used during CAD design, where iterations can be short and engineers can work together in bursts on specific designs, parts of the design, or assemblies. In this way, engineering teams needn’t be cross-functional. They could break design tasks down into short iterative cycles, each of which might end with analysis and virtual prototyping, until the product is ready for release.
The release, in this case, would be to the larger team at the company. That team might include members from manufacturing, marketing, quality control, and the like, who would give feedback. Depending on feedback, the engineering team might need to iterate again in the original manner to refine the design.
At any part of the cycle, design engineers would still to order new components and wait on parts. That piece is impossible to take out of the cycle.
All that is a long-winded way of saying: yes. Agile development can work for mechanical engineering organizations, but with customization and refinement.
I haven’t found any literature quantifying cost or time-to-market savings at engineering companies who have adapted this approach. I have found that some companies tested it and continued to use it.
Because it can be hard for engineers, like everyone else, to adapt to change, getting the agile process up and going and getting engineers’ buy-in would likely require a trial run at the company.
Software developers have found agile to be a great improvement over the formerly used Waterfall method and mechanical engineers just might find the same.