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:

1. Autonomous teams
   
2. Timeboxed learning cycles
   
3. Rapid prototyping
   
4. 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, which is a one-to-three-page document that describes the customer, market targets, timing, price points, decision factors for customers, positioning in the market, etc. This kickoff gives you a clear understanding of what you’re trying to accomplish.

Next, look at user stories and physical attributes of the product. We use a tool called a focus matrix, which allows us to see how user stories relate to product attributes. Using the focus matrix is a collaborative team exercise. Identify the areas of focus and where to remove risk.

Next, create an iteration plan, which is the pig picture of the project that replaces a detailed Gantt chart. Look at the areas of risk, major strategic questions and where you want to answer them, rapid prototyping, and customer engagement. Identify the right place to bring those components together to create a prototype you can put in front of customers to get the feedback loop going.

After this, the tactics are similar to Scrum. You work in timeboxed execution cycles, working through tasks as a team. However, with hardware projects, you have multiple sprints working toward a higher-level iteration or alignment point where you bring together hardware and software.

[20:10] What are the benefits of the MAHD Framework?

The iteration plan helps teams communicate. Backlogs can make people’s heads spin; the iteration plan operates at a higher level than sprints, so you can communicate the big picture of what you’re doing when. Any manager or stakeholder can comprehend the iteration plan.

The MAHD Framework allows teams to learn about risks and problems early on, enabling the team to redirect. The collaborative team environment, where teams are learning together over short cycles, is much more powerful than just letting things go and assuming they’ll be okay over a long period. The two-week sprint cycle and team accountability force the team to get urgent action items done.

[26:47] What’s an example of using MAHD on a project?

We worked with a thermal imaging company that, prior to using MAHD, took six to eight months to get the product requirements document (PRD) approved, spent a lot of time on detailed Gantt charts, and still had R&D complaining that marketing didn’t know what they were asking for. They began using the MAHD Framework and worked through the first onramp, and some people were not comfortable with the uncertainty. They took a while to get comfortable with not having all the specifications and learning during the first few iterations. They needed to answer some big strategic questions about the core technology, like the image resolution the customers needed. MAHD allowed the team to work with more uncertainty, and they got their kickoffs down to two months. They have greater confidence their product is right for their customers because they’re working through alignment points, customer engagement, and prototyping.

[30:34] What are the reactions of teams using the MAHD Framework?

More than once, managers have told us their teams are happier using MAHD, as well as more focused and collaborative.

Action Guide: Put the information Dorian and Gary shared into action now. Click here to download the Action Guide.
Useful links:

• Learn more about the MAHD Framework and get a free membership and resources
  
• Learn more about Gary, Dorian, and their consulting company, Auxilium
  
• Connect with Dorian and Gary on LinkedIn
  
• Check out Dorian’s book, The Savvy Corporate Innovator
  
• Download the MAHD Overview for Executives PDF
  

Innovation Quotes

“Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features.” – Steve Jobs

“Marketing and innovation produce results; all the rest are costs.” – Peter Drucker

Thanks!

Thank you for taking the journey to product mastery and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it using the social media buttons you see below.