The Problem with Agile Transformations…

What Management Needs to Consider About Agile Transformations

Many Agile transformations are happening in various businesses at the moment. Yes, the current pandemic has sped up the need to transform organizations to be more Agile. But even before COVID-19, I was encountering transformation stories in the news, on LinkedIn postings or blog posts. I heard many first-hand experiences in MeetUps and conferences. As an Agilist, I am happy and pleased to see all these transformations. 

Still, a part of me sees a problem with all these transformations, especially those made by large companies. The leaders who want these transformations think there is an end state to a transformation. They invariably will ask –  how long will this transformation take? When will this transformation end?

The Honest Answer

My candid answer to this question of when a transformation will end is: Never. There is no end state. And if there is – it’s because someone defined that end state, and maybe defined it prematurely. There are a couple of reasons why. 

Usually, the first and primary problem that leaders want to fix is the inability of their product teams to deliver fast, on time, or even deliver something at all. This pain point is typically the basis for starting the transformation. You send your people to take classes. You hire consultants and coaches to work with your teams to implement things like Scrum or Kanban. As the change gains momentum, you experiment with scaling tools like the Spotify model, Scrum of Scrums, or LeSS, to solve the broader coordination and focus needed to execute and deliver.

And invariably, this is where management sees the endpoint of a transformation, a myopic and short-sighted conclusion. 

Transforming Delivery Teams is the Beginning, Not the End

As your delivery teams gain Agility, they will run into problems interacting with other departments. The problems encountered at these boundaries will slow them down. I first encountered this when I was an Agile coach for Yahoo from 2005 – 2008.  Yahoo was rolling out Agile enterprise-wide. It was the first of its kind in Silicon Valley. And a first of this magnitude and size for the Agile community. That endeavor yielded a lot of excellent practices, patterns, lessons, and surprising results. 

It also showed me the painful reality that getting delivery teams Agile was only the beginning of an Agile Transformation, not the end.

One example that highlights this issue from my Yahoo experience stands out to this day – the boundary between Engineering and Finance. As engineering teams gained speed in their execution through their Agile transformation, the procurement process slowed them down. A month or two wait to get expenses approved was the average – but I ran into several instances where it took three to four months. That’s a lot of wasted market opportunity. That is a lot of time that the teams could have used working and delivering on priority items. Instead, the teams spent a good amount of effort in managing the procurement process, instead of managing their deliverables and outcomes.

I always remember this example because I’ve seen it manifest itself repeatedly in two or three other companies after my stint at Yahoo. Same problem. Same result of delivery teams slowing down. There are other examples that I can give – the boundaries with HR, Marketing, Sales, etc.

And it manifested itself, too, in coordinating with some executives. You would not believe the wait it took to schedule a meeting with one executive for approval, let alone two or more if you had to deal with more than one. 

Name the department, and I most likely have an example.

Change is Constant, Agility is Not

If you, as an executive, decide to green-light the transformation beyond your delivery teams, what then? Is there a potential end destination that you can reach? Can you consider the transformation as Done?

Unfortunately, my answer again is No. Change is constant. Agile itself is not unchanging. People are continuously experimenting and evolving with new Agile ideas, tools, frameworks, and methods.

Your company undergoes change every day. It’s a complex adaptive system. You have a constant ebb and flow of change. Ideally, teams are long-lived in Agile, but new hires come in, and veterans depart to other opportunities. Your company’s board changes. Your executive leadership changes. You go on a hiring binge when the times are good, and lay-offs when times are bad.

Your company responds to stimuli, like your customers and their changing needs and issues, the actions of your competitors, the regulations passed by the government. And yes, events like the pandemic. 

You had to change your strategy and execution from all these inputs.

All these changes create an impact, and what used to work may not work again. You always have to adjust and transform – especially when it comes to addressing your company’s Agility. Doesn’t this sound familiar? 

It sure sounds like Inspect and Adapt, one of the founding principles of Agile. It is the principal reason why there is no end to Agile transformations. You and your company have to metamorphose time and again into a better vision and version of itself. 

What Management Needs to Ask, and The Short Answer

Hopefully, by now, you understand that defining an endpoint doesn’t complete your Agile transformation. The agility issues between the boundaries of various departments in the companies are downright challenging and complex. The constant change and stimuli require you to reevaluate and adapt your solutions.

During my journey working at various places, I’ve come up with workarounds. Sometimes, I have managed to penetrate the boundary and effect agility. But it also stopped at a point. Executives and organizations are not able to stomach the challenging changes needed to move forward continually. 

I’m seeing new efforts and ideas emerge in areas like HR, where Agile expertise is building up (check out the Agile HR Community). Some boundary areas like Finance are still tough problems to solve. (FYI, see Stephen Denning’s talk at the recent Emerging from Crisis conference. He brought up Beyond Budgeting, which has been trying to convince Finance for the past 20 years.)

As an executive, you have the right to decide and define an endpoint. You can ask and seek the counsel of consultants and coaches to help determine the endpoint. You can use them to seed and bootstrap your Agility efforts. You might copy and paste Agile, but don’t expect the results to last long term. 

You are as “Agile” as your slowest department.

What Management Needs to Ask, and The Better Answer

Are you willing to go beyond what you initially thought an Agile transformation means if you genuinely want to transform your entire company? Are you disposed to let go of the notion that this transformation will end? Will you include these principles in the company Mission Statement and Values? Will you live it every day once you write it down?

Are you inclined to incorporate values of Agility in every department? Are you eager to go into areas not seen traditionally as requiring Agile, like Sales and Marketing? Are you capable of providing budget, allocating money, hiring people to help you build this continual evolution? Will you allow people to establish communities of practice within their domains and focus on helping the company see these issues of Agility and come up with solutions?

Creating a full Agile transformation goes beyond implementing things like Scrum, Kanban, or LeSS. It requires people to be vested in the mission and goal. You need people working for you to believe in it and work at it. You may start with external consultants and coaches. But in the end, you need to build this capability into your organization. 

Are you prepared as an executive team to lead by example, ask help when needed, and enable the organization to follow you into this continually evolving Agile Transformation?