10 Steps to a Successful Agile IoT Project

Once you’ve chosen to go the agile route for your IoT development project, how do you make sure you’re successful? We’ve narrowed it down to 10 key steps that we follow at Very to get our clients’ biggest agile IoT projects fully operational. 

1. Validate Your Assumptions and Define Project Constraints

Although we practice agile IoT project work at Very, we're not allergic to documentation and building requirements. What’s most important in gathering those requirements is that we don’t get to the point where we’re wasting time validating premature assumptions. 

For phase one, the first thing we do is dig into our riskiest assumptions — those assumptions that, if they are invalidated, will flip the ROI equation upside down. With agile IoT projects, we run experiments to test those assumptions, like customer interviews, reaching out to manufacturing partners, and more. 

The second part of this stage is identifying the ROI of the project, which can involve gathering sales projections, doing market research, and understanding your customers’ price point thresholds. We’ve found that if you can identify some of the cost parameters for the device that you're building or the services that you're creating, this will help inform decisions down the road and will keep you from having to do major revamps and component swap-outs late in the game. 

2. Build an IoT Product Development Roadmap

Credit: Very

To build a product development roadmap, we take the needs, wants, and desires we’ve established for our users during our Strategy Sprint and use them to write job stories. Job stories help us to define a given situation, a user's motivation for acting within that situation, and the expected outcome of the action. 

Then, we create a workflow map that goes through each feature in a device or product to see all of a user’s possible paths, accounting for both “happy paths” (when users do what they’re intended to do within your product) and “sad paths” (when a user doesn’t complete the expected action, like typing an invalid password).   

Once we have a robust workflow map that gets everyone on the same page (literally), we create cards in our project management software (we use JIRA). The cards break out individual job stories, detail any potential blockers, and establish who’s working on what. Our engineers use the cards to go through a story pointing process, where they estimate the complexity of each feature and how much they can accomplish within a given amount of time. This is what helps us to make accurate projections about how long things will take and what we’ll be able to get done. 

3. De-Risk Your Hardware

Credit: Very

Step three is when we actually start building things and hammering out the basics. The goal here is to eliminate unknowns around the hardware design. We answer questions like:

• Is it possible to measure/control X with an acceptable level of accuracy?
• Is it possible to receive wireless communication in the expected operating environment?
• Is the expected bill of materials cost feasible from a budgetary perspective?

4. Imitate Your End Product

Now that the foundation is set, it's time to make this device do its job. We call this stage “imitation” because, for hardware, we’re trying to create a device that will imitate the way the end product will work. It should be able to reliably operate, establish a network connection, and check for firmware updates. 

The software, meanwhile, should be able to imitate the interactions with the device. This includes getting the OTA firmware update process in place since having individual developers manually updating firmware can introduce unnecessary risk. 

5. Build a Full Prototype

Credit: Very

Once we’ve successfully imitated the end product, it’s time to simulate it by building a full prototype. We start plugging in real components with the goal of getting the device to use the real CPU architecture paired with the final code on a development board. 

By the end of this stage, the prototype should be fully connected to the web. We should be able to send data to and receive data from the device, including IoT firmware security updates. The firmware and software should be ready for production (but probably not feature-complete) at this stage. 

6. Complete a Micro-Facturing Run

Credit: Very

Once we’ve built our first prototype, it’s time to start replicating it in what we call a micro-facturing run. The goal is just to create enough products so that every engineer on the project has one to work with, so they’ll typically be hand-soldered and 3D-printed. From a hardware perspective, this is when we’ll start making decisions about enclosures and materials.  We’ll start doing things like sending for final element analysis and running models for testing high-stress areas in the mechanical design. After those tests, we start to come up with some solutions or models to alleviate those high-stress points. 

The most important part of this step is that we’re really starting to think about how this device is going to behave in the wild. We’re trying to see if there's anything fundamentally wrong at this stage. We know that we’re ready to move on when we feel comfortable that we could put something highly similar to this device and in the hands of the users in a beta launch. 

7. Launch Your First Manufacturing Run

By the time you launch your first manufacturing run, you should feel confident enough with the decisions made thus far to produce around 50–100 devices, depending on the context of the project. It’s time to get a pilot group engaged, finalize the board layout, and optimize the software infrastructure. 

At this point, the biggest drivers of change shouldn't be new mechanical requirements. They should be the actual users and how the product is behaving in the world. Additionally, at this stage, we take proactive steps to ensure that the real manufacturing run will go smoothly. We make estimations for the final bill of materials, check with our manufacturing partners about the volume they’ll be able to handle, and make sure we’re taking the proper steps to get the product certified by the relevant regulators.  

We’re ready to move on from this stage when we’ve received robust feedback from our pilot group and have made adjustments as needed. 

8. Do Your “Real” Manufacturing Run

By step eight, things are getting exciting. For a “real” manufacturing run, we recommend producing about 1,000 devices to perform initial user testing, product training, and onboarding. From a hardware perspective, when there are devices out in the world we’re able to start validating longevity issues (e.g., is the glue we used wearing out?) We start to see the real impact of temperature and environmental effects on these devices. We know that we’re ready to move on when we’ve received additional solid feedback, and probably had a couple of “aha!” moments along the way. 

9. Go to Market with Your Final Manufacturing Run

Credit: Very

When we reach step nine, the go-to-market manufacturing run, we’re ready to move forward in a big way. The software and firmware have been performing well for a while, we are confident in our hardware choices, and the idea of bringing hundreds of these devices online at once isn’t scary because we’ve accounted for potential issues ahead of time. Eliminating these worries gives us time in this stage to optimize for economies of scale.

10. Explore the Power of Digital Twins

With the product out in the world collecting data through sensors and sending it to the cloud, we have a wealth of information we can use to create a digital twin, a virtual model of the product that takes real-world conditions into account. Digital twins can be used for testing, predicting and diagnosing failure, and experimentation for the next version of the product.  

Agile IoT projects in the Real World

One of our favorite quotes about working on IoT projects comes from Very’s own Software Engineering Practice Lead, Daniel Spofford:

"Nothing beats the real world. The real world is messy. That's why agile IoT is relevant and necessary."

When we created these steps, our focus was on getting products in the hands of testers and users as quickly as possible, then using the feedback from those cycles to inform the development process. 

The key to making all of these steps actually work, though, is communication and cadence. At Very, we do monthly release planning, weekly sprints, daily standups, and weekly retrospectives where we identify what went right and what didn’t so that we can make adjustments. Every single week we are practicing finding ways that we can work better together. 

Agile IoT is a journey of 1,000 tiny steps. What matters most is that everybody is taking those tiny steps together.