One of the biggest challenges for a platform team is planning their work in a linear, visual way. At IT&Care we work in PIs, our epics are high level objectives that we would like to work on which are further broken down into features. These features are prioritized by the product owner and planned for each PI based on the team capacity. The PI goal is fixed and the output of the features define the success of the team/ PI in most cases.
The truth however is that, these delivery plans betray the true nature of platform development. We need to be more iterative than linear in our approach. The true success of the platform team is on how fast they can make the right choices. For this they need to try out something, deploy or make changes to an environment… see how that impacts the developer activities, and if that does not work, make changes or change directions, deploy again, test, iterate…
With the traditional delivery plans, we have clear starting dates and end dates for features. This reflects an output-faced mode of operation, instead we want to focus on outcomes.. Outcomes that changes the developer behavior and boost their productivity. The platform team need to work towards getting evidence and feedback from the developers on how these changes are impacting their day to day activities. What would they like to have in the platform? Which technology they would like to access next or trial? That would be the true measure of efficiency of the work from the platform team and how they are meeting the needs of the stakeholders.
Objectives and Definition of Success
Instead on spending time on creating features and stories for the team, the product owner can focus on defining the objectives for each PI. The objectives define the qualitative goal for the team. These objectives help the team realize the wishes for the platform in a tangible and focused way: for e.g.
Automate update management on all databases
Decouple release from deployment
Provide end-end visibility on user requests etc.
These objectives are backed by quantitative measures (definition of success) to access whether or not the team actually achieved this goals.
Using this information the team together with the P.O can now brainstorm on how they would achieve the PI goals. Looking out one PI in advance the team can make strong, educated guesses about spikes and features they think will achieve their quarterly goals. They will have complete freedom in making changes to the features in a PI to meet these objectives. This should provide enough learning opportunities for the team on how their ideas are working, what moves the needles forward and what their next guesses should be.
Here is how the team roadmap looks like
Measuring progress:
Progress should not be measured on how many features has been delivered or with the team velocity. Instead, progress should be measured by how well they have improved the developer productivity. There are too much uncertainty and complexity in working on platform teams. Outcome based roadmaps ensures that leaders and teams are being transparent with each other, realistic about their goals and targets and most importantly driven by real value.
Comments