Pros and cons for agile hardware product development
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)
- Kanban
- Scrum
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
About The Author
Sara wants nothing more than to help the GrabCAD Community thrive and grow. She loves listening to members and learning from them, so send her your feedback and introduce yourself. Sara wants to help engineers share, collaborate and ultimately build amazing things. She enjoys running around soccer fields and is most passionate about bringing the half time snacks.
Related Posts
- Yes, Lean, Agile Methods Can Be Applied to Hardware Development Too September 18, 2017
Should You Hire New CAD Help? Nope.
Business is good and you’re anticipating a big new project. The development team seems stretched, and you think it might be time to add headcount. But as a manager, you know that finding the funds and approval for a new employee is rarely easy. And nobody wants to hire someone today, only to have to lay him or her off 6 months from now when the current projects wrap up.
One alternative would be to look closely at how efficiently your current team operates. You might be surprised to find out that with just some changes to your processes and tools, you’ll create the capacity you need for handling the new bigger workloads without hiring new CAD help.
Here are five places to look for that extra capacity:
1. The Engineering Change Order (ECO) Process. ECO’s consume one-third to one-half of engineering capacity. There are two ways you might be able to reduce the efforts that go into ECOs.
First, look at how defects and enhancements are managed. Most companies use online forms and routing systems to identify, assign, track, and sign off on changes. Increasingly they’re using the PLM system to manage the process too. Make sure your process is clear and the right team member is changing the right thing at the right time.
Another key to reducing change orders is to reduce errors before they’re created. Rework is time consuming and expensive. Explore CAD tools that ensure the models your team sends out for prototyping and manufacturing are as robust as possible. Sheet metal and simulation/analysis tools are good examples of technologies that lead to more stable models downstream. Depending on your vendor, some of these capabilities might already be included in your CAD software. In other cases, you may benefit from purchasing extra technology.
2. Requests for Proposal Bids. If your company bids a lot of jobs, especially in response to RFPs, your engineers may be spending considerable time doing “spec” work. That is, they may be using engineering time to create models to include in bids, many of which may never turn into jobs or finished projects.
Here’s where PDM, an extra seat of CAD software, and a little training can help. Assuming a non-engineer is responsible for developing bids at your company, that team member could be using a company PDM system to access existing designs. Most major CAD systems now also include Direct Modeling functionality, a method of changing models that doesn’t require updating history trees or parameters. So with a seat of his or her own software, the bid manager can make changes without being a seasoned CAD pro.
3. Design Reviews. The design review is an important milestone during the product development cycle. But it can also sap a lot of time from good engineers. In fact, some CAD vendors say that engineers attend an unbelievable 17 to 57 reviews each month.
Look closer at what it takes for a developer to prepare for a meeting. Are team members using up time to take screen captures and prepare PowerPoints? How often? While you may not want to reduce the number of reviews, you can explore technologies that make preparing for them faster.
Generally, these are tools that make working with large assemblies fast, as well as viewers that the review team can use to load, inspect, measure, mark up, and share model data. All the major CAD systems offer some of these tools. If you prefer to stay CAD agnostic, download GrabCAD’s simple and free 3D viewer.
4. At the Very Start. In a recent article, I wrote about the value of designing for reuse. Most new products are built on the shoulders of existing designs. Some estimate that “only about 20% of an OEM’s investment is on new design, while about 80% is on the reuse of existing products, with or without modification.” Make sure your team is optimizing its opportunities for reuse from the very beginning of a project, if not before. In some cases, a good re-use strategy can take weeks of a design cycle.
5. In Front of the Desktop or Workstation. You may be updating your software regularly, but are your developers using the newest features and capabilities you just paid for? Often, when I talk to engineers, they say they have new and more efficient technologies, but they haven’t had time to integrate them into their everyday work.
It might pay to give team members some time to explore new product training. For seasoned users, everything they need to know is probably free online already. It’s the time that’s missing. (Hm, maybe this belongs in part 2 of this series, “Hire New Help? Yes.”)
I hope this has given you some things to think about as you challenge your team to do more with the same number of people. Next time, I’ll tell you why you probably ought to hire someone new anyway.
The Next Generation of PDM
More teams are using Cloud, Analytics, Mobile, and Social tools to speed up product development. Independent analyst firm, Consilia Vektor, explains how this changes Product Data Management (PDM) as you know it and how this can help your team work smarter.
https://blog.grabcad.com/blog/2014/05/14/pros-cons-agile-hardware-product-development/https://blog.grabcad.com/blog/2014/07/30/new-cad-help/
