By definition, the development of an innovative project cannot be perfectly designed and planned. However, it is essential to respect scheduling deadlines defined by the marketing teams and budgets imposed by Management.
No one wants to be a victim of the Pi factor (the law that says the actual duration of projects is three times longer than initially planned), so the implementation mechanism must be reliable and flexible. The scope can and will change, but your budget and timing must be protected, respecting the appropriate level of quality and maintaining a stable team. How can the Agile method guarantee the best chances of success while protecting these two imponderables?
Characteristics of the Agile method
Agile development appears to be an interesting alternative to the traditional waterfall development model. Agile operation takes into account budget and timing as fixed input data, right from the outset. The focus of the development will therefore be the variable data. Teams can focus on what is most valuable in order to develop a functional product within the allotted time and which meets the allocated budget. The Agile method works with regular deliveries (see below), which makes it possible to adapt later stages (improvement of the initial version according to user feedback, development of the next function if the results are good, etc.).
Different types of tools exist to apply Agile methods.
The value vs effort matrix is the standard tool. It puts the very essence of the product into perspective and allows for a return to basics by prioritising the features we want the product to have. It consists of a grid that categorizes each feature or characteristic according to the value it generates and the corresponding effort required. This grid then naturally defines quick-wins (high ROI and little effort), things to abandon (low ROI and a great deal of effort), those that generate value but require a lot of effort, and those that generate less value but represent little effort, and only come into play if the most important tasks are already achieved (see table below).
There is also the willingness for inclusion: a product owner is appointed to guarantee product development at the company behind the project. The special feature is that they join the team as if they were part of it: they participate in debates, challenge the teams on product development, help prioritise actions. There is only one team: genuine co-contracting. The supplier is not only there to deliver the specifications; together, they will ensure development of the best possible version of the product.
User story writing workshops are also a powerful tool during product development. A user story is a functional request based on a key product user that will add business value to the product. It will be written in a natural language understood by all project participants. Such workshops are held throughout the development of the project.
The developments are then organised into sprints (2/3 weeks each). This allows the first functions to be tested after a few weeks, to validate or discard them. This also allows the level of each function to be adjusted once the tests are carried out. In this way, the product will have a better chance of success, as it will match final expectations.
Contracting: a vector for successful project development
Contracting also makes it possible to capitalise on the success of the product. Indeed, some contracts are more akin to co-contracting than to a simple client-supplier relationship. At Rtone, we are used to working via 50/50 or "stop or continue" contracts:
- the 50/50 contract has a monthly cost and an estimated target time frame for a fixed scope. If the project ends earlier, both parties are winners and share the benefits. If the project is not completed within the time limit (including a margin of leeway, for example 8 months +/- 2 months), both parties re-invest pro rata in the overrun. This will encourage the teams to finish on time.
- The "stop or continue" contract also has a monthly cost. A list of required features is drawn up and some of them are included in each sprint session. To deliver more, and to maintain a satisfactory relationship, the supplier must promise less, so that the contract is carried over from sprint to sprint. The particularity of this contract is that either party can decide to stop the project at any time, for various reasons. This has a reassuring aspect, because it focuses on mutual satisfaction and helps to balance things out. It allows the supplier to be part of the project, to work as real co-contractors.
Thereby, balancing this type of relationship and ensuring that the benefits are similar for both parties will allow us to capitalise on the results and drive the project forward.
Looking for more information about RTone?
Agility to ensure that your product matches its market
Development must be understood from a technical and economic perspective. A project must first and foremost be built around a market, but market analysis alone can be fragile. On the other hand, a product cannot hope to sell exclusively for its new embedded technology. A product finds legitimacy in what it brings to the user. It does not have to be multifunctional, but must above all resolve a set of issues through its main function.
Agile methods allow exploratory analysis throughout development by placing mock-ups and POCs in the hands of end users more frequently. These user tests will generate feedback and allow conclusions to be drawn for each version. In this way, the company driving the project can adapt itself to the development process at any time and rectify the development route. This method clearly represents a way to easily and healthily eliminate risk from a market.
Agility certainly has a cost, but this method really allows you to give your product the best chances of commercial success by remaining close to your market. The local cost will be recovered in the overall gains generated by the project. By breaking down the project into parts, this iterative approach makes it possible to test and validate more aspects of the product more often (each version), and not only in technical terms. The result is a much more efficient product, in both business and technical terms, and therefore in full compliance with market expectations. Agility shines through its efficiency. By guaranteeing better business success overall, costs involved in the Agile method are fully amortised.
Notes from our expert Tom Fournier:
We believe in agility, whether it involves hardware or the cloud, because it must be an integral part of business processes and above all, the company values. This is why at Rtone, we have chosen to integrate all IoT-related activities internally and to be exclusively fabless. Each sprint can lead to a change that we see as an opportunity!
We fully integrate agility as we believe that it guarantees more chances of success in certain IoT projects. If you would like to know to what extent this can be integrated into your project, contact us and we can discuss it!
You want to go deeper with your IoT project? Discover how to build a successful connected solution with our free guide.