Agile Adaptation

The necessity of adaptation.

The world is not static. And change isn’t optional.

What happens when teams or organizations don’t adapt? It’s easy to point to the big ones, looking at you Blockbuster, but the same thing happens on a smaller scale each day in almost every organization.

To thrive, we need to see change as normal, not scary. Keeping things the same really is a phantom.

I stopped seeing mistakes as failures and as discoveries about the world.

A personal experience that drove this home for me was when we moved as a family ten years ago. It was a hard decision to make as we had built great relationships in the community. But we knew it was still the right change to make.

Within two years, most of our close friends also moved for various reasons, and it hit me. If we hadn’t changed, life wouldn’t have stayed the same.

As you increase the frequency of adaptation, be aware of the tendency to glorify change to the point that you end up with instability or change for change's sake.

How does Scrum support teams to adapt?

Regular change on its own can be disruptive and confusing. Scrum’s not-so-secret ingredient is that it first normalizes transparency and inspection. Adaption is then just the natural next step.

Transparency creates shared consciousness, a great concept from the book Team of Teams, and contextual awareness that allow teams to make informed decisions.

Learning is always part of the process. And the process takes time.

Continual inspection keeps teams from making changes based too heavily on a singular data point. Instead, the adaptation is based on a nuanced understanding of many influencing factors.

But Scrum’s biggest advantage in adaptation is self-organizing teams.

It’s their decision.

The change isn’t being pressed down on them by leadership. It’s not disconnected from the reality of everyday work. Nor is it disconnected from the overarching goals and objectives of the organization.

The impact of agency and empowerment combined with clear direction is hard to overstate.

Now, with this backdrop, let’s look at each Scrum event through the lens of adaptation.

• Sprint planning. The team may have had an idea of how to do the PBIs when they last saw them during backlog refinement. But now, when they have the context of the sprint goal and other work to be done, they may decide to adapt their approach.
• Daily scrum. Every day the team is essentially adapting to replan the rest of the sprint based on what they discovered the day before.
• Backlog refinement. As the team works to clarify the items in the backlog, the product owner will likely make changes to the prioritized order of the backlog.
• Sprint review. After receiving feedback from stakeholders, the product owner will adapt what is prioritized for the new sprint.
• Retrospective. The team identifies changes they will make to work more efficiently together.

Going through that list, it’s hard to miss how closely adaptation ties to the other two pillars in Scrum of transparency and inspection.

What to do when an adaptation doesn’t work?

Learning is always part of the process.

And the process takes time.

Learn from the kids

As adults, my wife and I moved around the world to work in a new language and culture. We were adapting in every facet of life, facets I didn’t even know were a thing. An unexpected blessing was having young children during that same season.

As we were learning to live in a new way, they were just learning to live in general. Not long after taking their first step, they would fall. When learning to speak, they would use grammar in a hilariously strange way.

Take the 1% improvements but be open the to possibility of 100% changes.

When we watched this in their lives, we knew it was normal and celebrated the journey. But then in my own life, I would be frustrated by not knowing how to do or say something. One day the light bulb when off that I was on the same journey my kids were.

Mistakes were part of my learning journey. I stopped seeing them as failures and as discoveries about the world. I needed the same grace I was extending to my kids. Your team will need this also as you embark on change.

Live with a growth mindset.

As I look back on those years, I realize they were instrumental in cultivating the empathy and curiosity that later led me to the worlds of UX and agile development.

Without those “failures,” I wouldn’t have grown into who I am today.

So whether it’s your own personal project or your team has made a change that didn’t work out, seize the opportunity to learn from it.

To thrive, we need to see change as normal, not scary.

Not only does inspection inspire adaptation, but it also acts as its safety net. During the next standup or the retro, evaluate what didn’t work and adapt again.

Perfection is not the standard. If you’re not failing much, you’re probably holding yourself and the team back by playing it too safe.

3 Strategies for guiding your team through change.

We each have varied tolerances for change, and the team will likely include members who see it differently.

These differences can create some challenges to leading a team through continuous change. Let’s explore three strategies to help you lead your team amidst change.

1. Avoid the sunk cost fallacy.
2. Maintaining current clarity.
3. Engage the whole person.

Avoid the sunk cost fallacy.

Have you ever known you need to make a change, but you felt the weight of how much work you’ve already put in holding you back?

It can be challenging to navigate change when you’ve already invested much in the current plan. But if you don’t do anything and keep moving in the same direction, it will only get worse.

Let’s explore the sunk cost fallacy and see how to understand our emotions' impact in this situation.

The workday is over, and you’re swiping through Netflix to find something to watch. You pick a movie you haven’t seen and start watching. It’s terrible. The acting, the plot and the cinematography all leave much to be desired. But you keep watching because you’ve already invested over an hour, and there are only 35 minutes left. This is the sunk cost fallacy.

It's hard to let go when we’ve invested a lot of work, money, or time into something. Even when our mind knows we should cut our losses and move on, our emotions keep us from moving forward.

We like to think of ourselves as intellectual agents making rational decisions, but research has shown that we’re not that different from mice or rats regarding the sunk cost fallacy.

Scrum's short cycles are a powerful defense against the sunk cost fallacy because it limits how much time you invest before discovering a change is needed.

But if you still find yourself in the face of needed change feeling paralyzed by the time and work already invests, here’s another strategy for you.

Name the past and move to the future.

While you can and should learn from the past, you cannot change it. The effort, time, or money you’ve invested is already spent, and taking ownership of this reality is crucial to moving forward.

Sometimes it’s simply saying aloud to the team, “When we started the project, we looked at factors X and Y and decided to do Z, but now things have changed, and Z is not the right strategy for reaching our goal.”

The world is not static. And change isn’t optional.

So often, bringing the truth out into the light disarms all the lies we’re tempted to believe. All of the “you should’ve…” and “if only…” statements shame us into submission and keep us stuck on the same path.

But when you take ownership of the decisions and the outcomes and call them what they are, you can set them down and turn your attention to what’s ahead.

Maintaining current clarity.

If a larger change occurs, like a merger or reorganization, your team will need extra help navigating the added uncertainty.

You don’t know the future, but you can be clear about what you do know.

During seasons like this, you may add 5 minutes to the standup and address the following points.

• This is what we know today.
• This is how it affects our team.
• This is what we’re going to do.

This real-time clarity will provide a level of safety for the team to still do courageous and creative work.

Engage the whole person.

But what if you know the new direction but need help facilitating the change?

Change can be tricky, and it's not always clear how to implement it. The book Switch is an excellent resource for understanding how to bring about change, and it uses a metaphor of a man riding an elephant to illustrate three areas to cultivate change.

• Directing the Rider. The rider represents the rational, logical mind of people. Appealing to the rider is usually the default approach but will have a limited effect on its own.
• Motivate the Elephant. The elephant represents our emotions; if not properly engaged, it will steamroll our rational plans every time.
• Shape the Path. How can you change the environment in which the change is being made? Can you make the new behavior extraordinarily easy and the old one difficult or impossible?

I find this framework informative when the team considers changes based on our evaluation during the retrospective.

Change is inevitable, and leading through it can be hard, but you’re not alone.

Even as we covered the pillars one at a time, you can see how they naturally integrate and work together.

• Transparency to make things more visible.
• Inspection to create space for evaluation.
• Adaptation to encourage growth.

They act in concert with each other, and you will often find yourself moving fluidly from one to another.

You can think of Scrum as a three-leg stool, with each pillar being a leg. If you remove any of the legs, the stool no longer functions. In fact, it’s likely to hurt someone. Scrum is similar. If you try to practice it without one of the pillars, you will do more harm than good.