Why is this necessary? Several teams often work on the product, and sometimes one of the teams does not have time to complete its part. It was our case: we were developing the web and back-end parts of the IoT system, and the hardware team on the client's side did not meet the deadline.

At the same time, the product owner has already scheduled demonstrations with customers, which he would not like to postpone because some meetings can't be scheduled a second time, or the impression will be spoiled. But we found a way to get out of this situation and meet all the deadlines with little effort.

About the product

Our client's company manufactures smart scales. In our collaboration, they were trying to optimize the process of controlling the storage of products in the sales halls of supermarkets, and the idea of their product was as follows:

Demonstration process

A test shelf had to be installed in one of the supermarkets for a successful demonstration of the system. It was also needed so that our team could test all the subsystems that should work with the shelf.

According to the demonstration plan, the client had to show the process of adding a new store and its employees to the system and adding shelves to the selected store. Real-time shelf data was displayed on a separate dashboard, and informative reports on shelf performance could also be created and viewed. In case of deviation of temperature or insufficient quantity of goods, employees were notified and were able to solve the problem with the shelf.

Problem solving

What ways out of the situation did we have? We could do nothing because the responsibility for the failure of the demo was not on our side. At the same time, delaying the project delivery date is always unpleasant. We will send the invoice later, there are risks that we will have to rework some tasks later, and the team members have already lost the context and are working on the tasks of other projects. Even more critical that our client got into an unpleasant situation because, without a shelf, it was almost impossible to hold a demonstration successfully.

So yeah, we just decided to create a software equivalent of a physical shelf that would do all the same things as a real shelf when finished.

We started with requirements development because we had to consider many details regarding the work of the shelf. First, we thought about how customers and employees will interact with the shelf. They can accidentally lean on the shelf, which can cause the system to get false statistics. You can also forget to close the refrigerator door, and the temperature will start to rise. After working through possible user scenarios, we decided that the shelf, in this case, could be replaced by a separate (or not separate) application that would be able to easily add a large number of new shelves and send data about the operation of each shelf. We immediately informed the client about this idea and that when we do it, it will be possible to run a demo using our test application only. It will be as relevant as possible to how our admin panel will work with real shelves.

The work took us a couple of days of teamwork. We simulated the possibility of turning off the shelf or losing connection with it with a probability of 1% every minute. Also, every minute a random amount of goods was "taken" from the shelf, and if the shelf remained less than 30% loaded, with a probability of 50% it was filled again. The typical storage temperature range of the product was from 2 to 6 degrees Celsius, so every minute we increased the temperature with a probability of 5%, and when the temperature exceeded the specified range, the employee received a notification. We also considered the possibility of sending false indicators, which the system had to filter and not take into account in the general work statistics.

With the help of the software shelf, our team tested all the necessary subsystems and demonstrated the operation of the product to the client. A few days later, our client successfully held the demonstration to their customers and fully validated the product hypotheses. When the physical shelf was ready after two weeks, we added it to the system. We ensured that our software counterpart worked similarly to the physical shelf, which again emphasized the correctness of the chosen solution to the problem.

Conclusion

We at Daiquiri Team believe that the development team must be aware of the client's tasks and problems, even if they are outside the competence of the developers. This is how the team gets enough background to understand the entire client's problem and be able to solve it completely. Saying that you can't continue work because third-party system components are not ready is not expedient. Components can always be replaced with another solution.

As a developer, I truly believe that all developers should care about the end customer of the product, at least partly. I participated in many projects, and I feel it from real life, so if you want to work with me on your IoT project or any other projects — write me directly or contact us on the website, and we will be glad to discuss and solve your problem.