The Middle of the Project
Here at Very, we work in 4-week sprints, which means that the MVP may have a few releases before it’s actually released for user feedback. The 4-week timeline is standard in agile development: long enough to complete a good deal of work, but short enough to let you accurately forecast where you’ll be at the end of the sprint.
Once the 4-week period has completed, we plan out epics for the next sprint. An epic is a chunk of work broken down into subtasks, each with a single common objective. By subdividing work in this way, it’s much easier for team members to know how to make progress on the project as a whole.
Testing is crucial from the very beginning of the project—not just an afterthought once development is complete. Every member of the team should have access to a hardware device that they can use for testing, including the product manager.
Most firmware for hardware devices is low-level code that’s hard to square with modern software development practices, such as automated testing. Here at Very, we develop IoT products using Nerves, an open-source platform that lets you generate low-level code automatically while leveraging a variety of powerful software tools. We’ve had so much success with using Nerves that our developers contribute to the open-source project themselves.
One final concern during project development is manufacturing, which clients should start thinking about as soon as possible. Procuring and managing the right contacts is highly important, especially in an era when many products are manufactured overseas.
Very helps our clients identify the right manufacturing contacts, as well as bridging gaps across time zones and languages. We go through multiple small-run iterations of the devices, getting prototypes built and testing them in real-world scenarios as we work toward the MVP.
The End of the Project
In reality, any kind of digital software product is never really finished. The application will always need to be updated to stay relevant and address new issues; there are always improvements and additional functionality that can be accomplished.
Once the MVP is finished, we can either hand it over to our internal development team for more work, or we can stay on and start building the next version of the product.
Because we’ve taken some shortcuts while building the MVP, we know that we still have some technical debt to resolve. As soon as we release the MVP, we look to get feedback from the target users. This feedback helps us to fix bugs and add features that users have requested, continually improving the product.
IoT projects typically require a larger team than a software project alone, although the exact number of members depends on the project type and requirements.
By adding hardware to the equation, you’ll need additional employees such as:
- An electrical engineer to design and implement the internal hardware of the device.
- A mechanical engineer to design and implement the external casing of the device.
- A full-stack engineer who understands both the software and hardware pieces and how they interact.
Of course, you’ll likely need a couple of engineers and a designer working on the software side as well.
At Very, we realize that strong communication—both internal and external—is an essential part of any development project. In particular, IoT projects require more communication because you have two separate pieces to work on: hardware and software.
We practice daily stand-up meetings and weekly iteration planning meetings (IPMs), as well as any other meetings that we see fit throughout the project. Tracking budget and time is also crucial, as certain expenses such as hardware can add up very quickly.