I’ve recently moved from pure software development into integrated technology, aka the Internet of Things. Exciting, challenging, and arguably the next frontier in electronic technology. But as an Agilist, it presents a whole new set of challenges.
The Physical World
Software vendors have no physical product, so they don’t worry at all about manufacturing and worry very little about distribution.When software is built to the required level of reliability and quality, it is essentially already manufactured. And in a sophisticated shop it can be distributed with the push of a button. (In the most sophisticated Agile shops, that button is pushed within an iteration as part of a user story’s acceptance process.) There is no supply chain, no production tooling, and no concrete product that can interact with the physical world.
With integrated technology, that simplicity is disrupted by the demands of material things and their physical characteristics. For example, electronic devices produce and are subject to electromagnetic and thermal effects that are unavoidably different in a manufactured product than in the bench product. As a result, final acceptance of work must wait until the product has been validated in manufacturing (somewhat like a press check in publishing). Also, hardware and mechanical products require formal specifications in order to be built, and the products must be certified (both in design and after production) by various regulatory bodies.
Time
In the software world, time can compress to essentially zero if enough money and skill are brought to bear. Testing, deployment, and installation can be automated, and with cloud services like AWS and Azure, provisioning can be automated too. As for speed, more horsepower is always available if you can afford it.So time boxes, the holy grail of Agile (and especially Scrum), are both practical and effective. The time compression that software development permits can fit everything into a time box.
In integrated technology that is not the case. Even if the software components can fit into a two week iteration, hardware and physical engineering (mechanical, metallurgical, etc) usually can not – for the reasons stated above. So you have several collaborating teams, only one of which can cycle fast.
Given these challenges (and there are others), our coordinated IoT teams practicing Agile are finding that:
- The risk-reduction work in a product release cycle must be limited to the very front of the timeline, so it can be safely completed before the first hardware production specification goes to a manufacturer. This is a perverse twist on the Agile goal of making decisions as late as possible. As late as possible is not very late at all in IoT, and descending back into full waterfall is a constant danger.
- Once the hardware specification has gone to a manufacturer, software teams must restrict their work to capabilities that do not disturb the software-firmware-hardware-material functional interface, which has by then essentially been cast in stone. Rather than tackle improvement opportunities as they come up, those must be batched for later consideration. This introduces more waterfall tendencies.
- The short cycles of the software teams must find a way to coordinate with the much longer cycles of the physical teams. And the assumption that every team can deliver fully shippable product at the end of each iteration is simply no longer true. It is a challenge to relax that imperative without abandoning it.
But there are only a few pioneers at this early date. We have a lot to learn from each other, and we need to learn a lot.
So I’d appreciate hearing from you if your shop is involved in IoT.
