How Dynatrace does Scaled Agile. Part 1: Choosing the right framework

Dynatrace was an Agile company from the start, but once it started growing, the need for a scaled Agile framework also grew with it.

Written by Hermann Lacheiner and Andrea Holl.

Welcome to part one of our 3-part series on how Dynatrace created the Scaled Agile Interface, an Agile Framework that we developed to suit the needs of our growing company. In the first part, we will look into the research we did to find the right framework and why we eventually decided to build our own. In the second part, we will write about what lessons we learned from the implementation phase. And in the third part, we will explain more in detail how the Scaled Agile Interface looks like.

We hope that you can learn something from our approach and would love to hear more about your own ways of doing scaled Agile in the comments.

It’s really exciting to see your company going through incredible growth. And it’s especially amazing to see how it can keep producing a high-end product at a high pace with so many people working together.

Dynatrace has been Agile since its birth. Just a few years ago, the number of employees was small enough that it was quite easy to know everyone in the company and this helped the company develop its product smoothly. However, since we opened several labs in various locations all over the world, it was not possible anymore to only rely on personal connection for efficient collaboration. So, we needed to find out how to scale our development to provide alignment while maintaining autonomy in the teams. This was important to keep transparency, and to remain focused on the most important topics, while at the same time continuously growing.

Successfully scaling the organization was one of the reasons why the Agile Competence Center was founded within Dynatrace. Hermann Lacheiner and I, Andrea Holl, (Agile Coaches at Dynatrace) were part of the team that made this scaling initiative happen. We would like to tell you the story of how we planned and performed this exciting journey and how the solution looked like in the end. Enjoy reading!

There is no such thing as a ‘silver bullet’

As Dynatrace continues to grow, new teams around many new topics have been formed. The combined expertise of so many people gives us the power to develop our product even faster and helps us push technological innovations very quickly. Nevertheless, alongside the opportunities mentioned, the increasingly rapid growth also leads to new challenges which need to be tackled along the way.

Dynatrace has been an Agile company all along. When the company was still relatively small, the development teams worked in a synchronized two-week rhythm where new releases are deployed continuously. In general, the teams applied a customized Scrum approach for efficient collaboration. But in fact, every team could choose which way and the methods that worked best for them. This approach worked well for quite a long time. But the day came when it was not possible any more to directly speak to all your colleagues over a cup of coffee. It became increasingly difficult to align teams within the organization, keep transparency and to be aware of the big picture of the product. We needed to scale our software development throughout the entire organization. Fast. But keeping the autonomy in the teams while creating alignment was one of the major elements which needed to remain.

When we started this initiative, we knew that we needed to treat the entire change with a lot of respect. There is no such thing as a ‘silver bullet’ when scaling an organization, as also Dan North mentioned in his article. We did not want to change the successful fundamentals of our organization. Many elements have already been incorporated quite well: like a two-week deployment rhythm, agile development teams and their mindsets or some specific roles in the teams. The idea was to use these elements and build missing components on top of it. That’s also the reason why we did not just implement SAFe, LeSS, Scrum@Scale or one of the other existing scaled agile approaches.

We all knew that such changes are not done overnight and that having enough time is crucial for successfully leveraging our pre-existing Agile development. That’s why we spent enough time to gain deep knowledge about these already existing scaled Agile approaches and about current challenges within our organization, on the one hand. On the other hand, we established a change advisory board to get early feedback and to communicate to the entire organization.

We took the following three steps in this evolutionary process to build our scaled Agile way of collaboration.

Research, research, research

We started with conducting research for already existing approaches like SAFe, LeSS, Scrum@Scale, The Spotify Model and many more. Besides the overall impressions and the main guidance of these frameworks, we had a deeper look into things like when to use them, how they differ from each other, and what the main advantages as well as disadvantages are. These insights were the foundation for all further steps.

During this phase, we found a fascinating study from 2020 which was conducted by the University of Applied Sciences Koblenz in cooperation with many well-known partners like Bitkom, IPMA, GPM, PMA and SPM. It shows interesting results regarding the usage of scaled Agile approaches. In total,
35 % of all large scaled Agile companies said that they had developed their own framework but had not used any of these existing ones. This result underlines the importance of keeping successful organizational fundamentals and not giving them up for the sake of an established framework.

Analyzing how other companies acted when scaling Agile in their organizations partially motivated us to look outside of the known frameworks and try to find something that was uniquely suited to Dynatrace.

Talk openly with people in your organization

(And figure out what works already quite well and what are the main challenges)

Communication is key in a change process and therefore we conducted a qualitative survey as a second step. We asked people in the organization how they felt about the current situation: What did they think was already quite good, what were their current challenges, and what should be improved in future. Many new things, like new roles (e.g., one dedicated Product Owner in the team) or new organizational structures were already being introduced at that time. So, it was very interesting to see how people coped with these changes and what exactly should be tackled in the future.

There were many interesting results which we considered when developing our own scaled Agile approach. I want to highlight two quotes here, which we collected during our conversations with employees.

The first statement is related to our internal roles and responsibilities:

“For employees who have been with Dynatrace for a longer time, it’s easier to do their work. In my point of view the reason for this is that people know whom to contact in a certain situation.”

The second quote relates to internal processes and collaboration:

“We should not implement complex processes as well as too formal workflows. Our development teams need to stay as autonomous as possible.”

With the help of this survey, we figured out that we needed to put special emphasis on certain elements like team autonomy, team collaboration and on clarity of roles and their responsibilities.

Find people who help to drive the change

As a third step in this initial phase of building our own scaled agile collaboration workflow, we established an internal community with people from all over the R&D, from different labs and with different roles. This community helped us to get early feedback and ideas for further development on the one hand, and on the other hand to communicate to the entire organization. People in this community committed themselves to help drive and implement the organizational change. We met regularly to talk about our experiences while implementing some elements of our scaled Agile collaboration approach in parts of the organization. We discussed best practices which we could reuse in the future and therefore should be integrated into our framework.

These elements have been merged into our ‘Scaled Agile Interface’ (SAI). The idea behind it is that this framework provides some basic guidelines and best practices but also a high level of autonomy for teams. People can choose which elements they need and how exactly to implement it. That’s why we came up with the idea of calling it an ‘Interface’.

To explain this concept, let’s look at the ‘Refinement’ meeting. The ‘interface’ of the refinement meeting expects stories as an input. The output of this meeting are refined stories which fulfill the ‘Definition of Ready’. However, how this refinement is implemented is up to the team: e.g., timeboxing or estimation technique.

What’s next?

I hope you enjoyed this introduction into our thought process when creating a scaled Agile framework for Dynatrace!

Stay tuned for part 2 and 3 of this blog series. In part 2, we’ll go into the nitty gritty of what we learned from this process and in part 3, we will explain the concept of the Scaled Agile Interface.

How Dynatrace does Scaled Agile. Part 1: Choosing the right framework was originally published in Dynatrace Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.