The Agile development method has existed for quite some time in the world of software, but it has not been adopted quickly within the domain of hardware engineering. Despite its lack of prevalence in the hardware engineering community, we've found it to be a very useful development process for our multi-disciplinary IoT engineering teams (which include hardware engineering). At its core, Agile development is just a means for ensuring that time is used in the most efficient manner, which is why we use it at Very.
The most important principles of Agile development as interpreted by Very are:
- Continuously deliver value to end-users.
- Ensure features are production-ready before moving to new features.
- Test early and often.
- Make a decision at the last responsible moment, and not before.
The biggest manifestation of these principles in our hardware team is the approach to our PCB design. The traditional path of industry involves scrutinizingly selecting a full BOM first, then work out the schematic, then perform the PCB layout, then prepare manufacturing instructions and order prototype boards. This results in long design cycles and is fragile when faced with changing requirements. Instead, we move through the full design cycle component by component.
This means we first select a processor, and its minimal required peripherals, work out the schematic for this small number of components, then lay them out on the PCB and create manufacturing documentation. This often means that after a couple of weeks, we could receive an order of production-ready (but not feature complete) PCBs.
We then step through each new component of the design in the same manner. This method yields schematics and layouts that are more modular and robust to change and prevents time loss by making pre-mature decisions (i.e. scrutinizing over a BOM for weeks only to have requirements change later, making much of it obsolete).
Lastly, clear definitions of responsibilities are critical to ensuring that team members know what work belongs on their plate and who to go to when they identify work that doesn't belong to them. For our hardware team, this is most notably useful in distinguishing Quality Assurance (QA) work from engineering work. QA is a crucial part of our IoT engineering strategy, but when QA gets its hands on early prototypes, the lines between QA, hardware engineering, and software engineering can blur.
In order to allow team members to be utilized in the most efficient manner, the teams have collaborated to build QA test plans which clearly document the steps QA should take before they reach out to engineers. In addition to this, all tickets on our Agile planning boards are broken down into small chunks of work and are labeled with the responsible parties. This ensures everyone understands who will be accomplishing a given task.
We still see room for improvement and are constantly refining our processes, but over this time frame, we've shocked clients and peers with the speed and overall cost of development that we are able to deliver.