Agility in Hardware Development

Developing new products is an inherently tricky business. When we begin our projects, we are never exactly sure what the market wants tomorrow, precisely how we will address that need and which disruptions will come along the way.

Over the last decade, agile methods have significantly improved the way software products and services are developed and it is obvious to apply agile to development of hardware as well. The practices don’t always transfer well, however.

Practices like frequent stand-up meetings to maintain alignment and collaboration, creating long term plans only at a high level, and breaking (and planning) the work into relatively short time boxes help the team focus on the right tasks at the right time.

Some practices, however, don’t translate well. Hardware cannot be developed one feature at a time. Software doesn’t have long lead times for procurement or need to allocate a large block of people (and money) to being able to reproduce the product flawlessly. Plus, a complete product development project includes people with a wide range of skills (from design engineering to operations to product launch) that cannot move tasks easily from one person to another. So, what should we do in the world of physical product development?

Most product development systems have some sort of front-end screening process to filter and refine the ideas into reasonably defined projects before companies invest heavily in them. In this article, we will look at strategies for agility after the projects have been selected.

In the execution, or back end, of development, we see most projects going through three distinct phases with different objectives, risk profiles, and hence different strategies.

The back end begins with a DISCOVERY phase. At the outset we have a reasonable idea of the problem to be solved and how solving it is valuable to the customer. At the end, we have our core requirements, a product concept, an operations concept, and a launch strategy. Creating these requires making many decisions and learning what is necessary to make those decisions. This phase can last very long because there is always one more thing we can learn before making each decision, and one more decision we could make.  

To overcome these time stretchers, we recommend using a system as described by Katherine Radeka of the Rapid Learning Institute. In this process we identify and focus on the key decisions that must be made by the end of the phase – decisions that if made incorrectly would require substantial work to recover and that we don’t have enough information to make today. Using the principle of the last responsible moment, we delay decisions until we need to make them, and no longer. To help us make those decisions, we identify the knowledge gaps we have and how we will close them. We then focus on the most important knowledge gaps to close, and skip ones with less impact – we’ll never have perfect knowledge, so we strive to do the 20% of the work with 80% of the impact. Planning in this phase is built around a cadence of closing knowledge gaps and making decisions.

After Discovery comes DETAILING. This is the focused work of the team to turn the concepts of the Discovery phase into reality. By the end of this phase, we have built and proven a form, fit, and function prototype, we have figured out how we will build it in production, and we know how we will market and sell the product. The driver for the cadence in this phase shifts from decisions to iterations of the product, manufacturing process, and launch development – as has been described well by the Modified Agile for Hardware Development (MAHD) model from Auxilium. Iterations of the product can take 3-9 months to create depending on the product and manufacturing complexity. This is too long to undertake as a single time box, so we recommend splitting each iteration into sections 2-4 weeks long. This is long enough to observe progress each time box, but short enough to reliably predict what can be accomplished with minimal replanning.  

The final stage of getting the product ready to release is the DEPLOYMENT phase where we focus on getting the system to replicate the product in place, verifying that the final product (and production processes) meets requirements, and validate that the product meets the customer needs. There is much less uncertainty in this phase than in the previous two. Things may not go exactly as expected, but it is reasonable to run this phase using conventional project management practices. By this we don’t mean having a 4000-line Gantt chart and following it to the letter. Rather, we mean having a medium level project plan (activities that last a week or two) with rolling two-week planning to fill in the details supplemented by daily stand-ups to ensure that there is cross-functional communication and alignment.

The principals of Agile encourage us to inspect and adapt as we execute a project. Our experience tells us that this should include managing the DISCOVERY, DETAILING, and DEPLOYMENT phases of the project differently to match the objectives and risk profiles of each stage.