We described in a prior blog post how the Research & Development team has adopted a full Agile approach. Although the basic principles remain unchanged and all team members have embraced a mindset of self-organization and team collaboration, in recent years new challenges have arisen that require continuous improvements in our methodologies.
In particular, in this blog post we focus on how the System Integration business unit handles the prioritization of development activities.
Problem Statement
Adaptation is one of the key principles of the Agile methodology, and that also includes changing priorities based on results and market reactions. Adaptations are unavoidable and continuous improvements are essential to constantly deliver high product quality in increments. Thus the requirements of the features and improvements to be implemented can change at any time.
But…
That means that if changes occur during the development phase of a particular feature, developers need to re-adapt what most likely was already designed and partially implemented. The outcome is that developers may feel frustrated. In other words, changes are usually welcomed, but they should only be introduced when they can be accepted.
As a consequence, the Research & Development team along with the heads of Product Management must work together to forge a collaborative and continuous adaptation process aimed at mitigating the feeling of constant change to the focus of development activities.
The Solution: Overall Prioritized Backlog
A Prioritized Backlog is an ordered list of changes known to the entire team that are needed to improve a product. Product Management is responsible for organizing and maintaining the set of tasks which must be achieved in upcoming releases.
An example of the Overall Prioritized Backlog dashboard
The Overall Prioritized Backlog in our System Integration business unit, shown in the figure above, contains not only the new features and improvements of a product (e.g., NetEye) but also the bugs which should be fixed and even the technical previews which will be demonstrated to customers.
The main advantages of the Overall Prioritized Backlog are:
It is visible to all those people who are involved in the development or deployment of a specific product;
It is transparent because developers know exactly what they will do next, and the consultants and the sales department are aware of upcoming improvements to each product;
It is fair to all teams since each can add feature/improvement requests, but the priority can only be changed by consensus.
The latter point is very important because the Backlog is refined during a weekly dedicated meeting in which the Service & Support team, Product Management and the Research & Development team (in the most recent meeting even the head of Consulting has joined, providing new points of view) discuss the current status of all ongoing and upcoming activities and agree on how to assign them priority based on their experiences. The result is that the Research & Development team has a clear view and vision of what will change, and can easily adapt to newly scheduled activities.
Backlog Refinement meeting: the bottom right shows the Overall Prioritized Backlog issues
During the Backlog Refinement Meeting, shown in the picture above, priority is assigned in terms of both the impact of and estimated effort needed for every single feature/improvement. Accordingly, the Research & Development team uses a well-known consensus-based estimating technique called Poker Planning. Further blog posts will explain this technique in detail.
In conclusion, the Overall Prioritized Backlog provides the outline for further improvements to our products and guarantees a more high-level overview to the teams of the System Integration business unit, helping the Research & Development team to be more focused on the most relevant activities so that significantly less time is wasted and the desired product improvements are continuously delivered.
Hi, my name is Michele Santuari and I am a Telecommunication engineer felt in love with OpenFlow, the first attempt of centralized network management, provisioning, and monitoring. I embraced the Software Defined Networking approach to discover a passion for programming languages. Now, I am into Agile methodologies and crazy development process management.
Author
Michele Santuari
Hi, my name is Michele Santuari and I am a Telecommunication engineer felt in love with OpenFlow, the first attempt of centralized network management, provisioning, and monitoring. I embraced the Software Defined Networking approach to discover a passion for programming languages. Now, I am into Agile methodologies and crazy development process management.
Scenario NetEye 4 is a comprehensive monitoring platform which natively supports Business Processes. A Business Process is an abstract view of a customer’s Business from the Application point of view. Usually, it’s a collection of Icinga2 checks aggregated by “AND, Read More
Suggested reader skill level: Proficient in software development Reading time: 10 min What you will learn: “Blockchain is hard.” Even if everyone has heard this sentence at least once, the truth is that it's not. It’s just a database, with Read More
Say you're using the SIEM Module in NetEye and are deploying the Elasticsearch Agent to your clients. You'd surely like to know if those agents are still sending data and are still connected to the Elastic Fleet server. I had Read More
Have you ever thought about how to monitor your NetEye system or other critical applications in a network failure scenario? To manage this scenario, in some customer cases some solutions have been implemented using SMS notifications, thus relying on the Read More
In my previous blog post, we saw how it's possible to index some documents that we created by crawling our NetEye User Guide, then applying the ELSER model in Elasticsearch to create a bag of words for searching that takes Read More