Agile methodologies revolutionized software design. Can they do the same for hardware development?
MIT Professor of Management Science and Innovation Steven Eppinger doesn't just think so – he knows so and has the receipts.
During a LiveWorx ’23 keynote session, Eppinger shared three ways hardware teams can adopt agile methods to unclog workflows and enable product innovation.
Can agile be applied to workflows that center on CAD?
Why Agile for Hardware?
Agile is a project management and execution approach that emphasizes flexibility, collaboration, and responsiveness to change.
Software companies have relied on the Manifesto for Agile Software Development for over 20 years with sustained success. According to a 2021 McKinsey survey, 65% of organizations across a variety of sectors report a positive transformation after adopting agile practices.
Gains in speed, customer centricity, operations, innovation, employee engagement, and productivity manifest themselves on the bottom line. It’s no wonder then that manufacturers are joining in on the benefits of agile, Eppinger noted.
“My research at MIT has always been about improving engineering and product development processes and lately, it’s taken a turn at looking at agile,” he said.
Through his work, Eppinger has worked with a number of companies in a range of industries, including consumer electronics, telecom, automotive, appliances, package goods, and complex systems.
He outlines four reasons why manufacturers are transforming and applying agile practices to product design workflows.
-
Agile is Already Here: If a company develops both hardware and software, everyone is already exposed to agile.
-
Digital is Preferred: Most professional workers today are digital natives and are comfortable with the agile workflow.
-
Change is Constant: Product development teams work in an environment of uncertainty and change. Specifications evolve, use cases emerge, technical debt is discovered, and supply chains get disrupted. The structure of agile sprints can help teams identify issues and address them faster.
-
New Digital Toolbox: Workflows today are readily supplied by tools, like Onshape, not available 10 years ago, like cloud-native solutions that improve collaboration and communications.
While these four reasons are compelling enough, doubts are sure to remain. How can a methodology applied to software be compatible with the constraints of hardware design and the physicality of building products?
Applying Agile Anywhere
While agile is not a one-size-fits-all solution, aspects of the methodology can be applied to hardware product design.
How? Eppinger describes it succinctly: Adjustment.
Some agile techniques can be easily applied to any team, like a daily check-in or retrospective, but others can be adjusted to fit an organization’s particular development process context.
“We don’t need to apply agile in the same standard way,” Eppinger says. “There are no agile police telling us, ‘Well, you have to do it this way because that’s the way it works in software.’”
He offers three different ways that agile methods can be adjusted easily to better suit manufacturing workflows.
Beyond the following points, Eppinger – along with the insights from Onshape co-founder and Chief Evangelist Jon Hirschtick – provides a deeper dive into agile workflows in hardware development in the white paper “Transitioning to Agile Development: How to Develop Hardware Like Software." Access it for free.
The Secret’s in the Sprint
Agile involves getting work done in time-boxed sprints, which are fixed development periods typically 1-4 weeks long. Each sprint cycle involves repeatable planning, coordination, and review events, e.g., daily scrum, sprint planning, sprint demo, and retrospective.
For hardware developers, adjusting the sprint cadence plays a vital role in the transformation to agile development.
An example of a typical sprint cycle.
Eppinger shares an example of a project at Ford Motor Company. At Ford, software and hardware teams work closely together but operate on separate sprint cadences to give hardware developers the time needed to make substantial progress.
The software team follows a one-week sprint cadence, while hardware developers work on a three-week cadence. Every three weeks, both teams meet for a joint demo and determine priorities for the next sprint.
For companies developing new products and supporting existing operations, switching between two sprint cadences can fit the bill, like at Ministry of Supply. At the online retailer, Eppinger shared, one week is focused on a development sprint. Then, the following week an operational sprint where teams have time to visit suppliers, support market launches, and do performance reviews.
In agile, one size doesn't fit all; adjusting sprint durations, themes, or stories, or reallocating resources can help teams build better project management and processes tailored to their needs.
Setting the Right Goals
Even in software development, the wrong sprint goal might be prioritized, leading teams to a dead end. Software teams using agile can quickly pivot, changing course to get back on track.
The same can’t always be said for hardware design.
Eppinger recommends “decomposing goals” by thinking about and defining long-term strategic objectives, then breaking down major milestones into smaller sprint goals, as Ocado Technology does.
To define sprint goals, for example, team leaders can ask, “In order to deliver a product release in Q3, what does it look like to be halfway there?”
Beyond keeping the team on track with a defined timeline, goals must also be reviewable. In software, the goal at the end of each sprint is to have workable code – not precisely a transferable result for hardware developers.
Hardware teams, however, should aim for a reviewable increment of work in each sprint in place of a releasable product. The results from each review can feed into the next sprint cycle. At Bose, development teams follow a similar method by testing design changes on a prototype before creating a releasable product.
Reviewable increments of work ensure that success criteria are determined ahead of time, and facilitate better collaboration by keeping stakeholders informed and aligned with expectations throughout the development process.
Use Cloud-Native Tools to Support Agile
“Agile depends upon close collaboration within teams and also across teams,” Eppinger says. “Collaboration today is based on certain types of tools, largely cloud-native tools.”
Eppinger mentions the above cloud-native tools that enforce agile methods.
While cloud tools and agile methods are not directly linked, they are highly complementary, especially in today’s world of dispersed teams and flexible work schedules.
“We all know Onshape is the CAD tool that helps teams collaborate without the confusion of file versions,” he says. “Cloud-native CAD allows us to share these models, and sharing is important [for feedback].”
Then, “We bring that feedback into the sprint demo so that we can review the incremental progress” and create better, more innovative products, Eppinger concludes.
Better yet, create an Onshape account for free and see how cloud-native CAD can streamline hardware development and launch more innovative products.
Agile is not just for software; it's a powerful tool for innovation in hardware development as well – and Onshape can be the key to scuc.
Get Started Today
Head to our sign-up page to choose the right CAD plan for you and your business.