MAHD
™
The Benets of Agile, the Needs
of Physical Product Development
By Dorian Simpson and Gary Hinkle
An Introducon to
Modied Agile for
Hardware Development Framework
WWW.MAHDFRAMEWORK.COM
2
An Intro to Modied Agile for Hardware Development
CONTENTS
THE GOALS FOR THIS E-BOOK:
1. Provide an introduction to the Modied Agile for Hardware Development
Framework.
2. Explain the key dierences between hardware and software Agile methods
and why a modied approach is both desired and necessary.
3. Explore the major elements of the MAHD Framework and what makes it
unique from Scrum or other SW-based Agile methods.
4. Share tips on how to get started with the MAHD Framework.
Introduction to the MAHD Framework 4
Roles and Project Kicko 6
The MAHD On-ramp 8
Scaling MAHD: An Overview 15
Scrum Vs. MAHD 16
Getting Started 17
The MAHD Team 18
What's Inside
Copyright and Trademark Notice
All MAHD Framework™ content is protected by US and International copyright laws. This material
may not be reproduced, distributed, transmitted, displayed, altered, or published without the
prior written permission of MAHD Framework LLC.
3
An Intro to Modied Agile for Hardware Development
INTRO TO MAHD
Is Agile Right for Hardware?
INTRODUCTION
Agile methods have taken over the software industry. Developers and leaders have discovered
that traditional waterfall processes don’t work because the upfront unknowns are too signicant
to accurately write requirements and estimate work. So a new way — Agile — was created and
embraced. All good. But what about products that have mechanical and electronic components?
Can products that range from trash cans to complex medical devices benet from Agile’s
benets? Yes. The principles are sound, but Agile was not designed to work for hardware, just as
traditional waterfall processes were not designed for SW. Agile methods require modication to
support the needs of hardware products where making changes are costly, partial products are
dicult to test with real customers and denitions must be frozen for production. This led the
need to develop the Modied Agile for Hardware Development (MAHD) Framework — an Agile
initiative to gain the benets of Agile while recognizing hardware’s unique needs.
Before moving on, consider the following questions and answer for yourself, “Is Agile right for
your hardware development eorts?”
1. Is it dicult to get clear product requirements before development starts?
2. Does risk accumulate throughout the development cycle as milestones are missed
and changes force rework?
3. In order to get accurate and valid feedback from customers, do customers need to
rst experience your product?
4. Is market success based on innovation in several focused product areas or key
specications?
5. Does management need clear guidance from the team on where the primary project
risks are and the plan to mitigate these risks?
6. Do individuals or teams wait long periods before their work is validated or
integrated into the product?
If you were able to answer "yes” to most of these, then the Modied Agile for Hardware
Development Framework may be a good t for your organization.
In the following sections, we’ll address each element of the MAHD Framework, why it’s dierent
than SW-based Agile methods and how you can get started applying Agile principles to your
development eorts.
4
An Intro to Modied Agile for Hardware Development
The MAHD Framework - An Introducon
The MAHD Framework uses the principles of Agile to develop physical products in less time, with
reduced risk and with higher customer satisfaction. Many companies have attempted applying
Agile for SW methods directly to physical products with mixed results. Teams often struggle
since current Agile steps, techniques and even language were not optimized for hardware
development. A modied Agile approach can leverage the power of Agile, while addressing the
unique needs of hardware development.
As shown in the framework on the following page, MAHD has many elements of Agile that may
be familiar to you. Developers start with user stories, a backlog is kept to prioritize tasks, and it
includes iterative development cycles. But there are also key dierences. A summary of these
include:
THE MAHD ON-RAMP
One of the basic principles of Agile is to develop very little formal documentation to keep
the team focused on the most valuable activities. This is true of Agile for hardware methods
also, but the nature of physical products requires additional upfront planning steps and often
more documentation.
ITERATIONS AND SPRINTS
Just as with Agile for SW methods, the MAHD Framework has at its core the concept of short
development and learning cycles. But as the model below shows, the MAHD Framework
includes two levels of cycles that must be considered to accommodate the needs of hardware
development.
TEAMS AND DECIDERS
Another foundation of Agile is the use of small autonomous teams led by product owners
and "Scrum masters" with as little governance as possible. Again, this is similar for hardware,
but the teams, project leaders and deciders often have dierent roles, titles and focus.
In the following sections, we describe the core of the MAHD Framework focusing on a single
project. As you extend MAHD to more products and larger systems, MAHD can also scale to any
level of complexity as summarized in the nal section. To explore an interactive model of the
Complete MAHD Framework, visit: www.mahdframework.com
For those familiar with Agile for SW methods, page 16 has a comparison of the MAHD Framework
versus Scrum, the most commonly used Agile for SW methodology.
INTRO TO MAHD
SIMILAR TO AGILE FOR SW METHODS, BUT WITH CRITICAL DIFFERENCES
5
An Intro to Modied Agile for Hardware Development
The Modied Agile for Hardware Development Framework uses the principles of Agile for SW, but has
signicant dierences to support the unique needs of physical product development.
MAHD FRAMEWORK
6
An Intro to Modied Agile for Hardware Development
GETTING MAHD
MAHD ROLES: Similar, but Need Modicaon Too
Before diving into the elements of the MAHD Framework, let's look at some of the roles dened
in Agile methodology and how these roles might be dierent for HW projects. Rather than focus
on the wide range of titles, we will focus on four types of roles - deciders, leaders, doers and
facilitators.
As the diagram shows, the roles are similar, but there are a couple of important distinctions.
The rst is the "decider" role. For software, deciders are typically dened as a Product Owner.
This person writes user stories, prioritizes the backlog and approves all sprint tasks. They
represent the customer in all aspects of sofware development. For HW this role will often be
lled by a Product Manager. This person may or may not work as closely with execution teams
as SW Product Owners. They must understand and consider the whole product with all of the
integrated components and make decisions that may have cross-functional implications.
Another clear dierence in the MAHD Framework is the "facilitator" role. Software often denes
a Scrum Master that has deep expertise in software development. For HW, we need someone
who can manage across disciplines. This is often a project management role, but MAHD denes
a MAHD Project Leader as one who must also be skilled in the MAHD process to guide everything
from backlog development to successful iteration planning. The specic titles are not as
important as determining who will lead teams, who will make decisions and who will facilitate
the process.
MAHD: ROLES
Leaders
Those who lead and manage
functional teams.
SW: Development Leads
HW: Technical Leads
Deciders
Those who dene the product and
make tough priority decisions.
SW: The Product Owner
HW: MAHD Product Manager
Facilitators
Those who drive the process.
SW: Scrum Master
HW: MAHD Project Leader
Doers
Those who do the work.
SW: Developers, testers, analysts,
designers, etc.
HW: Developers, engineers, testers,
designers, etc.
Learn more about MAHD roles by visiting us at:
WWW.MAHDFRAMEWORK.COM
CD Team
7
An Intro to Modied Agile for Hardware Development
GETTING MAHD
Kicking O a MAHD Project
One of the goals of Agile methods is to enable faster project kickos. With traditional methods
it can take months to build a business case to gain project support, more time to develop a
"complete" Product Requirements Document (PRD) and then more time for marketing and R&D
to negotiate features and develop detailed schedules. Most of this time is wasted on things the
company already knew, assumptions that never get tested and schedules no one believes.
To kick o a MAHD project, a better approach is to use a light product-market description document
that provides concise information the development team can use to get started. The “MAHD Vision
Brief” shown below summarizes the market situation, claries the customer and their needs,
establishes project goals and identies the high level value drivers that lead to purchase in the
market. The example shown here is from
our Step-by-step guide to MAHD
which follows the JavaBrew team
as they use MAHD methods to
develop a new, innovative coee
maker.
Transforming to Agile methods
often does require a change to a
company's culture including getting
more comfortable with uncertainty
and having trust that the team
will evolve the product in the right
direction as they learn. In the next
section, we'll look at each step of
the MAHD On-ramp which provides
a set of ve collaborative activities
designed to:
1. Quickly get marketing and
R&D teams on the same page
2. Identify the aspects of the
project that will lead to
success and/or create risk
3. Develop a high-level plan to
begin execution
MAHD: KICKOFF
To learn more about this tool, download our 9-part Step-by-Step Guide:
WWW.MAHDFRAMEWORK.COM
MAHD Vision Brief
8
An Intro to Modied Agile for Hardware Development
Preparing for Project Success with the On-ramp
ELEMENTS OF THE MAHD ON-RAMP
1. User Stories - Hardware companies
attempting to apply Agile struggle with
user stories. MAHD addresses this by
taking a system approach to user stories
when dening physical products.
2. Product Attributes - While Agile for
software does away with requirements
(which are replaced with user stories),
product attributes still have a necessary
purpose in Agile for hardware.
3. Focus Matrix - This is a new element to
Agile introduced in the MAHD Framework
and builds a necessary bridge to drive
iteration planning, Agile thinking,
innovation and development focus.
4. Iteration Plans - Similar to a SW release plan, but quite dierent. The MAHD Framework
uses two levels of development cycles. MAHD Iteration Planning and IPAC Cycles create the
game plan for success while sprints provide the execution details.
5. Task Backlog - Notice that this is not the product or feature backlog. It’s dierent, but
related and focuses on specic team tasks that must be accomplished each sprint.
While these activities may look like early stages of a waterfall-oriented process, this doesn’t
mean the team writes a detailed product requirements document, a complex Gantt chart or
gets sign-o by 12 managers. It does mean that the team has thought through the project
details in enough depth to condently get started with Agile development.
One of the major challenges that the MAHD Framework addresses for hardware is the need
to think about the whole project before getting started with execution. Designs, architecture,
dependencies, high-level iterations and even the schedule need to be considered before diving
into the work itself.
As we'll describe, the MAHD On-ramp may take a few days or up to a couple of weeks, but the
results are well worth the eort in setting the team up for success. While many of the elements
are similar to those found in Agile for SW, each element must be reconsidered and we'll
introduce several new elements to the MAHD Framework to support hardware development
eorts. The following pages will look at each of these in more depth.
MAHD: ON-RAMP
IT MAY LOOK "UN-AGILE” BUT HARDWARE REQUIRES DEEPER UPFRONT PLANNING
CD Team
ON Ramp
User
Stories
1
As a user...
As a user...
4. log log log log
As a user...
Product
Aributes
2
Architecture...
Funconal...
Targets...
Non-funconal...
3
Focus
Matrix
User story...
User story...
User story...
4. log log log log
User story...
Iteraon
Plan
4
Task
Backlog
5
Epic
Task
ub-task
4. log log log log
Sub-task
Epic
Task
Sub-task
Aributes
9
An Intro to Modied Agile for Hardware Development
Rethinking User Stories for MAHD
HARDWARE FOLKS STRUGGLE WITH USER STORIES... AND FOR GOOD REASONS
MAHD: USER STORIES
User stories are a critical starting point for Agile for SW methods since they provide the backlog
items, are groomed directly into features and sprint tasks and form the basis of the product
denition. In essence, user stories ARE the product requirements for software. For hardware we
need to rethink this. For example:
User stories go something like this...
"As a user, I want to be to able to quickly log in so that I can access my account.”
Software developers know what to design and almost how to implement it.
Now let’s try it for hardware. Let’s assume you’re planning to develop a new fork lift and you
write this user story:
"As a user I want to be able to quickly pick up my material so
that I can save time moving inventory.”
Does a developer of hardware know what to do? Probably
not. There are too many facets of the problem to solve. The
implementation might involve the speed of the fork lift, the
accuracy of the fork attachment, the orientation of the inventory
and many other factors. Rather than specic features or tasks,
these user stories for hardware become customer goals, rather
than product requirements.
USER STORIES ARE STILL VALUABLE, BUT INSUFFICIENT
The previous example might lead you to think that user stories are not appropriate for physical
products, but this would take us too far back to traditional waterfall methods where customer
needs often take a back seat to the desire to develop detailed product requirements.
User stories have their place in the MAHD Framework and are necessary to create a focus on the
needs and priorities of customers as well as to clarify results customers are trying to achieve.
However, since user stories for physical products cannot typically be directly translated into
features, functions or tasks, they become the starting point for developing a task backlog rather
than backlog items themselves. Once you have written MAHD User Stories, it takes several more
steps to identify the specic backlog tasks.
Next, we’ll need to consider some of the hardware-centric steps that you won’t nd in Scrum or
other SW-based Agile processes — product attributes and the focus matrix.
Prioritized
User Stories
User
Stories
1
As a user...
As a user...
4. log log log log
As a user...
10
An Intro to Modied Agile for Hardware Development
Product Aributes: Describe It, But No PRDs
Just the term "requirements” is almost anathema to Agile purists. They know that customers
typically don’t have requirements, they only have needs and goals to accomplish that can be
described as user stories. But hardware is dierent. Physical products often have limitations
in components, must meet target specications or must accommodate pre-existing interfaces.
Certainly we could describe the details through user stories, but this approach is tedious to
document and obscures the purpose of user stories.
For example, if we consider our forklift user story again,
"As a user I want to be able to quickly pick up my material so
that I can save time moving inventory.”
We could enumerate the specics of the features and functions
to satisfy this user story with more user stories, such as,
"As a user, I want the fork lift to be able to lift materials at a rate
of three meters per second."
This is not really a user story, but more of a target specication
or perhaps part of the acceptance criteria of the user story.
To be clear, we are not advocating that MAHD Framework
practitioners write detailed product requirements documents that are associated with waterfall
processes. However, concisely describing the product vision and rough architecture as well as
major anticipated functional and non-functional product attributes is important as we'll see in
the next step. Keep in mind that "attributes" as dened in the on-ramp aren't rigid specications,
but really just a high level summary of what might be expected to be in the product to act as a
starting point to seed the Agile process and guide it in the right direction. Each attribute will get
rened into specic features, functions and requirements that satisfy customer needs (the user
stories) as the MAHD process moves forward.
To summarize, without describing the product attributes at some level during upfront planning
it will be dicult to continue with the on-ramp and develop the backlog of tasks as well as to
identify areas of functionality that will be used for iteration planning, prototyping and the focus
of innovation eorts.
MAHD: ATTRIBUTES
Product Attributes
WRITING PRODUCT REQUIREMENTS IN AN AGILE WORLD
Product
Aributes
2
Architecture...
Funconal...
Targets...
Non-funconal...
11
An Intro to Modied Agile for Hardware Development
Driving Development Priories with Focus
The Focus Matrix is a MAHD element you won't nd in any version of Agile for SW methods since
it is not necessary for SW development (but SW teams still nd it valuable.) However, matrix
thinking has been a powerful tool for hardware development for decades and is valuable for
Agile for hardware planning for one good reason — user stories will be satised by a range of
product attributes, and various product attributes will contribute toward satisfying a range of
user stories.
This n-to-n relationship cannot be documented,
understood or analyzed without some form of
relational matrix. For those who have studied Total
Quality Management (TQM), you may be aware of
the House of Quality. This matrix planning tool is
used to dene the relationship between customer
desires (user stories in Agile terms) and product
capabilities (features). While the TQM House of
Quality is far too complex for Agile purposes, the
rationale behind it is critically important and can
help MAHD practitioners focus on the most important
tasks.
Considering the diagram on the right, the MAHD Focus Matrix has two dimensions. The left
hand side of the matrix shows prioritized user stories. These are customer needs and goals. On
the top of the matrix are the range of prioritized functional attributes from our rst two steps of
the on-ramp. The relationships between these factors become the basis for iteration planning,
prototype plans and dependency identication.
Consider our fork lift example. The user story, ".... quickly pick up my cargo..." would appear
on the left and could be satised by a range of attributes that will be organized on the top,
such as: The speed of the lift, the lift attachments, the accuracy of steering, optical recognition
to determine the orientation of the inventory, etc. The team would then determine which
attributes contribute to satisfying the highest priority user stories and develop a plan of
execution for how to prototype the attribute, what questions need to be answered and how to
get customer feedback.
Successfully working through the Focus Matrix leads to the next MAHD On-ramp activity,
iteration planning. The result becomes the high-level project plan that is necessary for managing
risk, schedules, resources and critical IPAC milestones.
MAHD: FOCUS MATRIX
FINDING IMPORTANT CONNECTIONS BETWEEN USER STORIES AND ATTRIBUTES
MAHD: FOCUS MATRIX
3
Focus
Matrix
User story...
User story...
User story...
4. log log log log
User story...
Aributes
MAHD Focus Matrix
12
An Intro to Modied Agile for Hardware Development
Iteraon Planning in a MAHD World
MAHD: ITERATIONS
CONNECTING USER STORIES, REQUIREMENTS AND ITERATIONS
As discussed earlier, at the core of any Agile methodology are iterative development and learning
cycles. For Scrum-based Agile for SW, "sprints" last from 1-to-4 weeks and result in working
software that can be demonstrated to users. The MAHD Framework modies this concept and
considers two levels of iterations. At the high level are IPAC Iterations. These iterations lead to
larger deliverables where components of the solution are integrated and a key result is often
a demonstrable prototype that can be viewed and validated with internal and/or external
stakeholders (i.e. customers).
The MAHD Framework also uses shorter execution cycles
within IPAC iterations. These are 2-to-4 week MAHD
sprints. The distinction is important for hardware-
oriented products since it is unlikely you'll be able to
create a demonstrable product with every sprint that
can be put in front of customers, but working toward
prototypes at the higher level iterations is critical to being
Agile. Without customer interaction at key phases of
product development, you will, by default, be reverting
back to waterfall practices.
To develop an iteration plan, consider four types of
milestones for each IPAC Iteration:
1. I - Integration - What is the right timing and functionality that should be integrated from each
discipline (electronics, software, mechanical, etc.) as well as what technical questions need to be
answered?
2. P - Prototype - How will you develop a prototype plan at dierent levels of sophistication
in order to gain real customer insight? (Prototypes can range from drawings to nearly full
functionality.)
3. A - Alignment - What are the major dependencies or stakeholders you need to get aligned at
each point?
4. C - Customer - What key questions do you need to answer to validate customer acceptance and
what is your feedback plan to answer them?
Back to our fork lift example. Let's assume you decide that determining the orientation of
inventory is crucial to satisfying a high priority user story. You then plan to focus on developing
a solution and early prototype in an early iteration in order to validate the technology and
customer acceptance. As you plan for iterations, this level of prototype might not be possible
for several iterations, so you decide an early iteration deliverable will include an animated video
explaining and demonstrating the solution for customers to get early feedback.
At this point of the MAHD On-ramp, you're not planning detailed tasks or sprints, but only
identifying important IPAC milestones, key questions, major risks, etc. that will then be broken
down to develop your MAHD Task Backlog.
Iteration Plan
Iteraon
Plan
4
13
An Intro to Modied Agile for Hardware Development
Developing a MAHD Task Backlog
MAHD: BACKLOG
IT'S TIME TO DEVELOP THE INITIAL SET OF BACKLOG TASKS
After reading about the previous four elements of the MAHD On-ramp, you may be thinking that
these activities will take a long time. However, completing on-ramp activities should only take
from a few days to a couple of weeks depending on the complexity of your project. This is still
a fraction of the time that the typical product requirements phase of a waterfall project takes.
While there are many details left undened, you'll have a very clear picture of the vision, the
customer, the high level roadmap and the overall project plan. You're now ready for the nal
on-ramp activity - developing the MAHD Task Backlog.
As mentioned before, the backlog in Agile for SW methods is
a combination of prioritized user stories, engineering tasks
and features. For the MAHD Framework, the backlog is similar,
but has distinct dierences. A user story will not typically
be a specic backlog item. A feature may be listed as a task,
but generally the MAHD Task Backlog is a prioritized list of
engineering and design tasks that are related to product
attributes and satisfy user stories.
To refer back to our fork lift example, the backlog might
include:
1. Investigate open-source optical recognition solutions
appropriate for fork lift applications.
2. Design new gearing to increase fork lift speed and accuracy.
3. Design new fork lift attachments to accommodate the largest
number of material conguations.
4. Etc.
As the backlog is groomed (meaning claried, estimated and the addition of acceptance criteria),
you'll likely determine that many high-level tasks, such as the third one, "Design new fork lift
attachments..." will need to be broken down further into tasks that can be accomplished in a
single sprint. You could also make this task an "epic" and add tasks and sub-tasks such as:
• Identify the most common pallet congurations, dimensions and variations
• Identify Amazon's inventory sizes and conguations (assuming Amazon is a target
customer)
• Etc.
Once your MAHD Task Backlog is ready (and it's never complete as you learn and add items), you
can then begin planning your rst sprint and you're o and running with MAHD.
Task Backlog
Task
Backlog
5
Epic
Task
4. log log log log
Sub-task
Epic
Task
Sub-task
14
An Intro to Modied Agile for Hardware Development
The Daily Grind: Planning and Execung Sprints
When most people think of "Agile," they imagine short development cycles where small teams
commit to and deliver a set of features selected from a backlog. This provides the foundation
of Agile methodology and executing MAHD sprints is similar. The only dierence is that the
development teams are selecting from backlog tasks that often look quite dierent than
software features. Tasks may include specic features, but they are more likely to be technical
investigations, design work, prototype building, integration of components, selection of a vendor,
documentation for BOMs, etc. These tasks are aligned with the activities necessary for physical,
mechanical and/or electronic designs and combine to build features and satisfy user stories.
MAHD: SPRINTS
When planning for sprints, MAHD cross-functional teams will review the task backlog, clarify
tasks and determine the number of tasks they can commit to during a two-to-four week sprint.
As with any Agile process, the governance process is based on regular meetings where teams
share their progress, groom tasks for the next sprint and validate their work. Teams may also
choose to hold daily "stand-up meetings" typical of Agile SW practices or opt for semi-weekly or
weekly meetings since progress for activities related to hardware are often not as granular as
software tasks.
During sprint planning the team will also have an eye to the whole product (IPAC) iteration.
Iterations are important to bring the components together and deliver prototypes that can be
used for validation with customers. As sprints are completed, progress is tracked and the team
will continute to improve their estimation skills and start showing real output months ahead of
waterfall processes.
15
An Intro to Modied Agile for Hardware Development
LEARN ABOUT THE COMPLETE MAHD FRAMEWORK BY VISITING:
WWW.MAHDFRAMEWORK.COM
While all projects will use the primary MAHD principles and methods, there are some
additional elements to consider as you scale. A summary of these include:
1. A MAHD team-of-teams approach – With major projects, having one large MAHD
team isn’t often practical and you need mechanisms to manage multiple teams.
2. New roles – While each MAHD team will have roles discussed earlier, additional roles
are needed to manage larger projects, whole product lines and the overall portfolio.
3. Multi-level Iteration Plans – For large systems, you might even have multiple levels
of Iteration Plans to manage each major workstream.
SCALING MAHD
The Complete MAHD Framework below shows the key elements for managing projects ranging
from simple cost reductions to whole product portfolios. While the key roles and elements are
typical of many new product organizations, the Framework is designed to allow you to adapt to
your situation, culture and objectives.
Scaling for Product Lines & Complex Products
16
An Intro to Modied Agile for Hardware Development
HW VERSUS SW
The MAHD Dierence
Can’t We Just Use Scrum?
Scrum is the most commonly used Agile methodology for SW-based projects so we’ll use
this as the basis of comparison for each element of Agile vs. MAHD. The following table
summarizes the Agile element and what's dierent for hardware.
Agile Element Scrum for SW MAHD
User Stories
Can be translated directly into tasks
and backlog items.
Provide customer requirements at a
system level, but typically cannot be
translated directly into tasks.
Backlog
List of user stories, technical stories
and epics. Constantly updated and
prioritized.
List of project tasks derived from
Iteration and sprint planning. Updated
& prioritized each sprint.
Iterations
1-4 week sprints, each with code
releases that can be demonstrated and
tested.
2-4 week sprints grouped into IPAC
iterations to hit important learning &
execution milestones.
Requirements Dened by user stories.
Dened by attributes, features, design
targets and user stories.
Prototypes Working software.
Demonstrable prototype of varying
sophistication.
Releases
Working software that can be tested
with direct user interaction.
Strategic prototypes that show
demonstrable output to enable
technical and market validation.
Deciders Typically a SW-oriented product owner.
Typically a business-oriented MAHD
Product Manager.
Process Owner Scrum Master Shared Ownership
Team Orientation SW Teams Cross-discipline Teams
Focus Matrix Not used
A crucial planning activity to determine
priorities, dependencies and learning
strategies.
17
An Intro to Modied Agile for Hardware Development
With the right support, resources and coaching, these activities and tools will
naturally lead to better NPD environments and long term market success.
Geng Started with MAHD
1. Determine the t - Start with a clear understanding of your team's goals to determine
if MAHD is right for you.
2. Ensure you have top-down support - If senior management does not understand or
support Agile principles, it will cause a great deal of frustration that often leads your
team back to waterfall techniques.
3. Clarify roles and deciders - You likely have titles like product managers, project mana-
gers and other roles. Determine if job denitions and responsibilities need to change to
support MAHD principles.
4. Start slow and expect early hiccups - If you've ever instituted a new process such as
six sigma or phase-gate, you know it can take time and energy. Implementing MAHD
does take a couple of projects to become procient. Stick with it.
5. Don't skimp on the on-ramp - Hardware requires up front planning to develop a clear
vision and iteration plan before diving into sprint planning.
6. Don't add tools too quickly - Agile project management tools, such as Jira, can be a
big aid, but learn Agile methods rst and then add tools to improve eciencies.
7. Identify and train champions - It takes leaders who have embraced Agile and are
skilled in its usage. Identify a small group of MAHD evangelists who can lead the team.
8. Don't skip customer interactions - Agile requires direct feedback from customers.
Many teams attempt to treat Agile as a pure development process, but to leverage its
power, MAHD must become a product success process.
GETTING MAHD
We've just touched the surface to fully describe the details of the MAHD Framework. If you'd like
to get started applying the MAHD Framework to your product development eorts, consider the
following eight tips:
How Can We Help?
(c) 2023 MAHD Framework LLC. - All Rights Reserved
MAHD Framework LLC is dedicated
to developing agile-based systems,
tools and skills to help product
development teams and organizations
take their NPD capabilities to a new
level of performance.
Services We Provide Include:
• Developing and rening the MAHD Framework
• Providing learning aids, tools and training programs
• Working with companies to build agile capabilities
• Licensing the MAHD Framework to skilled service providers
Contact us to discuss how we might help you
accelerate your NPD eorts.
About MAHD Framework LLC
web: www.mahdframework.com
email: [email protected]
The MAHD framework was developed by Dorian Simpson and Gary Hinkle with with input from
dozens of companies and teams ranging from electronics to medical equipment to address the
needs of hardware development. Having both been involved with product development for years,
they have seen the challenges of waterfall-based NPD processes and how Agile can help. However,
working with teams trying to implement Agile processes designed for SW development, they
were determined to nd a better way to get the benets of Agile while solving the needs of HW
development.
Below are three recommendations to get started. To learn more, visit:
www.MAHDFramework.com
ABOUT MAHD
TRAIN AND PILOT
• Idenfy a pilot team and project
• Get hands-on MAHD training
• Execute MAHD w/facilitaon
• Learn, improve and repeat
The fastest way to start
is to train a focused team
and pilot a project
2
ASSESS AND PLAN
• Establish clear NPD goals
• Idenfy areas for improvement
• Develop a roadmap w/milestones
• Pilot, learn, expand
This is a great opon if you
know MAHD is right for your whole
organizaon
3
Get started by vising www.mahdframework.com to learn more and
nd an authorized MAHD Sservice Provider.
GET AN OVERVIEW
• Review your situaon and goals
• Overview of the MAHD Framework
• Determine if MAHD is right for you
• How to best get started
Contact a MAHD Service
Provider to set up a
45-minute consultaon
1