agileIoT logo

The AgileIoT Manifesto is the summary of the analysis work done in the domains related to the Internet of Things, going to highlight the fundamental aspects related to the governance, risk and sustainability of the initiative.



The AgileIoT philosophy is the same as the renaissance workshop one, the cell where everything needed was made to realize a new handiwork: starting from the design to the marketing, going through the learning and the production.

Team’s members are pushed to behave like renaissance craftsmen, with ability they use various materials, techniques and tools to satisfy the handiwork’s customer.

AgileIoT brings the customer’s need to the center, harmonizing competencies, approaches and various technologies by defining a main-set of economically-sustainable tools to create an IoT solutions.



It’s not software, hardware or service: it’s about jobs to be done!

It’s not the completion of a software or hardware project but a smart solution, based on both, to solve a need in an effective and efficient way.

Think less and do it!

Reduce to the bare minimum the time dedicated to the analysis phase, in favor of a quick startup of development’s activities related to the solution.

Simple is better!

Simpler is the solution, more chance we have to evolve it according to stakeholders needs.

If you can’t remember it, you can’t improve it!

Using visual management system to monitoring the state of the solution development.



Fast Prototyping

The goal of the Fast Prototyping is to validate the overall sustainability of the solution. The sustainability is characterized by 8 bobble-aspects that focuses on the main ones, related to the IoT solutions: Energy, Hardware, Code, Data Flow, Cloud, Security, Delivery e Legal:

  • Energy: focused on the energetic-based aspects as a function of the needs of the operational continuity of smart devices;
  • Hardware: focused on the validation of the hardware through one or more Evaluation Kits (EVK). The EVK is evaluated through CPU/MCU, and then with prototyping the other components, like RAM, USB, and so on;
  • Code: focused on the prototyping of the firmware of the devices and the services made for acquiring the main data/events. In this phase, useful frameworks and productive IDEs can really cut the development time;
  • Data Flow: focused on the aspects related to the gathering, cleaning-up and managing of the Raw Data that comes from the devices, with implementing the data transfer and serialization with the right protocols and the right format. It is very important to estimate the data volumes, the ways for analyzing them, in order to get the best approach possible, following the Polyglot Persistence pattern, which is fundamental for a big-data scenario.
  • Cloud: focused on the Cloud aspects of the solution, as a data/event management platform.
  • Security: focused on the verification of the security aspects, which affect the solution as well as the development. The underlying process is the Threat Modeling, by which the security is considered one of the main part of the development process.
  • Legal: focused on the analysis of the law and regulations, national and international, which the solution must consider in order to become a marketable, to be aligned with sector standards and manage adequately all the incoming data. This aspects impact in a very high way the choice about hardware, software and the business model, that must be conformed with the standards in force and the different regulations governing the service offered by the solution;
  • Delivery: focused on the deploy of the elements of the solution, speaking about both hardware items and services ones. This is useful for getting the what-if reaction when the deployment troubles occur, in order to get the best sustainability of the solution.

All this bobble-aspects explicitly contribute to the evaluation of the solution cost/benefit.



The Make-Measure-Learn (MML) loop aims to fast experiment different hypotheses and assumptions:

  • Make: create a prototype to test the Vision assumptions and starting to consolidate the reference team;
  • Measure: analyze the prototype according to the Goal and related metrics. Also check whether the organization and the team are confident with the solution creation;
  • Learn: adopt the necessary changes depending on the results.



The so-called flashback leads the team to match the state of the solution with a fast alignment, IoT driven, action, where the observer team will check the work of another team directly. During this action the observer team can ask a limited number questions in a short timeline.

The flashback ceremony, forces the teams to go deeper on some aspects.


Continuous Improvement

The goal of the Continuous Improvement is to reduce to the minimum the changes to the hardware side, which is a long-term and expensive task. The suggested approach is to focus on the firmware side, the services and the cloud, in order to improve continuously the overall solution and to be able to workaround on the devices in case of physical troubles on them.


Continuous Integration

The Continuous Integration pushes the team to integrate continuously (and as soon as possible) every change, in order to identify problems and resolve them in a timely fashion.  This helps to reduce the costs associated to the unexpected behaviours.


All the elements described in the guide are the result of direct experience and many discussions with experts, coming to extract the essence of complexity that a new IoT initiative brings with it, both from a technical and organizational point of view.

The guide is a "pretotype", to represent a constant and evolving work depending on the field of application of a new applications IoT. In this sense, the suggestion is to use the guide as a reference in the context of your own reality according to you own corporate culture.