International Defense Security & Technology Your trusted Source for News, Research and Analysis
Related Articles
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.
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 modified Agile approach can leverage the power of Agile, while addressing the unique needs of hardware development.
The most obvious difference between hardware and software is that hard goods cannot be undone, twisted, adapted and adjusted at the same rate, or minimal impact to cost and time as software. For example, a new casing for a mobile phone cannot be quickly built and rebuilt again in the face of changing requirements.
Modified Agile for Hardware Development (MAHD)
Agile methods require modification to support the needs of hardware products where making changes are costly, partial products are difficult to test with real customers and definitions must be frozen for production. This led the need to develop the Modified Agile for Hardware Development (MAHD) Framework — an Agile initiative to gain the benefits of Agile while recognizing hardware’s unique needs.
Modified Agile for Hardware Development (MAHD) Framework was developed by Gary Hinkle and Dorian Simpson. It is similar to agile for software methods, but with critical differences. The MAHD Framework uses the principles of Agile to develop physical products in less time, with reduced risk and with higher customer satisfaction.
For software, Product Owner writes user stories, prioritizes the backlog, and approves all sprint tasks. For HW this role will often be filled by a Product Manager. They must understand and consider the whole product with all of the integrated components and make decisions that may have cross-functional implications. Software often defines a Scrum Master that has deep expertise in software development. For HW, we need project management expert who can manage across disciplines.
To kick off a MAHD project, a light product-market description document the “Agile Product Brief” is used that provides concise information the development team can use to get started. The shown below summarizes the market situation, clarifies the customer and their needs, establishes project goals, and identifies the high-level value drivers that lead to purchase in the market.
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 defining 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 different. 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 different, but
related and focuses on specific team tasks that must be accomplished each sprint.
Refine requirements into detailed user stories
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 specific backlog tasks.
