Is Agile the Right Choice for IoT? 8 Key Challenges and How to Overcome Them
This blog was written under the expert guidance of Karol Szczepanik.
Introduction
Ever experienced it? That nagging voice of doubt that tells you the development of this new device isn’t looking too promising? If so, you’re not alone.
When creating complete IoT solutions, we face both hardware and software development challenges. While Agile methodologies have become the standard in software development, the real question is: can they work just as effectively in the world of microcontrollers, custom enclosures, cables, switches, antennas - in other words, hardware?
The answer is: yes, however it requires adaptation.
In this article, we’ll discuss eight key reasons why Agile may not work well and how to adjust it to work better in hardware development.
1. Long Production Cycles
In software, you can work from anywhere and make changes in minutes. But hardware? It takes time to design, produce, test, and deliver.
Recommendations:
- Prototype and validate quickly using widely available, tested, and trusted components.
- Develop applications in parallel with simulators and device prototypes (concurrent engineering).
2. Supply Chain Dependency Makes Dynamic Changes Tough
The only limitation in software changes is our skills. With hardware, we’re also at the mercy of component availability - microcontrollers, antennas, sensors, and more
Recommendations:
- Brainstorm prototype ideas and work on the most promising options in parallel. This way, you can test ideas and choose the one that best solves the problem, allowing for better supply chain planning.
- Choose widely available, standard components whenever possible to ensure easy replacement. This minimizes the risk of having to redesign the device due to the unavailability of a single "unique" component.
- Check the status of components before selecting them and prioritize those that are mature and/or recommended for new designs (statuses: obsolete, not recommended for new designs, active, recommended for new designs, preview…).
3. Hardware Changes Are Costly and Hard to Reverse
Even a minor change in hardware often requires project revision, updates to documentation, waiting for new deliveries, testing, and sometimes firmware modifications. Essentially, you're creating a new device. The differences in its specifications and capabilities must also be tracked for compatibility with older versions (in terms of production, functionality, firmware, sales, etc.).
Recommendations:
- Plan a long-term product roadmap, where each stage is a new version of the device.
- Design hardware for multiple functionality versions based on the Bill of Materials (BOM), allowing a single PCB design to support different versions, including customer-specific configurations.
- Reserve spare resources on the PCB, such as unused I/O lines, interfaces, and test connectors, to enable quick adaptation to new requirements or functionality testing.
- Consider a modular hardware design to make component swaps easier.
4. Device Certification Takes Time, Costs Money, and Must be Repeated for Each Version
Every hardware change may require recertification, which means additional costs and delays.
Recommendations:
- Make rapid changes early, then freeze hardware design once all technical and functional requirements are met.
- Include headroom in the device specification (e.g., memory, processing power, antenna types and power) if new features are planned for future versions.
- Design hardware with electromagnetic compatibility (EMC) in mind from the start to avoid costly redesigns if the device fails EMC testing.
- Pre-test prototypes in EMC labs during engineering hours and/or consult experts on EMC compliance early.
5. Synchronizing Hardware and Software is a Critical and Time-Consuming Process
Transitioning firmware from a prototype to the final hardware version always requires time for testing and fixes. Additionally, applications that worked on simulators must also be tested with the actual device and firmware updates.
Recommendations:
- Ensure an easy way to update firmware remotely (over-the-air updates) during prototyping—this will save time.
- Test devices in their intended working environment whenever possible.
- Develop tools to assess device performance and accuracy.
6. Slow Hardware Delivery due to a Complex Production Process
The material, environmental conditions, production batch size, shape, tolerances, and required standards all impact manufacturing complexity and costs. Even a simple PCB requires strict design guidelines.
Recommendations:
- Apply Design for Manufacturing (DFM) best practices as early as possible.
- If the device is custom-made for a client, align expectations early. Clearly communicate the trade-offs in production time, parameters, and cost, establish a plan, and set milestones.
7. Iteratively Improving Device UX is Tough
Every device serves a purpose, and user interaction plays a key role. However, making UX changes after thousands of units have already been produced is incredibly difficult.
Recommendations:
- Test early mockups and prototypes in a real environment with users who match the target audience.
- Consider a more interactive design, such as a touchscreen or wireless interface, which can be updated via software.
8. Hardware Must be Safe and Reliable from Day One
Customers expect high-quality and reliable hardware. Device failures or safety issues (e.g., electric shocks, fires, data leaks) are unacceptable as they can have catastrophic consequences.
Recommendations:
- Choose proven circuit designs (from previous projects, reputable component manufacturers).
- Implement proper protections for I/O, power, and interfaces, considering the environmental conditions in which the device will operate.
- Allow enough time for rigorous testing before deployment.
Summary: How to Adapt Agile for IoT?
Unfortunately, creating hardware is a complex and time-consuming process that doesn’t fit neatly into Agile frameworks. The only phase where Agile truly shines is the early prototyping stage. This stage should be used wisely:
- Use concurrent engineering -develop software alongside hardware.
- Eliminate as many unknowns as possible during prototyping, validate concepts with users, test device functionality, evaluate total cos of ownership, and plan the next steps.
- Account for synchronization time between hardware and software, testing, and certification.
- Consider modular hardware design for easier upgrades.
- Include remote configuration options.
- Use proven solutions to minimize risks.
- Ensure proper safety measures from the start.
By applying these principles, you can bring Agile’s flexibility into the hardware world while minimizing risks and delays.
As a Chief Information Officer, I bring over a decade of experience as a C# developer and a passion for technology to every aspect of my role. I believe that the answer to every question lies somewhere in the middle of every point of view, that’s why I want to first understand others’ perspectives, allowing me to adapt my own before taking any action. This belief has shaped my approach, fostering a hybrid mindset that I apply across all areas of my life—from family and work to sports. My wonderful wife and two amazing kids are my greatest inspiration, fueling every decision and action I take. Balancing the demands of family and a career, I’m committed to creating harmony between innovation and practicality, constantly seeking the middle ground where diverse ideas converge. This perspective enables me to lead with empathy and insight, always striving to blend the best of all worlds to achieve meaningful outcomes.
Rapidly adapt our competences into your IoT solution
Contact us and share your challenges
