366: This is modified Agile for hardware development – with Dorian Simpson and Gary Hinkle

How product managers can use the Modified Agile for Hardware Development Framework Today we are talking about using a modified version of Scrum for hardware projects. Many teams have tried adopting Scrum for developing hardware products, not always successfully. This is such as big topic, we have not one but two guests to help us with it—Dorian Simpson and Gary Hinkle. They think they have the answer for applying Agile principles to hardware projects, and they call it the Modified Agile for Hardware Development (MAHD) Framework. Dorian has a deep background in product development, starting in engineering and then moving to business leadership roles.  These include roles at Motorola and AT&T along with dozens of companies as an innovation and product development consultant. He’s also the author of The Savvy Corporate Innovator, which is about applying Agile principles to idea development in organizations. Gary also has an extensive background in product development with senior roles at SAIC and Tektronix. He has held R&D leadership roles and founded Auxilium in 2002 to help companies improve their R&D and leadership practices and transform their new product development using Agile practices. Summary of some concepts discussed for product managers [2:56] Can you summarize Scrum for us and share what aspects of it aren’t suited for hardware projects? Scrum is one of the most widely-used flavors of Agile, mostly applied to software development projects. It starts with describing the customer experience through user stories. Teams work on high-priority user stories in rapid cycles called sprints, deliver working software that is validated by users, and incorporate feedback quickly into the next cycle. This mechanism is great for evolving a product and figuring things out as you go, and those challenges apply to hardware products, but the basic mechanics of Scrum, optimized for software development, are missing some pieces for hardware development. The first missing piece is big-picture planning. Hardware projects almost always have a schedule—the project has to end and the product as to go into production. This end goal and transition to manufacturing requires a big-picture plan, which Scrum doesn’t account for. Scrum also doesn’t account for the dependencies involved in physical products, mostly associated with physical materials’ lead times, which need to be factored into the project plan. Software and hardware have to come together from multiple disciplines, and typically all the pieces can’t come together in a traditional two-week sprint. When companies try to implement Scrum or Agile for hardware, they get hung-up on the mechanics. We focus on four key Agile principles, which give us the benefits of Agile without worrying about the dogmatic, detailed tactics: * Autonomous teams * Timeboxed learning cycles * Rapid prototyping * Engaging with customers In hardware development, user stories have to be looked at differently. The user still needs to benefit from the product, but you can’t directly translate user stories to features of a physical product. User stories are still a valuable starting point to understand the customer, but hardware teams have to shift gears quickly to the physical attributes of the product, the complexities of designing hardware, and regulatory concerns. Some Agile purists tell hardware teams to write a user story for every requirement, feature, and specification, but we don’t know anyone who’s done that successfully. [15:01] How does your MAHD (Modified Agile for Hardware Development) Framework work? One of the big differences between MAHD and Scrum is the onramp, which is a set of five interactive, collaborative activities between marketing and R&D. To get the project started, use an Agile project brief,