How Dynatrace does Scaled Agile. Part 2: Lessons learned from implementing a new framework

What you need to be aware of when transitioning between Agile frameworks.

Written by Hermann Lacheiner and Andrea Holl.

In part 1 of this series on how Dynatrace does Scaled Agile, we wrote about how our company grew to a certain point where we needed to define a framework to improve the way we worked, communicated, and be more efficient. After analyzing existing frameworks, we decided to create our own, which became the Scaled Agile Interface (SAI).

In this blog post, we will look into which elements were an important part of this transition into the new Agile interface and what key lessons we learned during this ongoing implementation period.

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

The key ingredients to a successful Agile transition

A key aspect of introducing the Scaled Agile Interface (SAI) was to respect and value already existing elements at Dynatrace. There were already some great established practices, roles, and ceremonies that worked, even though they sometimes had different names or were lived slightly differently, e.g., depending on the lab or organizational area. Step by step, we brought everyone on the same page. Having a similar understanding of the key elements made the collaboration across labs and across different organizational areas much easier and more efficient.

An evolutionary adaption of Scaled Agile Interface elements was an important principle of bringing the Scaled Agile Interface to life. We didn’t want to put too much stress on the organization with a revolutionary approach and overthrow good practices that Dynatracers were already used to. It also was crucial to continuously inspect and adapt and collect feedback during the development and rollout of the Scaled Agile Interface.

Having a big picture, or a vision, was essential to be accepted by the organization. To be honest, this was a tricky part. On the one hand, it’s important to have documentation as a reference, a guidance for people. On the other hand, it’s also very important to present and show the organization why the transformation is needed, what the vision is, and how we plan to get there.

Of course, the elements of the Scaled Agile Interface, e.g., the events, roles, artifacts, are never going to be final. There will always be the need for some modifications and adaptions because of context changes or organizational growth. And we continuously learn throughout the rollout of the Scaled Agile Interface. One of the success factors was to identify the right stakeholders and consult them before implementing changes.

Introducing and rolling out these new elements of the Scaled Agile Interface is quite challenging. A key component in this change process was the tight collaboration of the Agile Program Managers and the Agile Coaches, which made it possible to implement the elements of the Scaled Agile Interface within different areas of the organization (development teams, product management, leadership team …) at the same time. This enabled us to accompany several roles, detect challenges in organizational interdependencies, and adapt when needed.

What we learned in the process

Introducing new things is always a challenge and cannot be planned in detail. It is a complex initiative that needs an iterative approach, short feedback cycles to learn and improve. Having said that, it is clear that not everything went smoothly during the transformation, so, we have several learnings that we want to share with you:

We struggled with “marketing and announcing” the Scale Agile Interface. Initially, it was sometimes not clear for people in the organization what this Scaled Agile Interface is about and why we need it. This issue has already improved a lot; we had several sessions and presentations to share the idea of SAI with the organization. But of course, many questions came up, for example, why we do not use SAFe or LeSS.

We invested a lot of effort into documenting the Scaled Agile Interface, but sharing knowledge and information lagged behind. Don’t get me wrong, good documentation is essential and highly appreciated and needed by people, but somehow documentation must find a way into the people’s mindset. Just by reading something, people do not typically change their behavior. With the help of workshops and training, we inputted the documentation step by step into people’s minds. I.e., by making them aware of which challenges we are addressing with the Scaled Agile Interface. To summarize, providing good documentation in combination with workshops and training is key.

And finally, a fun fact, visualizing a framework in an understandable and straightforward way is hard work. Small mistakes can let it be easily misinterpreted.

For example, drawing straight lines with arrows all pointing in one direction is not a great idea, simply because it gives the impression of a “waterfall” workflow. We recommend using circles instead of straight lines.

Another example is depicting areas that are unrelated. It’s easy to run into the “silos” mentality. Try not to separate areas (e.g., product management vs teams) with strong dark lines, better interweave them.

Here is a gallery of the different versions of our Scaled Agile Interface we had so far (more to come 😀):

What’s next?

We are quite at the beginning of our transformation journey. Obviously, there is a lot more on our plates and we are extremely excited about the upcoming weeks and months. Nothing is written in stone as this is an iterative process. However, there are already a few things we want to perform as the next steps:

Communication and Introduction

A crucial part is communicating it to the entire R&D. Everyone should be aware of the benefits of the Scaled Agile Interface and how to implement it. As mentioned before, this is a mindset shift and providing just some loose documentation is way too little to move forward. That’s why we plan to facilitate some kind of ‘roadshows’ for the Scaled Agile Interface.

The first step was to announce it in one of our internal “Dev2Dev” meetings where developers present interesting topics for other developers. Now, we are also producing an introductory video. This short and simple clip shows the most essential elements of the Scaled Agile Interface and provides an overview of the basics. But this is just the beginning, there is more to come.

Training and Workshops

Besides introducing the Scaled Agile Interface to the R&D, we also needed to make sure that people understand how to live it. For this reason, we designed several workshops for different purposes. Below, we want to present two of them as examples.

The aim of the first workshop was to get clarity of all roles and responsibilities in one team. We set up a new remote workshop format like speed dating, where people from one team can talk to each other to clarify expectations and responsibilities. Besides the benefit that this is also kind of a team-building event, people understand much better whom to contact in a certain situation, what their responsibilities are, and what they can expect from each other. Obviously, there are follow-up steps needed to fill gaps and missing roles.

The second workshop is called “Agile@Dynatrace”. In this remote workshop, we use gamification elements to introduce the Scaled Agile Interface to the participants. In fact, the Scaled Agile Interface is the game board, and two to three teams need to tackle real-life challenges from the everyday working life at Dynatrace by using the elements of the Scaled Agile Interface.

Communities

Training and workshops are a perfect way to ensure that people get to know the framework in more detail and to enable them to use it in their work routines. But participants are limited as well as the number of Agile Coaches who run these training. Therefore, communities are a perfect way to, on the one hand, focus the attention from Agile Coaches on many people at the same time, and on the other hand, to focus on specific topics of interest for a specific audience. We have now several communities for specific roles (e.g., Product Owner, Team Captains, Agile Advocates) and locations up and running. People come up with ideas on what they want to discuss and have the possibility to share experiences and learn from each other. As a positive side effect, teams get aligned and get to know each other better.

Agile Coaches & Agile Program Managers

To ensure that the organization, teams, and people find their best possible way to use the Scaled Agile Interface, we have decided to add the role of Agile Coaches to Dynatrace. They are team-independent but support individual teams if needed, but their scope is wider for the company as a whole.

Together with Agile Program Managers, they drive and accompany the change process. The effort for designing such a framework, for setting everything up, for introducing it in the organization as well as designing/facilitating workshops and training is significant. Therefore, you need people who have the capabilities and the time to do that.

Conclusion

Implementing a new Scaled Agile framework is a huge journey that needs the attention of the entire organization and we are lucky to have multiple roles and people supporting us throughout.

Now that we have discussed why we created the SAI and what we learned from implementing it, it’s time to go deeper and explain what the SAI is all about. So, make sure to tune in again for the 3rd installment of this series where we present the Scaled Agile Interface in its current form.

How Dynatrace does Scaled Agile. Part 2: Lessons learned from implementing a new framework was originally published in Dynatrace Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.