We’ve talked with companies in over 20 countries (and counting) in product categories ranging from electronic toys to military contractors who are all in various stages of applying agile methods to their product development efforts. What each company who is using Agile for Hardware has in common is a need to develop products faster, manage changing requirements and increasing their focus on real customers.
Below we share some of the rationale for why the Modified Agile for Hardware Framework is necessary along with some of the common objections we hear.
Agile is used by a majority of software teams, but is quickly being adopted for hardware-based efforts. The reason Agile has been adopted so quickly in software is that they needed something better.
While most teams struggle with traditional waterfall methods, SW teams were asked to follow processes like Stage-gate that were designed for hardware with little consideration that software is different. Features can be added incrementally, testing with real users to get feedback is straightforward and software can be modified as you learn. Waterfall methods support none of these, so a better solution was essential. Agile’s learning cycles, team orientation and backlog prioritization methods are a much better fit.
Hardware-based product development (including those with significant software functionality) needs have changed where rapid prototyping is possible and necessary, teams need to quickly adapt to changing requirements, and customers still need to experience solutions to provide meaningful feedback. Agile principles work well to satisfy these increasingly important needs, but just as Stage-gate was not designed with software in mind, Agile was not defined for hardware needs. So not only are the benefits of Agile less obvious for physical products, attempting to implement Agile without modifications can be unproductive at best and even disastrous.
The objections to adopting Agile for hardware we often hear:
“Agile won’t work for hardware. Period.”
“We can’t break our work down into 2-week sprints. Hardware doesn’t work that way.”
“We can’t develop a working prototype every sprint. Who has those kind of resources?”
“There are too many dependencies, lead time issues, shared resources, (fill-in-the-blank) for hardware that Agile can’t handle.”
These objections are well-founded if you try to apply Scrum or other Agile for SW directly to hardware. We hear from companies every day who develop physical products ranging from furniture to medical diagnostics equipment. They see the problems with traditional processes and the benefits of Agile, but find it difficult to visualize how they would work. Many companies have even struggled for years to adopt Scrum, SAFe, or other Agile for software approaches to their hardware efforts leaving them jaded on the while Agile concept.
Many companies are having tremendous success with Agile for hardware methods. Some are just beginning their Agile journey with the MAHD Framework and others have matured to consistently better results over previous methods. We know immediately whether the company has a chance for success. Those who focus on the core Agile principles and modify their culture, behavior and ways-of-working to build on these principles will be successful. Those who are trying to fit the tactics of Agile into an existing NPD framework or directly applying Agile for SW methods will not. The principles are sound, but tactics of Agile must be modified whether you apply the MAHD Framework or design your own.
The most common question we get is how to get started. You’ve likely spent years refining your Stage-Gate, Lean, Sig Sigma or other processes. With MAHD, none of these need to be completely discarded. In fact, MAHD builds on each of these and can seamlessly be integrated with little disruption if you take an incremental approach and focus on the principles first. Your objective should be to take the best elements of each to create a holistic, end-to-end new product system that:
Drives focus and efficiencies
Delivers products and services that delight customers
Enables identification and execution of innovative opportunities
Allows you to rapidly learn and adapt to changing competitive and customer factors
Enhances collaboration and team synergies
Your processes shouldn’t run your company. Just like a great sales person never comes across as a sales person, your process should almost be invisible to your company. Teams and leaders should know what to do and how to do it not because of a process document, but because the methods and activities make sense and get the desired results.
To learn quickly if MAHD is right for you, try these basic steps:
Identify a pilot project and team. Select an important, but not mission critical small to medium-sized project. Ideally involve 5-12 cross-discipline team members to plan and execute as one MAHD team.
Learn about the MAHD Core Framework. Download the e-book, steps and other resources. Assign roles and keep minds open.
Try it. Develop your Agile Project Brief, gather the team and execute the MAHD On-ramp steps until you have an Iteration Plan and initial backlog.
Document learning. At each step ask, “What works here? What doesn’t?”
Improve and expand. Develop the next pilot or roll out more broadly with your improvements.
Transformation is never simple, but the benefits will be worth the effort.
If you’re considering a trial of the MAHD Framework, Auxilium (the founders of the framework) has developed a range of cost-effective programs to get started quickly. Go here for more suggestions on how to get started.
If you’d like to discuss your situation, get an overview of the MAHD Framework or learn more about the options to get started, the fastest way is to set up a 45-minute video discussion with one of our evangelists.
Register for the MAHD Community to get access to member resources and new tools and tips directly to your email.
