All right, can everybody see my screen? Okay, perfect. I'll go ahead and introduce myself. I'm Alex Vasa, an Agile coach. I've been in the space for over 15 years. I got my start as a developer, moving through XP teams and the Scrum Master route. I'm currently working on my third transformation, and each one has been very different. Right now, I'm leading a SAFe (Scaled Agile Framework) transformation—version 4.5. Prior to that, I worked on a Spotify transformation, which was quite different. I'll touch on some of the structural agility concepts I was exposed to in that transformation.
I'll start by discussing the Spotify model and what happened during that transformation. Like most transformations, we began with the teams. We started forming Agile teams—dedicated, cross-functional teams—and then built out our practice. We created an Agile Center (or Agile Office), started growing our coaching capabilities, and developed mentoring programs for both coaches and product owners. These programs helped us build out the Agile practice and reinforce the necessary skills.
We also experimented with team alignment and formation. One of the key experiments was whether teams could choose their own Scrum Master and whether Scrum Masters could choose their teams. Initially, we faced resistance, but we had teams identify their biggest coaching needs and match themselves with coaches who had the right strengths. They conducted interviews and ranked their top three choices, though no one wanted to be picked last, which was a challenge. In the end, we achieved strong matchups.
We then extended this experiment further, asking: "What if teams could choose their own development manager?" This faced more hurdles. While we had some success in certain areas, the organization was resistant, and it ultimately didn't gain traction.
On the product management side, we transitioned from a large IT software development function to a product development and management structure. We took a "big bang" approach, forming a product management group aligned by platform. While there were benefits to structuring everything at once, challenges arose—especially in securing business buy-in and aligning more closely with business and customer needs.
Now, I'll shift to discussing a workshop I'm currently leading at my company. We are about a year into our transformation, following the SAFe framework. We've set up product owners and various HR-related roles, which took time. Unlike my previous transformation, we didn't immediately establish a full product management structure. In hindsight, I would recommend against a "big bang" approach—it's often easier to start small with experiments. Organizations don’t always realize how many structural layers they need, and creating unnecessary layers can lead to waste.
We knew we needed product owners and possibly product managers. Beyond that, the SAFe model suggests roles like Solution Owner, but we weren’t sure if we needed them. So, we started small. This workshop was designed to give business and corporate leadership insight into the emerging structure and its benefits.
Currently, we have development teams and dedicated teams that are generally small and cross-functional. We've introduced product owners, built up the product ownership skill set, and improved work prioritization. However, one of the biggest struggles in any transformation is role clarity. When you introduce new roles, what happens to existing ones? Business owners, business analysts, and other traditional roles may overlap with the new structure.
In one transformation, we had three or four different roles that essentially performed the same function. Without buy-in across the enterprise, older roles don’t disappear, leading to unnecessary complexity and cost. That’s when organizations begin saying, "IT is too expensive." To avoid that, it's best to simplify, run experiments, and ensure that changes actually add value.
When introducing product owners, we initially placed them within existing business units to help with ownership and introduce the concept gradually. However, this raised another challenge: while prioritizing work within a team is manageable, how do you prioritize across an entire enterprise? That’s where enterprise-level prioritization, portfolio management, and alignment between product owners and business leaders become critical.
Many traditional companies don’t have a clear product strategy because they’re not product-focused. So, introducing a product management structure means asking fundamental questions: Where is the product going? What is its market need? What differentiates it? At some point, the organization has to determine whether it’s time to formalize a product management structure and, if so, what it should look like.
Workshop Overview
This workshop involved senior leadership, including the CSO. Not all of them were familiar with IT terminology or Agile concepts, so we had to find a way to explain agility in business terms. More importantly, we needed to address the leadership perspective—what’s in it for them?
Through multiple transformations, I’ve noticed common organizational struggles, including:
- Should we build or buy a solution to achieve an outcome?
- If we build, should it be a new product or an addition to an existing one?
- How do we measure product success?
- How do we ensure we consider the bigger picture rather than just localized solutions?
These questions consistently arise, and a structured product management approach can help address them.
Lessons Learned
- Business and development roles will change, and buy-in is needed at all levels.
- Before creating a structure, define the outcome you want to achieve and measure against it.
- Gather feedback throughout the process and run small experiments instead of making sweeping changes.
- Avoid creating unnecessary layers—build only what you need based on real value.
In the end, transformation isn’t just about implementing Agile; it’s about ensuring the organization evolves in a way that maximizes value while minimizing waste.