23. 12. 2019 Michele Santuari Unified Monitoring

Research & Development – Sprint (Part 4)

In a series of blog posts (1, 2, 3), I described how the R&D Team development process has changed to meet new requirements, to improve delivery time and quality, and to increase adaptation.

As mentioned, the R&D Team development activities are planned and prioritized for each NetEye release. The main problem of such an approach is that is very difficult to estimate the delivery of big changes with a life span of two months. Moreover, developers do not feel the urgency of closing tasks, because the value will be delivered only after the release.

To solve these issues, we have recently introduced the well-known Scrum Sprint approach, a fixed time-boxed period in which the development team commits, with the Product Owner, a certain amount of work to be delivered.

The work planned for a Sprint is a subset of the prioritized tasks contained in the Backlog. The development team planned the tasks within a Scrum Sprint leveraging the Planning Poker so that a number of story point is committed in each Sprint.

To graphically visualize a Sprint, we use the burndown chart: the sum of the story points of all the tasks in the Sprint are on the vertical axes and the time, which is time-boxed based on the Sprint duration, on the horizontal one. The grey line represents the ideal trend to close the Sprint tasks and the red line the real one. The result is a clear view of the status of the Sprint and its progression, which gives the team a better focus on delivering value faster.

Moreover, after each Sprint, we have the so-called Sprint Review meeting in which all the developers present the outcome of their work to key people close to our customers: Product Owner, Consultants, and Support Teams. In this way, we reduce the feedback cycle and the developers are happier to frequently deliver useful solutions for our customers.

Nevertheless, we are continuously improving and refining our development organization because, for example, it is not easy to estimate the correct amount of work that can be done in a Sprint as well as to close tasks continuously, not only at the end of Sprint.

Michele Santuari

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

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive