Agile product development isn't new, but it is still foreign to most teams building physical products. Should your team make the switch from Waterfall to Agile hardware product development? There's nothing better than a pros and cons list (and lots of resources) to help you decide.
Pictured: Poppy Beta by The Poppy Project on GrabCAD
We need new ways to develop products
Hardware is unpredictable. The traditional, waterfall approach to hardware product development relies on a predictable process that can be planned and executed without many adaptations or surprises. The Agile Manifesto was created to help foster a creative and adaptable process. Could hardware benefit? Luckily, there are already many established and tested methods for Agile thanks to its popularity for software engineers. Hardware is hard, right? So, any tool or method that can make creating physical products easier is worth considering. EETimes helps you decide if your team could benefit from Agile product development with this list of questions, below.
Questions to ask your hardware team
- Is it possible to build a detailed project plan that accurately captures a complete development cycle prior to development?
- Do detailed project plans remain stable over time?
- Is it possible to build a concise set of product requirements that will satisfy customer and market need 6, 12 or 18 months in the future?
- Do product requirements remain stable over time?
- Are products consistently delivered on schedule?
- Do products consistently meet market demand and customer need?
- Are target technologies thoroughly understood and unlikely to change?
- Would a hardware team design and build a product the same way twice?
- Are product architectures likely to remain stable over time?
- Are people and their respective skill-sets interchangeable?
- Questions originally posted by EETimes in 'Agile hardware development - nonsense or necessary?'
If you answered, 'No' to most of those questions, then you should consider making the switch to Agile. We've come a long way from product data management (PDM) tools of the past that require a more waterfall approach to design. New technology like cloud-based PDM, SaaS products that cater to Agile methodologies, and other collaboration tools make this a better time than ever to make the switch.
Agile product development at a glance
Agile refers to an iterative way of developing. It was created by a group of software engineers that got together to brainstorm an ideal development process. Their manifesto respects and acknowledges best practices like normal due diligence, documentation, contracts, and plans. However, it's main focus is on things like working product, collaboration, and adaptability to get things done. It is a direct response to process-centric methods that are documented to the tiniest detail. Agile is the anti-'Dilbert.' The engineers who founded Agile wanted something that allowed creativity and most of all, something that helped them build successful products, which was proving harder and harder with traditional, top-down processes. There is one problem, though. This is all a general guideline that allowed for many different Agile methodologies.
Different Agile methodologies
- Dynamic Systems Development Method (DSDM)
- Extreme Programming (XP)
- Feature Driven Development (FDD)
Scrum is the most popular. There is a very good description of the Scrum process by Design & Reuse. Basically, small teams iterate collaboratively in set periods of time called sprints. Each scrum team takes ownership of a piece of the product instead of focusing on individual tasks. It's a more holistic approach that helps ensure a useful product is the result of each sprint. And, one big difference from traditional processes is that scrum teams focus on users stories, or looking at things from the customer's perspective, over documentation and specs.
Pros: Agile hardware development
Imagine a team that focuses on how their work will be used by the customer, who quickly uses feedback from other teams and test users to build something that gets better and better in noticeable, usable chunks of productivity. They work without the usual documentation and strict procedures because communication is fast and the results are what is important. Who thinks Agile hardware is the way to go? Open source projects like Poppy Project with Matthieu Lapeyre, pictured above, and even big companies like GE. Forbes highlighted how one team built a fuel-efficient car in months.
- Better teamwork with pair engineering and co-located teams
- Less documentation to restrict creativity
- Less time spent doing blind research
- Testing and feedback speeds learning
- Smaller, more rapid improvements
Cons: Agile hardware development
Some companies prefer the perceived stability and predictability of a traditional development process. The comprehensive documentation and contracts protect them from risk and having one team follow the work of another. Here is an argument against Agile for hardware by Michael Thompson. There are also special hurdles when you're combining hardware and software in one product like a lot of the new connected devices.
- More revisions and versions mean more data to manage
- Cost for changing procedures and tools
- Fewer contracts and specs could mean higher risk
- Communication and coordination is more complicated
It's time for Agile hardware product development
To stay competitive, teams need to get to market faster with usable products that they know customers will love. Agile hardware product development can help your team do just that. If you're having a hard time getting over the cons of changing your processes and dealing with higher risk, then we suggest digging deeper in the resources below and checking out the 'Top 10 questions when using Agile on hardware projects' by Larry Maccherone. Let us know what challenges you faced or what benefits you saw when adopting an Agile process for your product in the comments.
Read more from our sources for this post:
- Agile Hardware Development - Nonsense or Necessity?
- Applying Agile to Hardware Development (We're Not that Different After All!)
- Are We too Hard for Agile?
- Going the Next Step? Agile Values and Hardware Development
- Why Companies Aren't Jumping on the Agile Bandwagon
- How We Learned to Build Hardware the Agile Way
- The Agile Hardware Design Mindset
- Hardware doesn't fit the Agile Model
- Hardware is Hard, That's Why They Call it Hardware