Agile transformation towards product domains

Agile is all about self-managing, cross-functional teams. Ever since we started our transformation into an agile organization many moons ago, we have been committed to continuous improvement not only within the teams we created but across the larger company structure. For that exact reason, our software development department (now known as “Platform”) has transformed from a group of teams with expertise in specific processes to a group of domains that focus on products.

“As a developer, I’m now creating valuable software for an end user instead of for the next team in the waterfall chain.”

Want to see what (part of) an agile transformation looks like? Read on!

Previous structure

In the previous structure, the Platform tribe (a team of about 100 people focusing on the core software package) was divided into 3 product lines. One of those focused on everything going on at the back end (“fabric”), one on the front end (“client”), and the third product line focused on the cloud and on Service & Resource Management (“bridge”). Each of these product lines consisted of several squads, led by a product line manager. The tribe had 2 tribe leaders at its head, who the product line managers reported to.

“Product” lines

While the 3 sections were called product lines, they actually focused on the running processes rather than on a product. In many use cases, changes will be needed in both the back end and front end.

Let’s say we want to identify and visualize relations between parameters in DataMiner elements. Even if we don’t leverage cloud functionality, we clearly need something in the back end to find and communicate those relations to the front end. That front end then needs to visualize those relations somehow, so that the end user can benefit from the detected relations. While the teams themselves can work agile, the company is still using a waterfall approach. Specifically, the client team has to wait for the fabric team to finish their implementation before they can get started.

Moreover, the team in both product lines did the work following the vision of their product line manager, who in turn had to align their vision with the other PLMs and the management level above that.

Downsides

We realized that the structure we had in place had its downsides, such as a lack of satisfaction from delivering directly to the end user, not being able to have a vision as a team, no close feedback loop on end-to-end functionality, and a waterfall approach. While the expertise of specific parts being in the same team and allowing for closer feedback loops in reviewing structures were however definite upsides to the structure, they did not outweigh the disadvantages.

Finally, each squad in this structure had a part-time agile coach and a part-time product owner. Those people had to balance their work between their role as AC or PO and developing, which led to conflicts of interest within the team, as well as even more context switching.

Desired improvements

As you can tell from the previous part, there were a couple of things we were looking to achieve:

• Less hierarchy, more self-managing: The team that does the work gets more ownership of user stories and has a clear vision and product understanding.
• Making it easier to create goal-oriented increments and letting the team decide when and how to release them.
• Orienting around products to enable autonomy: Allowing for separate releases and lower T2R (time to release) for different products. This also allows for integration testing within the same team and for fewer dependencies.

New structure

This led the Platform tribe to the creation of 7 new domains, each with its own vision and set of products:

• Automation & Orchestration – We make the data DevOps tool because a user wants efficient and consistent execution of the business flows.
• Cloud Ecosystem – We enable products to use the cloud because a cloud infrastructure allows for new possibilities.
• Core Ecosystem – We keep the engines running, because a user wants to use DataMiner with the least amount of worries.
• Data Acquisition – We create the indispensable foundation for any data-driven operation.
• Data Exploration – We provide access to the data, because a user should be able to consume data exactly as they need.
• Data Insights – We add value to your data. Because a user cannot give attention to everything, rules and AI give them a hand.
• Lab – We are at your service as your first friendly user because the next user expects us to have their back.

This new structure was created initially by tribe leadership, but couldn’t exist without the 3 product line managers being willing to take a step back from their management role and become part of the domains instead. It takes a person who truly keeps the company’s interests at heart to do this, so kudos to them! Now, everyone in the tribe answers to tribe leadership—a whole layer of middle management removed.

The previously part-time agile coaches and product owners per squad have now been replaced by full-time equivalents per domain. The teams are now trusted to self-manage as much as possible and decide on a way to determine what’s most valuable and how to approach it!

Finally, with the new structure, a lot of people also moved over to the Platform tribe. The tribe wants to be truly end-to-end and apply a DevOps approach. That means a lot of people that were previously doing technical support for different customers came over to one of the domains. This way, the feedback loop between the software team and the end user becomes even shorter, allowing for more involvement on all ends.

Of course, all of this evolved over a short period of time, starting as an idea all the way to the above-mentioned domains. Read on to see how we got there.

Go-time!

With the initial idea noted down, it was time to get things moving with the necessary input from everyone involved. That meant collaborating with around one hundred people and working towards a consensus on defining the members, roles, and accountabilities of each domain and its people.

Purpose, hopes & fears

So how did we go about this? We decided not to include anyone external. Instead, our tribe leadership took the helm, along with our global agile lead. And what did they do? Ask the team, of course! We wanted to know everyone’s fears, hopes, and other thoughts about this transition and discuss them. But how do you hold a meeting with around 100 people? “Lean coffee” came as a great answer to this question.

Defining the product domains

With the purpose, hopes, and fears discussed, everyone had a clearer idea of where we wanted to go. With that in hand, it was time to define the different product domains. What is their product? If they were a standalone company, what would they be selling?

Everyone had a week to add products and their different aspects to a mural board. Over the course of that week, people added comments on things that still needed to be discussed. At the end of the week, another meeting was scheduled to discuss the remaining parts.

People make the teams

Now that everything had been divided into different product domains, a quick check-up was in order to see if everything was clear.

Then, the next step was for everyone to mark their preference for one or multiple product domains. Tribe Leadership evaluated those preferences and divided up the people with respect to what would deliver the most value to the company. In addition, candidates were selected for the roles of Product Owners, Agile Coaches, and Quality Coaches to determine the roles within the different domains.

DO IT

Ultimately, it’s just a matter of doing it. Key is to inspect and adapt constantly and ensure great collaboration between teams, POs, ACs, and management.

So once everything was in place, the domains kicked off and we have honestly never looked back since.

Where are we now?

One year later, we see the major benefits of this change. Teams indeed feel like they have more autonomy to decide what they work on and organize themselves to prevent the waterfall approach between teams. This has led to them delivering the right thing faster and of a higher quality. The teams now manage themselves to avoid growing technical debt and ensure continuous delivery.

We continue to put in the work to improve our company structure to maximize the delivered value. Just because people are generally happy with the current situation, doesn’t mean it can’t get even better. The POs and ACs formed close cross-domain teams, which causes the barriers to disappear and allows for even better collaboration.

The technical support engineers were mentioned as part of the transition, but actually only came on board a couple of months after the domains kicked off. This was our first major improvement after the large transformation.

At this very moment, the lab domain is transforming into a domain called Infrastructure & Operations. This means the central operations team, which is your first line of support, will collaborate with others to optimize your installations, updates, and availability, both on-prem and in the cloud.

What do you think of this transformation and how it was done? Going through an agile transformation yourself? Let us know in the comments!

You might also like