Having control over distributed system of devices makes a difference – especially when you work with industry, where every minute of delay has great importance – can generate real loses.

One of our client is actually producing vending machines, which are installed in various factories, where with the use of cards (token) the workers can take anything they need for continuous work – gloves, glasses, drills, etc. There are many advantages of using such machines – factory doesn’t have to invest in local storage, they pay only for the actually used items (no need to pre pay), workers have access just in time, when they need something for their work, however with limits so that they can’t withdraw too much, too often (steal).

Our client was considering to build a new SaaS platform that is going to be used for both – the factory, and workers, but also suppliers of materials stored in vending machines.

However they were a little undecided – having bad experiences with software production in the past – lacking predictability of costs and returns of investment.

We suggested that maybe we should start with the determination of what the new platform should change? What are the business and technical drivers – finally, maybe there are some hypotheses that we could test quickly?

Business drivers

After couple of workshop sessions we have determined that the main beneficieries of the systems are the goods suppliers and their warehousemen agents. They are actually the personas responsible for the bilateral business growth.

So the business drivers were as follows:

• high availability
• stable performance​
• reliability of data to be used for costs, revenue, sales prediction of items stored in vending machine

Serving business value usually drives some architecture and infrastructure demands. Thus,

Technical drivers

• scalability
• continuous integration and deployment – zero downtime
• high security of data
• infrastructure costs awareness
• testability

Having this in mind we also wanted to describe the fears – risks, and suggest some mitigations

Risks and mitigations:

• When testing the performance and simulating heavy loads – the cloud resources could be consumed faster – the team would alert about sudden cloud costs increase
• Flexibility when there is a need to deep dive into some experiments
• Unplanned leaves – especially on the client side, may result in poorer communication
• The changes of the sprint scope – by design not accepted in Scrum, however – as this was a pure R&D experiment, we agreed only if there were interesting findings on our work, worth changing the direction slightly ​

With this solid preparation, we got green light to start with 4-sprint long (2 months) PoC project (proof of concept).

PoC characteristics:

• dedicated team on i4B side with proxy PO
• business PO and technical leader available on client’s side
• scope clear enough to start with first sprint
• sprint goals clear for all 4 sprints
• 15 min daily
• biweekly 3-hours long “Sprint Shift” (Demo/Review -> mini-retro -> Planning)
• PBR (product backlog refinement) sessions – 2-3h a week
• remote work

During these two months of purely agile cooperation, with adjusting the direction, grooming the backlog items and presenting live results on the pre-production environment as early as possible, we achieved:

Key results of PoC

• Improved synchronization / initialization / data between the management platform and vending machine operating system
• Visualization of synchronization load vs. stability of the new architecture
• Improved numerical parameters of requests
• Monitored reaction time while increasing the load
• Ready synchronization testing environment
• Draft of the TO-BE API architecture and infrastructure componets
• ​Observability of the new API’s responsiveness during synchronization of machines and prepared load tests – presentation of metrics
• ​Open possibility to develop reports and alerts

The results of this PoC apart from particular artifacts were also – increased trust, proven predictability of our work, tested cooperation.

That was a solid foundation and a good credit for further work – the proper new project – the full next generation environment for vending business.

If you liked the above story, you may also be interested how we approached the new challenge having gained trust. In the next case study, we will cover topics of

• personas identification
• customer journey
• user story mapping and cutting the scope for MVP
• poc for infrastructure and architecture — how to minimize risk and grow trust
• 30+ sprints development