In this article, Bryan Eagle from Roamworks USA discusses the need for agile development and rapid prototyping for a successful M2M program.
The saying, “there is nothing constant but change” is never more true than in system design requirements for new M2M solutions. One thing I have learned is that whatever people say they want in their system, these requirements change over time, often before you have finished coding the first iteration of the system.
The first time I witnessed this was back in 1995 with Skywire, when we were developing an M2M system for monitoring Coca-Cola’s vending machines. We initially worked with them for months, designing and specifying the detailed requirements for the platform. Once we had a few binders filled with requirements, we turned it all over to our programmers who then spent months developing the software.
After the developers finalized the software we began implementing the M2M system in a large number of Coca-Cola’s machines. The innovative platform had been designed to track cash and provide an elementary routing system, but once we started analyzing the data some very interesting and unexpected patterns started to evolve. Because of this, we began to realize the myriad ways this information could be used to provide a much stronger ROI to the client. We also saw that several of the initial “must have” requirements actually were less important or could never be implemented.
After sharing these design changes with our developers, I was a bit surprised to find that there was some initial frustration as they wanted to know why these requirements were not in the original spec. Their view was that they had wasted time in delivering something that was not of value, and then wanted to charge heavily for the new features. I, on the other hand, viewed the situation completely differently and saw that what we allowed them to identify these new requirements. Our developers thought delivering the software was the end of the project, when in fact it was just the beginning.
Because of this I’ve embraced rapid prototyping and Agile programing methodologies. When you think about it, the customer only realizes it needs these new features AFTER interacting with the data and should not be penalized for learning new uses for the data or the system. In the M2M world this is what you WANT the client to do – evolve and grow the requirements through use of the system. This is when there is real value added, and when solutions providers truly earn their fees.
If you wait to complete an M2M system until all the requirements are known, the system most likely never gets developed, is developed late, is over budget or is still missing functionality.
Some people call this feature creep and think it is a bad thing, but I disagree strongly. As long as the requirements come from interacting with the data and deliver functionality that helps make better decisions and delivers a better ROI, then you are doing exactly what you should be doing as a solutions provider. The trick is to make sure you deliver the initial system quickly (rapid prototyping) and create an architecture that allows for the continued evolution of the solution on a timely basis (agile development).
While this approach is not new, it got a lot more organized in 2001 when the Manifesto for Agile Software Development was published.
The manifesto reads, in its entirety:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
While perhaps not as prosaic a start as “We the people, in order to form a more perfect union. . .,” the Manifesto has had a profound effect on how some are approaching the development of M2M systems today. In the Manifesto, the group went on to outline additional principles including, among others:
- Customer satisfaction is achieved by rapid delivery of useful software.
- Software enhancements should be delivered frequently (weeks rather than months), which requires close, co-operation between the customer (internal or external) and developers.
- Welcome requirements changes, it means the customer is getting what they need.
- Simplicity.
- Regularly adapt to changing circumstances.
So how does all of this apply to the M2M world? Because so many customers are monitoring various elements for the first time, the true value culled from the data is not known, and won’t be known until the customer starts to interact with the data. When this does in fact happen, the software platform must be able to architecturally adapt to the changing requirements. To allow for this, the software design flexibility needs to be built in at the beginning, and unfortunately most systems are built fairly rigidly and don’t allow for this kind of modification, without a major rewrite.
Be sure when you are picking an M2M platform to talk with your solutions provider about their approach to software development. My advice is to stay away from the providers that are too rigid in their approach and embrace those that adopt these agile development principles.
