Transformation & Change108

Tackling Organization Design During Our Agile Transformation

Tackling Organization Design During Our Agile Transformation with Alex Basa

Alex Basa

July 18, 2018

OverviewRelatedHighlight

Alex shares his current approach to tackling organization design in a healthcare company.

  • What approach to structural agility has he tried in the past? What did he learn from it?
  • How different is his approach today? What would be the benefit of new organizational structures?
  • What would a workshop look like for it? Who would attend it?
  • What were the lessons learned by this approach?

In addition to those areas, he will talk about some anti-patterns that he has seen in approaching the creation of a Product Management organization as well as some of the things that would need to be in place before facilitating a workshop like this.

Live drawing of Alex's talk

About The Presenter

Photo of Alex Basa

About Alex Basa

Lead IT Agile Coach @Centene Corporation

Alex Basa is a Lead IT Agile Coach at Centene Corporation, working on his third agile transformation.

Follow them on LinkedIn:
https://www.linkedin.com/in/alexbasa/

Presentation Slides

Video Transcript

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.

Download Materials

Share

Are You Ready to Uncover Your Agility?

The Business Agility Profile™ is a detailed, research-based snapshot of your organization’s Business Agility capabilities & behaviors.

Based on years of research and trusted insight, it delivers data-driven analysis highlighting what’s pushing your organization forward — and what’s pulling you back.

  • Understand where your organization is on its Business Agility journey today

  • See how your organization compares to a benchmark of 1300+ other companies

  • Know the most important next steps to further develop and grow

The component MostRecentArticles has not been created yet.
The component LibraryHighlightsSmall has not been created yet.

You have NaN out of 5 free articles to read

Please subscribe and become a member to access the entire Business Agility Library without restriction.