Accelerate: A way to be more agile and catalyze Product Management

I previously shared our approach, awarded by Google Cloud DevOps, to deploy and work on Accelerate capabilities in some of the teams of Decathlon Digital (Align to Accelerate: an approach to change culture and practices through Digital transformation). I detailed how we engaged in this transformation but didn’t share any impacts or outcomes. I propose here to do it through some examples.

Prerequisites

First of all, wanting to go faster means you can know what is your current level of performance. Without metrics, you base this knowledge solely on apriori and feelings. As I shared in the previous article, you must measure with 4 keys (the best would also be to measure your reliability). You can do that with:

• the DORA Quick-Check tools
• manual measurement
• full-automated tools

To go deeper, it’s necessary to assess your level of each capability. A 2-hour workshop, using a maturity matrix, allows you to do that.

Going fast & safely

For many, being able to deliver faster comes at the expense of stability. And conversely, high quality can only be achieved at a more moderate pace.

Scrum theory says: “Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.”

Kanban leads us to find the right team organization to promote pull flow by a regular and rapid throughput.

So, the faster you can develop and deliver digital products and services, the more you’ll learn about your context, what you’re producing, what your obstacles are, and what solutions you need to find. These are the three DevOps ways of doing things: “Flow, Feedback, and Continual Learning and Experimentation”.

Lastly, Jonathan Smart in “Sooner, Happier, Safer” defends the principle of “Think big, start small, learn fast”

To summarize, you can deliver fast and frequently small parts of work to learn early and quickly correct in case of trouble. Speed and stability are not mutually exclusive.

The ninth principle of the Agile Manifesto

Continuous attention to technical excellence and good design enhances agility.

Closest to delivery and operational products and services, you have, in the value stream, all the technical infrastructure. To be performant, you have to respect some technical principles:

• Automate all that you can: tests, deployment, alerting, data change… to not be alienated to low-value tasks — sources of frustration, brown-out, wasted time, and mistakes and stay focused on creating value.
• Monitor and observe your products, to keep confidence and be sure your business is up.
• Create a pipeline and infrastructure that enable you to quickly develop easy-to-maintain code.

To summarize, the challenge, here, is to build a performant race track allowing competitors to go fast and safely.

Then, the DORA Core Model allows you to focus on your first actions:

These capabilities predict your performance which in turn predicts your organizational performance — commercial and non-commercial — and the well-being of your team by less deployment pain, less rework, and less burnout.

DORA’s model evolves every year through the Accelerate State of DevOps. For example, this year, they shared the impact of some capabilities on interesting outcomes :

The aim is therefore to improve the speed of your value stream. In this way, you have to generate a “vacuum” near the exit of your pipeline and create and maintain the best technical stack to develop and deliver your value.

How to measure that it works and the effort and time invested to improve were right?

DORA’s 4-keys metrics should help you. Implement a good dataviz to follow the evolution of your metrics, particularly Leadtime for Changes and Deployment Frequency. The first one, measuring the time for a commit to be deployed into production, should decrease. The second, measuring how frequently a team successfully releases to production, should increase.

Product Management and team organization: catalysts or break of your performance

All right, developers in your team have well-understood the benefits of the right infrastructure to develop and deliver value quickly and safely and have set it. But nothing !!!

You don’t observe any enhancement of your performance. What a frustration !!! We have invested time and resources. You have agreed to delay some key topics, change your roadmap and the team doesn’t deliver more…

Perhaps only tractors or abnormal loads drive on your superb freeway? Don’t you have too many topics per year, quarter, or sprint, too big and not prioritized?

You have to go further from DORA Core Model. There are several capabilities you can activate in your processes.

Reminder: As discussed in my previous article, please adopt a small-step approach to:

- Better understanding of the impacts of your actions

- Apply the powerful capabilities to be focused and performant: Limit WIP (see below)

Work in small batches and focus on it

It doesn’t matter if you follow a framework and its type. The optimization of your development/delivery pipeline in a DevOps approach leads you to progress from development through test and operations into production in a matter of minutes for finalized code.

If you engage your team in a several-day or several-week way of development of big items, you lose the benefit of your performant pipeline. Admittedly, your finalized code could go into production fast but how often? How long does it take for your team to develop this crucial feature written, in detail, in a specification that is more than thirty pages long?

The worst effect of this approach is not the long time spent. Still, the tunnel you entered cuts you off​​ from collecting feedback, increases the risk of not doing the right product and cumulates potential issues with merging and integration phases.

Here again, the framework is not the problem. In Kanban, a too-big item, not sliced, will have a too-long cycle time. In Scrum, a Sprint Backlog item too complex or too big will never be done for the end of the sprint, even if you have a performant pipeline. In the same way, a sprint with too ambitious objective or too many objectives doesn’t allow your team to be performant, even if your team has the best system of estimation.

Then it’s crucial to adopt best practices of Product Management to refine your objectives and items. For example:

• Adopt tactical objectives, achievable in the medium term, to decline your strategic objectives, increasing your impact.
• Commit small quantities of work and don’t start anything else.

This approach predicts a better performance.

Limit the work in progress

“Stop Starting, Start Finishing”. What a powerful concept applicable to all levels of action inside an organization. Limiting the work in progress puts the right pressure on the flow to be efficient.

This counterintuitive mechanism is based on Quering theories and modelized by Little’s Law:

So if your team can deliver an average of 5 items per week and have 10 items in progress, it will take 2 weeks to process everything. With the same level of performance, if it limits the number of items in progress to 5, its performance (Lead time) will be twice as good.

The average throughput depends on the number of people inside the team and on their skills. For a constant budget and limited team organization, you might consider the average throughput constant in the short/medium term.

On the other hand, to help your team to be performant, work on its skills, and improve its average throughput, you can put WIP limits as a constant. The more your team improves its average throughput capabilities, the more its lead time will decrease and the better it will perform.

The same causes produce the same effects, as a Product Manager or a Leader, the more objectives (even worse if they are not prioritized) you give to teams, the more you increase confusion and put people inside a non-secure and non-performing environment.

All these Product and Management capabilities should help you and your teams:

• Have Vision and Mission
• Be able to make choices, take priorities, and agree to make renunciations
• Build and share roadmaps
• Refine regularly the work

To summarize, most of the best Product practices lead to help your team to be more performant.

Close the loop

You certainly know the DevOps loop. There are a lot of examples and declinations on the web. It comes from the Three Ways of DevOps to embrace more Agile and Continuous Delivery working approaches:

• The First Way: The Principles of Flow
• The Second Way: The Principles of Feedback
• The Third Way: The Principles of Continual Learning and Experimentation

In this way, we can schematize the benefits of an Accelerate-based continuous improvement approach as follows:

All capabilities in the DORA CORE model allow to:

• Improve Delivery Performances
• Improve Quality & Stability
• Decrease Rework
• Decrease Pains to deploy

The principles of automation (CI/CD, Tests, Deployment), monitoring, and alerting provide serenity and time to do more valuable tasks for Engineers. Regular and frequent deliveries make them more involved and proud of their work.

Then they can better participate in the refinement phase and have a better comprehension of what they have to do and why.

Therefore, the improvement provided by DORA CORE capabilities allows the team to better prepare its priorities or the work to do. It could be more autonomous in the refinement phase and also give the possibility for the Product Manager to be more focused on discovery, collect more feedback, and create more value.

The combination of smaller batch sizes and WIP limits constrains your value stream to be more fluid and swift, by a “mechanical” effect. From an overall perspective on the DevOps loop, we have seen with these capabilities, we can decrease, not only the lead time for changes but also the cycle time.

This empowers other benefits:

• Better predictability: The team enhances its knowledge and its ways of working. It has a better understanding of what and how to do, passing from unsure estimation to predictability of its work, in the short and medium term. The roadmaps could be easier to design and more reliable.
• Test & learn earlier: Mainly thanks to Trunk-Based Development and Feature Flipping, the team can deliver daily (or more frequently) and adopt A/B testing practices, more efficiently.
• Less risky approach: As you deliver more often, you avoid troubles with merging, you can reduce your tech debt and you’ll notice service interruptions more quickly. Working with an Accelerate approach brings you closer to Site Reliability Engineering, as measured by reliability.

Conclusion

Accelerate is often reduced to an Engineering approach or, sadly, a way for Management to control and objective teams and/or people’s performances only by following the measurement and not in a continuous improvement mindset.

We have seen here this is, actually, a common concern for a Digital development team — aka product team — in an end-to-end approach. But not only. To be performant you can’t only work on the technical capabilities or the process capabilities or the product capabilities. It’s a holistic approach to adopt with teams, managers, leaders and led by Agile people. Leaders have a crucial role with the cultural capabilities: empower transformational leadership, Westrum’s generative culture, learning culture, and well-being.

To conclude, Accelerate isn’t a silver bullet to fix all your performance issues and has to be completed by other approaches like Team Topologies or unFix for organizational performances, OKR to decline well your strategy and have more impacts but this is a way of committing people and teams to a pragmatic and agile continuous improvement approach. A real Lean approach!

Acknowledgments

Special Thanks to Helene Soulard, for your Agile mindset, your pragmatic and relevant ideas, your energy, and your smile. Ever more efficient.

Thank you, Antoine Comble and Loïc Dubart for proof-reading.

And thanks to the Decathlon Digital Agile community for sharing and brainstorming. The best is still to come!!!