06. 11. 2024
AI, Log-SIEM, Machine Learning, NetEye
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.
Michele Santuari
Software Architect at Wuerth Phoenix
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
Latest posts by Michele Santuari
28. 12. 2020
Development
Research & Development – Spike (Part 4)
23. 12. 2020
Development
RPM/ISO Repository: Disk Space Optimization
05. 10. 2020
Development, NetEye
Research Activities: A Fully Distributed NetEye