A Leader’s Guide To Successful Agile Transformation: How To Go Beyond Teams

by Matthew Jacobs | October 29th, 2020 | Blog

What Agile organizations have, and traditional businesses lack, is the ability to constantly change, inspect, and adapt. Agile organizations are able to pivot to take advantage of unpredictable markets, customer demands, and real-world conditions.

In short, they have an institutional ability to make change a competitive advantage. Gone are the staid hierarchies and bureaucracy. They are replaced with an adaptive, Agile operating system that drives innovation, speed, and value delivery.  

Not just at the team level but across the entire enterprise. 

Your organization can improve just by adding Scrum Teams. They can accelerate your organization's ability to quickly deliver value. However, if you don’t change the core processes of your organization, the overall effectiveness of your Scrum Teams will be limited by legacy structures and institutional barriers. 

These are the roadblocks that cause so many Agile transformations to fail.

When going through an Agile transformation, your organization's current operating system and the new, Agile operating system will fight for dominance. They will actively work against each other. 

We have successfully helped many organizations transform into Agile enterprises. There are no shortcuts, but there are known patterns of success. Aligning the organizational operating system with Agile ways of working will greatly increase the probability that your Agile transformation will succeed. 

1. Leadership Participation vs. Buy-In

Many organizations believe they are Agile. Indeed, their product or service teams may be. But higher-up the classic organizational chart, the old operating system is still running. That is the difference between leadership participation and simple buy-in. 

The problem with leadership buy-in is it alone isn’t enough to make you Agile. If leadership is still operating in the old system, it will cause friction with the teams. They will actually make it harder for them to deliver the business objectives and outcomes that they are being held accountable for. You are empowering the old system to dominate and destroy the change your organization needs to thrive. 

One of the ways this will manifest is inefficient communication. Orders instead of vision will come down from the management team and the leaders will expect status reports coming back up.

Your management team must evolve into a leadership team capable of enabling the Agile teams themselves. This is best done when leadership itself fully embodies an Agile mindset.

To emerge as leaders they need to provide the vision, direction, and prioritization to enable the teams to execute with Agility. Leaders must also empower teams by removing obstacles to their success and productivity. 

Ideally, management will be so well educated in the Scrum framework, they can function as auxiliary coaches.

This empowers management as well as teams. By understanding how to read, interpret, and use tools like Product Backlogs and burn-down charts, management gains a greater ability to align the organization. Transparency and visibility increase. Planning becomes more reliable. 

I wish I was surprised when a management team called us earlier this year expressing frustration that their Scrum Teams had not only stopped improving, they seemed to be backsliding. When we went to talk to the teams to identify the root cause of any problems, they were surprised their management team had asked for help. 

The team then provided examples of what some of our military clients refer to as ‘hallway tasking’. Leadership would frequently drop in to demand something else be done right away. When the Product Owner tried to intervene and ask for support in prioritization, the management team refused to engage. These ‘hallway tasks’ were using up huge amounts of the team’s capacity. Progress on products that would benefit the company suffered. 

On the flip side, when simple impediments were identified by the team, they had no escalation channel. When problems were brought to the Executive Steering Committee the frequent response was “do not bring me problems, bring me solutions”. This discouraged anyone from transparently bringing problems forward, especially ones that required support beyond their remit. 

These managers may have bought into being Agile, but they were not participating or leading. As for the unresolved impediments, they too hurt the team’s productivity, creativity, and morale. 

Luckily, a newly appointed General Manager began pushing for a true servant leadership model.  

As we educated the organization about Scrum@Scale, the new General Manager saw how the framework operationalizes servant leadership. The Scrum Teams began accelerating once Scrum@Scale and servant leadership expanded. The outcomes management was looking for were quickly delivered.

As a management team, if you are asking your organization and team members to change and exhibit Agile behavior, you should expect the same from yourself.

2. Make Your Product Life Cycles Agile

Frequently companies have specified processes for Product Lifecycle Management. These get tied into the approval frameworks of the organization and feed funding, reporting, marketing, and future investment. 

Agile teams frequently have trouble getting projects through stage-gates when this legacy process is not updated. This does not mean regulatory requirements can or would be ignored. Nor does it mean other safety and quality checks would be removed. 

What this does mean is that these checks ensure they are serving the intended purpose and meet the minimum required amount of overhead to meet the safety and regulatory standards required. 

If these processes are not amended, projects that should have been killed because they aren’t meeting customer expectations tend to get more funding simply because they already meet the predetermined requirements of the product life cycle process. New products and value-enhancing pivots are jettisoned by default. 

Here, I can give you an example from a Fortune 100 manufacturing company we recently guided through an Agile transformation. Within their systems, they had built automated reports to ensure that everything was “working correctly”. 

There was a complicated process wherein teams outside the development group were responsible for managing and reporting on any system errors as they arose. But as we implemented an Agile operating model, the teams themselves had assumed direct ownership of product support. 

Before the implementation, new development went through a series of stage-gated releases with approvals moving slowly through the system. 

Well-formed Scrum Teams have members with all the skills needed to do the work, including support in this situation. This allowed the team to focus on releasing faster and build automated tests to quickly detect issues even before they were encountered by a customer. 

Yet the organization retained these separate, manual testing and reporting teams that had been part of their prior operating model. So when changes occurred the testing scripts were unable to keep up with the speed of the changes emerging from the development teams. These outdated tests began to fail. 

So, as they had done all along, the compliance department went into action. They sent out failure reports to various managers, and those managers began insisting that issues that didn’t exist on applications that had been refactored or eliminated be fixed as quickly as possible. 

The teams produced the right output for the problem and were properly deployed to support it. However, the support team spent its time resolving issues with the quality system that had no bearing on the original task at hand. If the organization had recognized the new way of working and augmented their operating system, they would have dissolved these external testing teams and placed those skills onto the Scrum Teams to better enable overall Agility.

3. Use an Agile Driven Planning / Budgeting Cycle

The finance budgeting process is sometimes referred to as the heartbeat of the modern corporation. It’s easy to see why. They define the monthly, quarterly, and yearly rhythms of an organization. They also play a major role in long-term strategic planning. 

Projects require funding to move forward and therefore Agile teams requiring budgets are beholden to this process. If budgets are only released once a year and the finance process is not Agile, the teams will struggle to shift funding to the projects and problems that are the most promising.

At some of our clients, we have noticed that Agile projects are being promoted internally and externally as large examples of success. However, when you talk to the teams, you hear that they face an uphill fight for needed resources when compared to traditional projects. 

As a result, promising projects or needed pivots are put on hold until next year's funding cycle even as low-value or failing projects continue and burn money. The overall cost to the business in these scenarios is simply staggering.

Yet this is one of the primary impediments identified by the teams we work with. 

To be Agile, and empower Agility throughout an organization, you must think like a venture capitalist:

• Utilize Rolling Forecasts - To increase the frequency of feedback loops and create a mechanism for acknowledging and planning around change
• Consider Instituting Zero-Based Budgeting Where Appropriate - Frequently, companies use last year’s budgets as a starting point to determine the next year’s budget. This often leads to a "use it or lose it" spending mentality that creates a tremendous amount of waste. Zero-Based Budgeting takes the opposite approach. Instead of starting with last year as a baseline you start at zero and increase allocations only after justifying every expenditure based on profit projections.
• Allocate Resources in Smaller Amounts More Frequently - reallocate based on performance and feedback. Stop allocation for those initiatives that are lower-performing and double down on what is working.  
• Fund People, Not Projects - most companies work in a project funding model: they decide the cost of the project, look at the expected return on investment, and then fund accordingly to hit whatever revenue or cost-savings target they want to achieve. Then they go and build a team to deliver it. In Scrum, we advocate a persistent funding model. Fund teams of people (there are various ways of doing this) and flow projects or ideally problems to solve, to them. We don't cost the project separately, we prioritize the team's effort allocation.

Remember, yearly planning is at best a guess. You need to utilize short feedback loops and know how to use the data you collect to be Agile

4. Refactor Your Procurement Process

If your teams are moving quickly and have dynamic budgets, they will frequently identify new items that they need to continue to deliver their high-value projects. If it takes six months to get the required people or equipment then the entire process slows down. 

We often see Scrum Teams move at a pace the company's legacy procurement process cannot handle. 

Many, if not most procurement processes were established to mitigate the risk of potentially overspending on a product or service. However, when you try to remove all risks you frequently create new risks through inefficiencies. If your procurement team and your vendors embrace the Agile Manifesto, both would value customer collaboration over contract negotiations. This has been shown to increases the speed of delivery. It can also reduce costly waste created through miscommunication. 

A point made during a recent conversation with a partner who works with the construction industry. His team was talking to one of their vendors who just delivered a six-figure item to a building site. The vendor went on to explain how difficult it was to get pink paint to stick to the type of metal being used. It required special chemicals and paint to be air freighted in to make it work. 

When our partner touched base with the procurement office and asked why the item needed to be pink, the procurement officer said “it just needed to be bright but I needed to choose a specific color within our system so I chose pink”. 

Procurement’s bureaucratic requirements-driven processes cost the company tens of thousands of dollars by valuing the contracting process instead of just having a truly collaborative working agreement with the vendor.    

5. Developing Agile People And Resource Practices

For Agile transformations to become real, your people enablement teams (HR in a lot of companies) play a substantial role. Why would I ever want to take the hard role of being a Scrum Master if the organization does not recognize that as a job and the responsibilities would conflict with my job description? How do we manage talent and people recognition if the Scrum Master and the Product Owner are not my direct boss? How do we manage the hierarchy of titles with job roles? 

For an Agile transformation to take hold and be sustainable the organization needs to embrace these changes and identify answers that align with their desired business outcomes. 

For example, incentives are powerful tools. Once Agile starts to take hold and your Scrum Teams are accelerating, you need to change your incentive structure to reward behaviors and patterns your organization now values.

If your recognition is solely based on individual merits, why would anyone shift their mindset and behavior to one that is team first? If team recognition is based on completing a specific project, why would they shift directions even when it becomes clear they need to pivot? 

Your organization needs to incentivize and reward teams that deliver high value. Therefore, team rewards and compensation must be aligned with the KPI’s you are using.  

An operations team in one of our partner’s accounts payable department recently implemented Scrum. Our client did not realign their incentives program. This team’s incentive structure focused on keeping their open ticket queue as small as possible. So they pursued that goal aggressively. However, by focusing on the size of the queue alone, the team was incentivized to resolve the easily processed tickets right away. Others were left waiting.  

Now, their payment time dropped significantly, the teams were accomplishing their stated objective. However, some vendors were being paid early while other strategic vendors were having their invoices queued for months before being paid. 

While this pleased certain business partners, it also took money out of accounts before it was due while frustrating partners who were not getting paid As the organization shifted its focus, the Product Owner eventually realigned his goals to focus on the higher-level business goal of on-time payments and refocused the team’s prioritization on the terms of each payment request, rather than treating each payment the same. If your incentives do not match your desired outcome and (or) the behaviors required to achieve them, the incentive structure will cause friction with the Agile transformation.

6. Organization Design

For your Agile transformation to succeed, your organization needs to be set up in a way that teams and team members get the oversight and development support they need to be effective. Tough questions need to be asked now that we are in our new model.

What should be in a shared service and what can be outsourced? What skills should be dispersed across the teams? How do we deal with deep subject matter experts? What do we do with
middle managers? How do we incorporate contractors and vendors? And many more.

If the organizational chart is not itself Agile, and communication pathways are not optimized, the organizational chart will fight back. And guess who almost always wins. 

When organizations don’t put this thought into their structure beforehand, they can end up in a situation where personnel with similar skillsets are under-utilized in one group and over-utilized in another.

Take for example a company we worked within the finance industry that underwent a large top-down reorganization. They created their Scrum Teams to work only on expected projects and workloads instead of forging truly cross-functional teams.

Then COVID-19 suddenly changed everything.

They quickly realized those teams weren’t built with enough flexibility to easily accommodate the new reality and had to re-launch new teams that were cross-functional and could adapt to the changes.

The moral of the story is to build your teams so that the work can flow to them. You don’t want to have to keep establishing new teams to accommodate the work, or you might lose all the benefits of the close working relationships and practical experience the team has developed. 

 Then, there is the question of scaling. One of the mantras for Scrum@Scale is you do not scale unless you need to. Unneeded layers slow down an organization. 

But when you do need to scale, make sure you do so in a unified way. Don’t add complexity by introducing what amounts to another operating system that kicks off another round of zero-sum conflict. 

This is one reason the Scrum@Scale framework so closely aligns with the Scrum framework. 

7. Create the Right Agile Workspace 

Where you work can define the work you do. The right work environments and tools will increase productivity, collaboration, and creativity. They empower the team to work seamlessly together.

This is as true with virtual teams as it is for those that are co-located. 

The wrong work environment creates constant distractions and impedes the team's value delivery. There are many ways this happens. If a subject matter expert is so important they cannot sit with, or virtually communicate with the team as needed how valuable are they? Are the office walls so full of artwork we cannot make our work visible? If your team is dispersed, are they armed with the right virtual tools to collaborate in real-time over a long distance? Are there unneeded process steps that slow everything down?

I was just talking to a team that was using a tool that allowed multiple people to work on slides simultaneously. Their CEO was amazed at how much faster they worked. When the free trial ended, the CEO pulled the product due to cost concerns. 

How valuable is speed and enabling your employees to work together? Organizations need to remember their purpose is to create value and support that value creation process. 

Embrace The Journey

Addressing these issues will greatly increase the probability your Agile transformation will succeed. This is how dynamic operating systems that drive innovation and value delivery are created. But always remember, creation is only the beginning of your Agile journey. The major friction points of today will not be the friction points of a year from now. 

Agile transformation is not an end state. There is no clearly defined finish line.  

You will need to regularly inspect and adapt your organization. Agile helps you do just that.