Agile telemetry at OVHCloud – Part II

In our previous post, we outlined the reasons that led us to create an Agile monitoring tool. To capitalise on this collective success, we needed to:

• Establish an efficient, simple and universally-accepted methodology to support the development teams.
• Set out the different visions necessary for the good handling of a project.
• Define the micro vision, for development teams.
• Define the macro vision, for sponsors.
• Industrialise this innovative concept for other teams at OVHcloud.

As with every new challenge, there was an element of complexity. OVHcloud is an international company, and our teams are distributed all around the world. The tool therefore needed to be easily readable and simple to maintain, and the indicators had to update automatically, as our teams work in a changing context where there are often unplanned events

We needed to create a tool that would allow us to remotely measure the performance and progress of teams in real time, and update the information needed to manage a project. This is our telemetry.

“Before engaging a development team, create your construction plans… draw!” With this idea in mind, I started to sketch a few drafts on a notebook, then on software.

This first sketch highlighted what I wanted to show my teams. We could track our progress on every subject we were working on (the Epics we talked about in part I). We were able to see if the roadmap was achievable, based on the rhythm of the team, and measure the team’s performance. Finally, we had a tool that reconciled the micro and macro visions.

But how do you make this board come alive?

At OVHcloud we use a ticketing tool: JIRA. This tool helps us in our everyday project organisation. However, it doesn’t show the information we need. Nevertheless, we can make it talk…

Based on this concept, we and the teams have built a metrics table with the GRAFANA tool.

This is our Agile telemetry

In this second blog post, we will be focusing on the macro vision. The next post will look at the micro vision part. 😉

Macro vision

This part of the table gives us a MACRO view of the progression throughout the quarter, and the associated charts.

1^st data block: Quarter KPIs

• (A) Predictability. Are you able to deliver all projects/requests? With this indicator, top management and development teams can monitor their capacity regarding deadlines. We are able to monitor this data with the following formula:

• (B) Quarter progression. Shows the completed parts of the quarter.

• (C) Team velocity. The number of story point completed per day. With this information, we are able to built our future sprints, and maintain the team’s rhythm.

• (D) Average impediment. This information is critical to building the next sprint and estimating the security coefficient.

Example

Let’s say we have a seven-person team, with a capacity of 350 hours per sprint (7 people x 5 hours/day x 10 days). If our team logged 58 hours as impediments during a sprint, we could use this information to tailor the security coefficient for the next sprint.

On average, the team use 17% of their time to resolve impediments during a sprint. With this information, we are able to make a security coefficient.

2^nd data block: Sum of Roadmap Epics

This table collects the expected epics. It shows the number of story points evaluated by the teams, the number of points they have already completed, the number of tasks “not estimated”, and the rate of progress. With this table, we can give figures concerning a progression. 

3^rd data block: Quarter Completion

1. Epic completion (1): During each week, we can watch the roadmap’s progression. Sometimes, we will see the completion roadmap decrease. It’s normal, because we have added a story point in our plan. (4)
2. Impediment count (2): This is the number of times the teams came out of the sprint due to impediments.
3. Impediment duration (3): The total time spent on impediments.
4. Delta story point planned (4): The number of points entering or leaving the roadmap, allowing us to see any variations on the charts.

4^th data block: Draw me a graph!

• A.  This figure represents the progress curve of the roadmap. It is created using the sum of the completed epics.
• B.  Our burnup roadmap.

This graph represents two curves:

• a – The curve of the elements quantified and estimated by the teams.
• b – This is the limit, calculated using the velocity of the team on the number of days in the quarter. We then add the team’s safety coefficient.

• c – The curve of the tasks completed by the teams.

Conclusion

This dashboard brings together all the information that we have managed to pull together, thanks to the amazing contributions of the teams. By believing in the values and trusting the method, the group already has a maturity that they have achieved themselves.

For our top management, this board shows all the key information they need. When the predictability is green, all is well. When something is wrong, they are able to take the right decision, whether this involves changing priorities on the roadmap, or hiring new people to help teams successfully complete it (for example).

In our next post, I will explain the micro vision in detail. Until then, keep Agile !