Overcoming the Most Common Agile Transformation Problems

We know that Transforming a large, complex organization isn’t easy. While many companies try to start with a culture or practices first, we also know those methods typically don’t work. Agile processes require a certain context to be effective, so we have to address the structure and alignment of the organization first.

The problem is that this structure doesn’t exist in most of the companies that are trying to adopt Agile at any scale—and there are some very common obstacles that show themselves on the way to creating it.

In this blog we’ll uncover some of the most common problems we see including size and complexity, dependencies, and resistance, and what to do with them so we can still create the right structure to enable Agility in the organization.

Size and Complexity

Agile Transformation is typically difficult at any scale. And just because you’re small doesn’t mean Agile Transformation magically becomes an intuitive process—or that easy to do—although some smaller companies do get lucky and skate through more easily.

But for something like a large financial organization with a set of platforms and various products that then feed multiple offerings to clients, the business is so complex by nature that Transformation often starts from a very tangled up place. How you untangle these things matters, and it doesn’t happen overnight.

We have to be pragmatic and realize the size and complexity of the organization are both going to impact our ability to be Agile and do Agile, under even the best of conditions.

Dependencies

We can’t talk about Transformation without talking about dependencies. To become Agile, we have two choices of what to do with our dependencies, we can manage them or we can break them. If we disregard them altogether, all we’ll get is local optimization—that’s it.

We can decide that, in the presence of dependencies, we’ll just deal with Transforming the one team that’s not aligned with the rest of the organization. And that team may do well on their own—but that’s it. Once they have any dependencies to be coordinated, everything falls apart.

Even in a system where every team is Agile, there are dependencies between teams, and it only takes one non-performing team to cause the other teams in the system to fail.

Technical dependencies tend to be the hardest and most expensive to deal with because everything dependency is tightly coupled. They’re difficult to break and often the organization doesn’t understand the impact of how having technical dependencies will prevent them from establishing and stabilizing velocity against a known backlog, which allows for predictability.

Resource or structure-related dependencies are difficult too. As the Theory of Constraints tells us, we can only go as fast as our slowest team’s pace. If we have one person that’s spread across multiple teams, that person is a dependency. If one team starts to need that person more than expected, the other teams slow down because they are oversubscribed.

If we have Scrum teams with non-dedicated team members, or functional silos with project teams, either of these will create dependencies between projects too, and we can’t overcome problems if a person isn’t available to solve them.

Dependencies create a lot of unintended consequences. We have to break them and figure out how we are going to slice up capabilities and realign the organization so we can manage and break them.

Resistance

Unfortunately, resistant people are one of the most widespread obstacles to the adoption of Agile ideas. Making changes can get very personal because people see the world from so many angles. Middle managers usually see a different level of complexity than the C-Suite or team-level players and often get marginalized due to their position in the middle.

Simply telling people they don’t have the right mindset is never going to work. We have to create safety for them and meet them where they are. We have to help them see the end state and how they benefit from it, as well as how we are going to iteratively and incrementally change in a way that doesn’t make their daily operations fall apart in the process. Then we can use this to lay a path to a new model where everything is clearly structured and ordered. We will need to make them feel safe enough to overcome their resistance and deal with the complexity.

Agile Transformation is hard. But the ultimate goal is to overcome these obstacles so we can create a solid, predictable operating model organizations can work within and learn to trust so they can go on to create value in the market.