In October 2018, just before the OVHcloud Summit, I joined the Product Unit Platform as Program Manager. A new challenge came with this new role… to support the team working on a new product: OVHcloud Managed Kubernetes. The deadline was short, we had lots of things to do, and we needed to provide visibility to both Management and Development teams throughout. But as a Program Manager, I had the right tools in my bag: SCRUM and “agility”.
My first action, as a newcomer, was to ask the team to express themselves. I wanted to understand how the group worked, as listening is one of the first steps in the agile construction process.
When dealing with significant changes, it’s necessary to do some change management and accompany people throughout the process. All too often, the word “agile” is used in a way that sacrifices common sense, becoming the scapegoat when unforeseen events or delays in delivery occur. Reassuring the team and explaining them that agility wasn’t going to make their lives harder, or add an overhead to the daily tasks, was a key objective. We achieved this in several ways:
- Organising several presentations and methodology training sessions
- Holding physical meetings with the teams at Paris and Lyon
- Explaining how the method would work during a real sprint
- Collectively drafting a guide to our implementation of the SCRUM method
Once we had validated the fundamentals together, we moved on to the methodology. At this stage, we could begin to add value to the project by using agility.
Value in our agility
After a few sprints using the agile method, our group found some stability, i.e. we had reached a good “velocity”, as we call it in agile practitioner slang. Velocity is an important value, and a determining factor in our ongoing journey towards agile telemetry.
To quickly (re)define it, velocity is the number of “effort points” the team is able to accomplish during a sprint. This key indicator allowed us to assess how much work our team could deliver over a given period of time.
Velocity and effort points in our Managed Kubernetes project
Let’s look at a simplified schema of how this method worked in our Managed Kubernetes project:
Here, we have three main steps. For each of them, we collected its quantitative values, to get a consolidated view of each step’s velocity, in addition to a global view of the whole project. With these velocities, we got a good view of the project’s advancement, and some visibility on the deadlines.
Example :
This agile model allowed us to achieve our goal and deliver the Managed Kubernetes project to our customers on time, and this success subsequently led us to share these good practices with all teams in the Product Unit.
But a second challenge presented itself, as maintaining this process required a lot of discipline, with numerous opportunities for mistakes to be made. And so our next step was to create a tool capable of reducing the risk of error, while maintaining full visibility of projects at both the macro and micro levels. This is what we will present in detail in a future blog post: Agile telemetry by OVHcloud.
Program Manager, Scrum Master, Facilitator, or Project Manager. Team coaching and project orchestration are hobbies.
Group spirit, sports, and challenges are part of my daily life.