29. 12. 2021 Alessandro Valentini Development, NetEye

NetEye Satellites: a Process-Growth Opportunity

During 2021 we decided to officially support Satellites as part of NetEye. Satellites were already widely used by our customers, in particular as part of the Icinga 2 monitoring infrastructure, but a complex manual configuration was required to install them.

The development team faced a difficult challenge in fully supporting Satellites: providing an easy-to-use solution for every customer but also supporting a smooth migration for existing installations, each of which is slightly different from all the others.

This is quite different from what we usually do: usually we start from a set of use cases provided by product management, support and our consultants during weekly backlog grooming meetings. Then we implement the solution and show the result at the end of the sprint. During the first post-development workshop we received negative feedback and discovered that our usual process in this case was not sufficient: we needed to take into account all the possible variants of existing installations, not just the general use case and the final vision.

For this reason we introduced a much faster feedback cycle involving the most active consultants on Satellite installations, asking them what they are actually doing with customers, including minor changes, maintenance procedures etc…, and collecting different experiences. But this was still not enough: most consultants are busy with customers almost every day, and it was nearly impossible to find a day when we could all get together to mull over all our ideas.

Then we tried to organize a group chat about each specific topic, where we could directly ask straightforward questions and collect answers from everybody to immediately course correct the direction of development. Furthermore we asked consultants to choose two short time slots (like half an hour) to schedule face-to-face feedback meetings to discuss more complex problems.

Not all our external people are able to collaborate every time, but we defined new requirements and spotted potential problems in multiple meetings, allowing the R&D team to react quickly by correcting errors and addressing simpler migration paths. Furthermore we’ve put enormous effort into testing migrations ourselves from proposed non-standard scenarios and, when it hasn’t been possible to automate the migration, to provide a how-to procedure covering different migration paths.

The result isn’t perfect, but we’ve seen a strong reduction in migration issues and far fewer complaints from end-users. Quick feedback cycles, chats and reserved time slots for feedback meetings are now part of our development process, and our non-developer colleagues are even more directly involved in early development phases as well as during the design phase when the R&D team gets the feeling that its knowledge base isn’t sufficient.