Transforming Your Hardware Through Agile
Time is currency. Optimizing engineering time and productivity while ensuring quality products is crucial. Therefore agile frameworks are frequently used for structuring work and ensuring that products and software are built in an iterative manner.
But what happens when we are not talking about software; can we apply these methodologies to other areas of engineering, namely hardware and mechanical development?
Some might be wondering “Why not? Why would hardware development possibly be so different? At the same time, hardware engineers who find themselves in a software focused company might claim there is a world of difference in the development mindset.
In this blog post, I’ll explore why hardware development is different from software and the benefits of embracing and adapting an agile framework for hardware teams.
I also hope to provide some insight for software engineers on the unique challenges encountered during hardware development.
Why doesn’t Agile work for Hardware?
A typical agile framework breaks down development into short sprints, usually no more than 1 to 2 weeks in duration. Each sprint is expected to be self-contained and include the requirements’ definition, planning, development & testing, to meet the defined deliverable.
A series of sprints allows the team to iterate until the full feature is developed and then optimized. For software development, this can allow for rapid bring-up of a basic, yet functional, feature, to allow for early user feedback, bug fixes and integration into a large system.
However, in a hardware environment, it is very difficult to break down development into small self contained sprints. Adding a new ‘feature’ to a hardware device requires several months, to allow time for CAD design, prototype, procurement of components, manufacturing and testing.
Can we just have longer sprints?
Yes, but it’s important for all teams to understand that each hardware “sprint” will not only need to be much longer, but there is a much bigger cost investment during each phase (components, materials, molds, fabrication, etc.). That means there can be a high cost for mistakes (both in time and money).
In software, a bug introduced in Sprint 1 can be quickly corrected in Sprint 2 or 3, without significant impact on the overall schedule. It’s easy to adjust to changes in software requirements, additions of new features and optimization with minimal impact to the development plan.
By contrast, if the mechanical team makes a design error or wants to accommodate a new product requirement, the cost of getting new parts and the lead time could significantly affect the product budget or schedule.
For example, if there is change in the required battery life of the product that necessitates a larger battery, it is not as simple as revising the CAD design to accommodate the large parts. There will also be a cost for new electronics or remaking molds for plastics (a lengthy task in itself). Note that plastic molds are often made by a subcontractor, requiring extensive back and forth between designers and mold makers, and may have a 2+ month lead time.
Traditionally hardware development plans follow the waterfall approach, which aims to reduce iteration and to minimize the number of prototype phases required. In the waterfall approach, it is essential that deliverables be clearly defined up front with documented requirements. As such, clear decision points and design freezes are needed with the associated risks communicated to all stakeholders. This would appear to be in direct conflict with the main principles of an agile framework.
Do we have to give up on Agile for hardware?
Agile provides a structure and mindset that ensures teams are constantly revisiting priorities, revising the plan and testing their solution, to ensure they remain on the right path to achieve the end goal. This constant re-evaluation leaves room for innovation.
In a waterfall approach, all decisions need to be made at the beginning of the project, leaving little room for innovation later on. So what if we combined the best characteristics of an agile framework with the waterfall approach. This means setting clear project points and design freezes, but also working in an agile manner between those points.
At Augury, we embrace the Agile framework wherever possible.
For the hardware team, this means that we have clear “design freeze” milestones before investing in costly and long lead time manufacturing tools and components. But it also means we are not afraid to pivot and change between design cycles.
We rely on risk analysis to make tradeoffs at these key milestones and ensure that we only ‘freeze’ those aspects of the design that are required. We also use rapid prototyping technology, such as 3-D printing to allow us to create and test solutions iteratively in shorter sprints (typically 1 month) before committing to a 3 month hard tooling development.
Sounds good, but does it really work? Here’s a great example…
Halfway through the development of our latest Endpoint sensor, we discovered that one of our key sensors would be out of stock shortly after the planned launch date. I imagine in many companies following a traditional waterfall approach, this would have delayed the project and required going back to the drawing board, re-evaluating the sensor options and reworking the electronics. The entire project schedule would have been significantly impacted and delayed the launch.
At Augury, we chose the agile approach. We continued on the existing design with the current sensor, and added the option to place the new (as yet untested) sensor on our prototypes as an alternate. This allowed the teams to remain on the current schedule, while enabling evaluation of the potential replacement in parallel. By maintaining the option for both sensors, risk of the sensor shortage has been mitigated through a potential replacement. Time will tell the outcome of this particular project, but this is just one example of how not being afraid of change and embracing innovation can yield success.
Wrapping up
As technology progresses, and easy-to-use simulation software becomes more ubiquitous for complex mechanical and dynamic parts, hardware teams will be able to test their designs and iterate before committing to a costly prototype. As an example the mechanical guild at Augury has been evaluating various 3D printing technologies to determine what technology suits our needs and budget, to enable us to shorten the design cycle. This in turn will enable us to move closer to a truly agile framework.
