Three Simple Ways to Ease Your Agile Journey
Photo by TheDigitalArtist on Pixabay

Something has been bothering me. For the past several years, I have watched our pursuit of Agile lose its way due to the magnitude of the change.

Sometimes this is due to scaling change too fast. Traditional organizational behaviors and design block the change from taking hold. And attempts to standardize backfire. If nothing else, complexity increases due to the sheer scale of the enterprise.

At times, I tell myself I should embrace this as the new normal and deal with it.

But the other day, I heard something that solidified where we go wrong. And it sparked an idea of how we can change to a better course to follow. A colleague said,

“Without applying Agile to Finance and Budgeting, Marketing, Human Resources, and countless other departments, your Agile journey will only go so far. You must first make the entire organization Agile.”

I was not surprised as Business Agility is all the rage. As the argument goes, to make the leap to Agile, the entire organization must move to an Agile mindset. Or we risk being myopic if we isolate Agile to technology teams.

But spreading Agile thinking throughout an organization translates to massive change. And the organization does not have to be too large or be too old to come face-to-face with this reality. Take a 200 person, ten-year-old company. I have seen a small company such as this face similar hurdles as a 10,000 person, decades-old company. And changing the culture can take years.

Business Agility is important for any Agile Journey. But how we solve for this is critical. I’ll get to a better way to approach it. But first, let’s discuss some of the pitfalls of our current methods.


Where We Go Wrong

The complexity we are experiencing has a lot to do with the way we are approaching the transition to Agile. While we have good intentions, our approach often mimics the behavior we are trying to change.

“Does experience help? NO! Not if we are doing the wrong things.”

—W. Edwards Deming

We attempt to change too much at once. Then, to ease the change, we try to create a cookie-cutter approach. In our desire to see results fast, we force the change on our teams.

Let me explain.

Big-bang Change

To embrace Business Agility, organizational structures must flatten and support cross-functional teaming models. Performance, compensation, and reporting structures must change. We must alter our vendor relationships and contracting mechanisms. Budgeting and forecasting must morph to support learning-driven product development. And the list goes on.

We sometimes fall prey to planning and design paralysis. We try to design the perfect organization on paper before we attempt to change the way we work. Only then do we aim to roll out the change to all teams and departments.

Responding to Change Over Following a Plan

—The Fourth Value of the Agile Manifesto.

The cultural adjustment to Business Agility can take many years. And the cost of delay is enormous. With a big-bang approach, we gain no value along the way as we move toward our goal of Business Agility.

Standardization

In the enterprise, we face changing many teams across many departments. In our efforts to reduce disruption, we turn to a standardized approach.

We form centralized change teams. These teams think, design, and plan the new process all will follow. They form communication and training materials on the new approach. And they roll it out en mass across the organization.

This approach is linear. And iterative experiments are not performed to customize to different contexts. Prediction takes the focus rather than empirical learning.

After rollout, the central team assesses alignment to the new standard. And it ranks teams and identifies teams that need help.

The change team does all this from its central perch. As a result, it is disconnected from the reality on the ground where the work happens. And its standards are too homogenized to address context-specific team needs.

Too Much Push

With a large change initiative, waiting years for new behaviors produces impatience. In an attempt to accelerate the change, we push the change out across teams and departments.

The teams are not consulted on the change. They often do not understand why they are changing. And many times, they have no desire to change. Without a purpose and desire, strong resistance will slow or halt the change.

Changing too much too fast results in significant chaos and change fatigue. Teams have had no input into co-creation of their change journey. The organization ignores their perspective. And as a result, the change does not stick and has a high chance of failure.


The Simple Idea: Use Agile to Become Agile

As I examined where we go wrong today in adopting Agile, two questions emerged, which I had not considered.

  1. Why do we use traditional behavior patterns to roll out a change initiative?
  2. Can we instead use an Agile approach to change our behavior?

“I am at war with the obvious”

—William Eggleston

These are valid, if not obvious, questions. If Agile is good enough for delivering products, then it is good enough for changing behavior.

We need an Agile approach to move towards Business Agility. Three simple, guiding behaviors support an Agile-oriented approach to change.

№1–Engage Your Teams

We should engage our teams in the change. Like we want engaged teams delivering our product, we want the same in attaining an Agile mindset. Plus, teams are the closest to the work. They will know best what needs to change to reach a new mindset.

And you will also get their buy-in.

“Always treat your employees exactly as you want them to treat your best customers.”

—Stephen R. Covey

To foster engagement, the teams should first understand the ”why“ behind the change. This will form their purpose.

Then, teams should have the autonomy to identify where they need to change to meet that purpose. And they should have the control to pull the appropriate change into focus. By pulling the change when they are ready, they will ensure the pace of change is sustainable.

Finally, they should co-create and customize the change to their context. This will allow them to address obstacles unique to their journey. In turn, they will master the techniques required for their specific change needs.

Teams engaged in this way will ensure the change flourishes rather than dissipates.

№2–Keep it Small

We desire broad, rapid change to arrive at a state of Business Agility.

A big-bang approach does not deliver. Large batches and high work-in-progress slows down product delivery. It does the same for changing behavior. 

Instead, we need a small, incremental, focused approach to change. This approach is faster and more successful in the end.

One way to do this is to start with one product and one team. This allows you to highlight organizational obstacles and remove them for that team. The first team paves a path for future teams. New teams will stand on the shoulders of teams that came before them. As new teams forge their unique path, they will discover new obstacles and remove them.

“Great things are done by a series of small things brought together.”

—Vincent Van Gogh

An incremental approach will build up over time to exponential change for the teams. And these changes compound to alter organizational behavior and structures over time. 

An incremental, cumulative approach changes your organization faster than a big-bang approach. And you will realize value as you change versus waiting years for tangible outcomes. 

When you change incrementally, it is harder to see your progress. So you may have to periodically step back and assess your overall impact.

№3–Be Experimental

A standard approach for each team will lead to change that does not stick. Each team is unique. As such, what works for one team will not work for another. You can’t plan out how to solve a complex, uncertain problem such as this. Each team has to experiment to find its right path.

“It’s easier to act your way into a new way of thinking than think your way into a new way of acting.”

—Jerry Sternin

This experimentation includes choosing the correct Agile framework. For instance, some teams might use Scrum while others choose to use Kanban. And a plethora of good practices exists to supplement the frameworks. Give teams the leeway to experiment and customize practices for their context.

Experiments happen daily to reach a change goal. When a team experiments daily to test out a new behavior, it will encounter obstacles. The team will need to remove these or seek help in removing them.

And you and the teams can’t plan for the obstacles. Each team will have its own challenges that can’t be predicted. Experiencing the direct pain of these provides the impetus to solve them. Best of all, you and the teams spend effort solving roadblocks only when relevant and necessary.

All this results in each team having a different way of working. When each team acts in a different manner, you might think something is wrong. Our minds like consistency.

But we should expect and desire differences in technique. When each team has its own methods and all methods support the Agile Mindset, things are going right.


So, What’s the Point?

The sheer size of an Agile change journey can make us fall back on old behaviors to roll out the change. This is not the best approach. It can lead to a big-batch, standardized approach pushed on teams and the organization. And this can elongate the change process or prevent it from taking hold.

A better approach is to use the Agile Mindset to guide your transition to Business Agility. This way you will engage your teams, realize incremental improvements, and customize to each team’s context. As a result, you will experience value early and your change will be fit for purpose.

Best of all, your change will last. And you get to practice the behavior you desire by applying the same behavior to your change.

Also published in Serious Scrum on Medium.


Source link

Leave a Reply

Your email address will not be published. Required fields are marked *