Agile for Hardware
FAQ

We have met with many teams who have tried to directly make SW-based Agile methods such as Scrum or SAFe work for physical products, but they struggle. User stories don’t always make sense, dependencies get in the way of strictly prioritizing backlogs and even the definition of a release is different. Agile principles are directly applicable to hardware and provide big benefits, but the tactics of Agile need modification for hardware.

The MAHD Framework can be used for all stages of product development and can generally be categorized as discovery, product development and production/commercialization. Where you’ll see the most benefits are where there are the most unknowns. This at the discovery and product development stages. This is important because if you think of Agile as purely for development execution, you’re missing most of the benefits.

MAHD incorporates the key Agile principles found in all Agile methodologies, including Scrum, with an emphasis on autonomous teams, rapid learning cycles, limited documentation (at least to start), and self-reflection. But the MAHD Framework also has unique and modified elements not found in any SW-based Agile methods with a particular emphasis on up front planning (the On-ramp) and other differences necessary to support hardware development.

We welcome any resource or discussion that contributes to the thinking and mission of Agile for hardware. Please just send us a note and let us know what you’d like to contribute or we can offer suggestions of what we think the agile for hardware teams are seeking.

Yes! We’ll share tools and resources and hopefully others will as well. Our goal is to help others get the benefits of Agile principles in a way that works for you. Agile consultants and organizations can also offer the MAHD Framework under a licensing agreement. Contact us to learn more about this program.

The MAHD Framework has Agile principles at its core, but does consider the needs that traditional phased development processes are meant to address. For example, hardware products need to freeze the design going into production, documentation must be developed, etc. These goals and milestones are part of MAHD Iteration plans that can seem “stage-gate” like. However, the culture, way-of-working, methods for adapting to change, etc. are far different. If you’re using agile methods, such as “sprints,” purely to achieve traditional gate milestones, you’re significantly limiting the power of agile.

An IPAC Iteration is a development and learning cycle comprised of one or more 2-4 week sprints (typically 3-4, but can be highly variable).  During Iteration Planning, the team will determine the length and goals of the iteration and consider at least these four “IPAC” objectives:

• Integration – Which functions and disciplines should integrate in this iteration, what does that mean, and how will we validate the results?
• Prototype – What level of prototype can we develop during this iteration to answer key questions, reduce risk and/or show progress?
• Alignment – Which sub-systems, functions, disciplines, etc. do we need to align with in this iteration and what does that mean?
• Customer engagement – How will get internal and/or external stakeholder (customer) feedback on our progress and get guidance for moving forward?

It depends. Physical products are holistic by nature, but by working in an Agile way, you’ll naturally need to think about how to modularize designs in order to test various elements as needed to reduce risk or validate the design both commercially and technically. All designs can’t be modular, so developing the product “incrementally” can take some creativity.

No. However, you will see more benefits of the MAHD Framework the more prototypes you can do. The ideal prototype cadence is to plan some form of prototype at (or near) the end of each Iteration as determined by the key strategic questions you have identified. A prototype can be anything from a rough sketch to fully functional product and everything in between.

No. Physical features are rarely directly user stories. You want to capture customer needs in the form of user stories, but for the MAHD Framework, these are at the system level where multiple features must work together usually to satisfy them. Review the Intro to MAHD Ebook or 9-step guide for more information.

These and other support elements including product plans and even the final product specifications are all developed on an iterative basis as components of the overall product. They may have separate MAHD teams, but should align milestones, etc. through joint Iteration Plans.

One of the unique characteristics of hardware vs. software is the variety of resources needed to execute. There will typically be a core MAHD team that is dedicated to a project, with many tasks and inputs dependent on part-time or external experts. This is one reason the Agile Project Manager is such an important role – to manage these resources, explain how the development is working and gaining commitment for tasks that might need to be modified for an Agile way-of-working.

The MAHD Framework uses variable length IPAC Iterations so that needs of the project and team drive the length of the iteration. If you need more or fewer sprints to get to a great milestone, then that’s what the iteration length should be. If you find it difficult to plan variable length iterations, a fixed cadence is okay, but it forces an artificial time-frame versus a needs-driven plan.

Here are some characteristics of a project that usually provides a good pilot to start:

1. 1. Expected duration of 9-12 months from start to launch
   2. The project has some unknown requirements or areas you want to innovate
   3. You have a near full team ready to start, including a product manager or owner
   4. The number of team members is 5-12, which means you can operate as one MAHD team

To start your pilot, learn the principles and methods, identify roles, develop your Agile Project Brief and go. Be sure to capture learning along the way (designate someone to document progress).

A great way to try out the MAHD Framework is to pilot a project. Gather the team, learn the principles and tools and get started. A small to medium-size project is a good place to start. Don’t get discouraged if you fall back to old ways. Identify what worked and build on it.

While not absolutely required, it is highly recommended that marketing is involved in your Agile transformation from the beginning.  They are responsible for developing the Agile Vision Brief, prioritizing customer needs, etc. If marketing is not involved, then you are left with a development team operating in short cycles, but not really getting the benefits of Agile.

Many people who only have a cursory understanding of Agile principles believe it is a “software only” process.  To convince management that Agile works, the best way is to initiate a pilot and show them the advantages. Start with, “We think Agile might be a better way (share benefits). We’d like to take a small team, try this, and document the results of what worked or didn’t and share our findings. Is this OK?” Few managers would say no to this request.

While being in the same location is always helpful, the reality is that many teams have distributed members. By using online tools such Miro or Mural, teams can conduct virtual on-ramp, iteration and sprint planning with few problems.

Each company has some mechanism to approve a project. This is typically a business case, that once approved leads to more detailed requirements (PRDs), etc. This is often a long process, riddled with misplaced assumptions.  With MAHD, the objective is a fast start in the right direction with requirements evolving through the early iterations of the project. As you implement Agile methods, the front end of project approval should be reviewed for what is REALLY needed to initiate the project.

All five of the On-ramp steps are recommended since they are collaborative activities designed to literally get everyone on the same page and off to a great start. For small projects, it’s best not to skip steps, but to take a lighter approach if you can, such as a simplified Focus Matrix or writing limited user stories.

The Focus Matrix is designed to drive collaborate discussions around the connections of customer needs and product attributes. It’s not important to include every customer need and attribute, but to identify at least two types for each.

For customer needs, include:

1. 1. The highest priority customer needs – What will drive market success?
   2. The biggest unknown customer needs – What don’t we know?

For attributes, it’s important to ask and include:

1. 1. Which attributes (categories) will satisfy the highest priority user stories?
   2. Where must we innovate or make significant improvements?

A rule of thumb is that you should have 10 or less on each axis to keep it manageable.

The Iteration Plan is the big picture of the project. They can quickly start looking complex, so it’s important to focus on the most important milestones, dependencies, questions, areas of focus, etc. to track and refine with each Iteration. As a minimum the team must have consensus about the plan for the first Iteration before getting started. Ideally there is also consensus about what the final Iteration needs to achieve (or some major interim milestone) and the timeframe.

Please don’t. Gantt Charts are difficult to develop and maintain, and provide a false sense of accuracy. Using an Iteration Plan and Backlog allows the team to plan their work while always focused on the big picture. This does change the role of the Project Manager so they must build facilitation skills more than Gantt Chart editing skills. Identify and manage critical dependencies in the Iteration Plan. A scheduling tool can be helpful for managing complex dependencies, but don’t create a complete Gantt Chart.

Developers who are accustomed to receiving complete requirements, architecture docs and even specifications can be uncomfortable with the uncertainty built into Agile methods. You should satisfy their needs as possible, but ask, “What are your major concerns? What is the minimum we can do to get started that will make you comfortable?” Often it is a much smaller scope of information than you might have provided in the past under waterfall processes.

Some roles can remain the same, others modified, some new:

1. 1. Developers keep their roles, but could also take the role of MAHD Master.
   2. Project Managers should become Agile Project Managers and build new Agile and facilitation skills.
   3. Product Managers keep their roles, but how they operate should be modified. They might become Product Owners, but not always. This depends on the size of the project, how their role is currently defined, etc.
   4. New roles should be considered such as MAHD Masters, Agile Program Managers, Agile Portfolio Managers, etc. depending on how broadly you deploy the MAHD Framework.

Traditionally, a Product Manager researches the market, builds business cases, writes PRDs, works with R&D to guide development and develops marketing plans. These organization needs don’t change. A Product Owner will prioritize user stories, guide Iteration Plans, drive validation activities and is usually closer to the day-to-day team environment. How you define and structure these roles is up to you. Download our guide to roles to learn more.

“Is this attribute good enough?” is the most strategic question the team can ask on a sprint by sprint and iteration by iteration basis. Some guidelines to answer “who should make this call” include:

1. 1. For sprint level decisions, this is likely the Product Owner for customer-facing attributes and technical leads for technical attributes
   2. For Iteration-level decisions, this is likely the Product Manager

If the team is unsure, especially for strategic attributes, then the question should go higher in the organization to ensure key stakeholders are comfortable with the decision.

The traditional project manager who is responsible for tracking project action items,  developing Gantt Charts, work break-down, etc. is the role that changes most as you make the transition to Agile methods. This person must learn new skills in addition to their current ones to facilitate planning sessions, drive Iteration Plans, manage backlogs, etc.

The Scrum Master in software development is primarily a coaching role. They make sure the team is humming along, facilitate retrospectives and coach others on agile methods. This role is often also a developer with sprint-level tasks. With cross-discipline MAHD teams, this role is similar and could also be one of the developers who would like the responsibility, but might be in any function such as mechanical, design, electronics, testing, etc.