Agile methods: how to balance innovation with project delivery

Do you have an innovative project involving smart devices and are wondering which project management method to adopt? Are you drawn to agile methods but wondering, in practical terms, what this entails?

You’ve come to the right place!

By definition, the development of an innovative project cannot be perfectly anticipated or planned. However, it is necessary to adhere to the scheduling constraints imposed by the marketing teams and the budget limits set by their management.

Because you fear falling victim to the Pi factor (the actual duration of projects is three times longer than initially planned), your project delivery framework must be both reliable and flexible.

What does that mean?

The scope may change—indeed, it will change—but your budget and timeline must be safeguarded, whilst maintaining the appropriate level of quality and having a stable team.

So, how can agile methods guarantee you the best chance of success whilst protecting these two variables?

That is what we will explore here.

The characteristics of agile methods

Agile development is emerging as an attractive alternative to traditional waterfall development. The Agile approach treats the budget and timeline as fixed parameters from the outset. It is therefore the scope of the development that remains the variable.

As a result, teams focus their efforts on what delivers the most value, enabling them to develop a functional product within the allocated timeframe and within the given budget. Agile methods operate with regular deliveries (see below), which allows for adaptation of the next steps (improving the first version based on user feedback, developing feature no. 2 if the results are good, etc.).

Various types of tools and roles exist for applying agile methods.

1. The effort-value matrix

It helps put the very essence of the product into perspective and get back to basics by prioritising the various features we would like to include in the product. It consists of a table that ranks each feature or characteristic according to the value it delivers and the corresponding effort required.

This table then naturally identifies the quick-wins (high ROI and low effort), the items to be dropped (low ROI and high effort), those that add value but require significant effort, and those that add slightly less value but require little effort and should be implemented if the most important ones have already been addressed (see the table below).

2. The Product Owner

There is also a commitment to inclusion: a product owner will be appointed, who will oversee product development within the project-leading company. What sets this apart is that the product owner becomes an integral part of the team: they take part in discussions, challenge the teams on product development, and help prioritise actions. There is just one team: this is genuine co-contracting. The supplier is therefore not there solely to fulfil the specifications.

Together, they will ensure the development of the best possible version of the product.

3. User stories

User story workshops are also a powerful tool during product development. A user story is a functional requirement based on a key user of the product that will add business value to the product. It is written in natural language that can be understood by everyone involved in the project. These workshops are held throughout the course of the project.

4. Development in sprints

Development work is then organised into sprints (lasting two to three weeks). This makes it possible to test the initial features after a few weeks, allowing certain features to be validated or discarded. It also enables the scope of each feature to be adjusted once testing has been completed. As a result, the product is more likely to succeed, as it will align with the final expectations.

Contractualisation: a key factor in the success of project development

La contractualisation permet également de capitaliser sur la réussite du produit. En effet, certains contrats tiennent davantage de la co-traitance que de la simple relation client-fournisseur. Chez Rtone, nous avons l’habitude de travailler avec des contrats 50/50 ou “stop ou encore” :

1. The 50/50 contract

The 50/50 contract involves a monthly fee and an estimated target completion date for a scope defined in advance. If the project is completed early, both parties benefit and share the profits. If the project is not completed within the agreed timeframe (which is set with a margin of error, for example 8 months, +/- 2 months), both parties reinvest in proportion to the delay. This will encourage teams to finish on time.

2. The ‘stop or go’ contract

The “stop or go” contract also involves a monthly fee. A list of proposed features is drawn up, and in each sprint, a selection of these is implemented. To deliver more, and to ensure the relationship remains satisfactory, the supplier must commit to fewer features, so that the contract is extended from sprint to sprint. The distinctive feature of this contract is that either party may decide to halt the project at any time, for various reasons. This has a reassuring aspect, as it relies on mutual satisfaction and helps to balance things out. It allows the supplier to be a stakeholder in the project, working as a true co-contractor.

Thus, balancing this type of relationship and ensuring that both parties share the same interests will enable us to capitalise on the results and give the project greater momentum.

>> Download our open-source contract templates here

Agility to ensure that a product meets market demand

Development must be viewed through a technical and economic lens. A project must, above all, be built around a market, but market analysis alone can prove unreliable. Furthermore, a product cannot expect to sell solely on the basis of the new technology it incorporates. A product derives its legitimacy from what it will offer the user. It need not be multifunctional, but must above all address a specific problem through its primary function.

Agile methods enable exploratory analysis throughout the development process by placing mock-ups and POCs more frequently in the hands of end users. These user tests will generate feedback and allow conclusions to be drawn at each stage. Thus, the company leading the project can adapt accordingly and, at any time, adjust the direction of development. This method clearly represents a way to explore a market easily and effectively.

Agility certainly comes at a cost, but this approach genuinely maximises a product’s chances of commercial success by ensuring it remains closely aligned with the market. This local cost will therefore be recouped through the overall project gains. By breaking the project down into smaller parts, this iterative approach allows for more aspects of the product to be tested and validated more frequently (with each release), and not just at a technical level. The result is a product that performs much better both commercially and technically, and is therefore fully aligned with market expectations. Agility shines through its effectiveness. By ensuring greater overall commercial success, agile methods see their costs fully recouped.

A word from our expert, Tom Fournier:

“We believe in agility, whether it concerns hardware or the cloud, because it must first and foremost be embedded in our processes and, above all, in our company values. That is why, at Rtone, we have chosen to bring all IoT-related functions in-house and operate exclusively as a fabless company. Every sprint can lead to a change that we see, above all, as an opportunity!

We embrace agility because we believe that, in certain IoT projects, it increases the chances of success. If you’d like to know how this could be integrated into your project, contact us and we can discuss it!”