Could Agile IoT Development Gain Favor?

Agile methodologies are increasingly disrupting traditional software development in the enterprise IT and cloud environments. These methodologies can speed up testing and updating of Internet of Things (IoT) systems. But they also challenge the traditionally linear process of creating hardware devices for field deployment in large numbers.

Historically, software development followed a “waterfall” methodology involving multiple steps, each of which depends on the previous, so that errors or changes can prompt a reversion to a previous step or a restart. This approach often creates project delays, adds costs and leads to development backlogs.

Agile methodologies make it possible to distribute the work into chunks and assign them  among collaborative, cross-functional teams. Each team can write and modify code in iterative cycles so that features can be added and modified without stalling the work of other teams. Because they’re generally developing for standardized hardware, these teams can focus on software-only tasks.

The inherently device-centric IoT environment typically relies on a sequential approach similar to waterfall development that has little tolerance for the “fail fast, fail often” mentality of Agile software methodologies. While “failed” software modules can be rewritten on the fly using Agile methodologies, hardware failures can stall progress and add cost, as entire devices or components have to be replaced or reengineered. 

“The development of new IoT products does not lend easily for the iterative and incremental approach,” wrote Gartner research analysts Aapo Markkanen and Nick Jones in a report on applying Agile methods to build IoT products. “For their full functionality, the developed products depend on not only embedded software, but also highly application-specific hardware that cannot always be separated into viable increments.” The result, they asserted, is that “most of the product risk is concentrated on the end of the project” as prototypes seldom adequately demonstrate how products will perform in the field.

If Agile IoT development can be combined with a more modular and adaptive hardware development process, there’s potential to speed up and improve product deployment. Agile IoT development could enable product features to be added more easily during the development stage to reflect changing market realities. Additionally, the Agile approach can make it easier to implement software updates throughout the post-deployment life cycle. 

Agile methodologies have been broadly adopted. KPMG indicated that all but 12% of respondents use Agile in some manner, and that number will decline to just 4% within three years. But many respondents reported they were still at early stages of adoption. Another survey found that few organizations have a high level of competency with Agile, and 52% indicated that their organizational culture was at odds with Agile values.

Ben Wald, co-founder and vice president of solutions implementation with the IoT development firm Very, acknowledged that implementing Agile for IoT hardware projects is more difficult than in software-only projects, but the methodologies and continuous delivery are well suited for the demands of connected devices. According to Wald, Agile eliminates silos, speeds up testing and makes it easier for development groups to adapt to change. 

“The biggest shift is that instead of having annual goals or a quarterly roadmap, we are launching and iterating and deploying on a weekly basis,” Wald said. “It’s critical to think differently about testing. You’re testing on an individual feature level, at different stages, long before you have a final ‘Gerber file’ to ship to manufacturing.” Rather than scheduling a quality assurance job six months down the line, he added, organizations need to allocate time and budget to testing throughout the process. 

Ready Robotics CEO Benjamin Gibbs, another Agile advocate, said the biggest misconception he runs into is the belief that companies deploying automation hardware like robotics can’t take an Agile approach. With increasing availability of 3D printers, he said, it is easier to redesign components on the fly, such as robotic grippers, rather than having to send specifications out to a machine shop and stop development while awaiting delivery of a new component.

Gibbs urged organizations making the transition to Agile to start small rather than trying to tackle a big complex project as a first foray. “The key is not biting off more than can chew,” he said. “Don’t roll out an entire line. Start with a lower-volume cell that will enable you to experiment in ways that not going to create tremendous backlog in production.” That will allow teams to get comfortable with the Agile approach, lessen the pressure on delivery, and allow people to be creative.

Even as more IoT developers adopt Agile, traditional waterfall methodologies still have their place. Wald said his company embraces some of the project planning elements of waterfall to ensure projects stay on track with client schedules and return on investment (ROI) goals. “If you’re taking a purist Agile approach where we plan one sprint beyond where we are today, it’s very hard to drive an ROI calculation.”

Currently, use of Agile in IoT development is spotty, according to Stephen Mellor, chief technical officer for the Industrial Internet Consortium and one of the original signatories in 2001 of the Agile Manifesto that spawned the Agile movement. Among the challenges, he explained in an email exchange, developers may not have access to key dependencies such as training AI algorithms, sensor and actuator controllers, alarms, and facilities to store large amounts of data.

“You can’t always test, especially failure modes,” Mellor wrote. “How do you check that two trains heading towards each other on the same track will successfully avoid a crash? Or that a satellite’s solar panels will deploy successfully in zero gravity? This makes test-driven development more difficult.”

Increasingly, though, developers can exploit IoT simulator services from cloud services providers including Amazon Web Services, IBM Watson, Microsoft Azure and Oracle. These types of service make it easier to test the logic required to operate large numbers of devices deployed in the field by running simulations on potentially thousands of virtual devices. Of course, that’s still essentially a lab-type process that may not reflect connectivity and power supply realities out in the field.

Cloud services enable testing resources that would be prohibitively costly to implement on-site. But until hardware developers can make their own design, testing and production processes more Agile, they’ll be holding back the ability of companies to execute IoT strategies faster and with reduced risk.