Agile Has Always Been About Change: Agile 2024 Day 3

In the mid-2000s, I worked on my first enterprise transformation. After a production outage, I found myself sandwiched between the Senior Agile Coach and the Director of Development.

Let's call the former Avery and the latter Blake.

Blake and I were sitting in Blake's office, and Avery had joined by phone. Since Blake got in trouble for the outage, they wanted to implement a sign-off checklist in the enterprise tool we were using so they could trace the error to its source. As the agile coaches, we had control over making these changes. Don't ask me why.

Avery assumed that was code for figuring out who to blame.

As the "discussion" carried on, Avery eventually shouted, "No Blake! This is a cluster-****!!!!" As Blake slammed down the phone, I could only imagine what my face looked like while I was thinking, "oh, so this is what agile consulting is about..."

Long story short, after trying to shove Agile into the organization for about a year, I realized Agile had nothing to do with Agile and everything to do with change.

So, I spent most of the last almost two decades cross-pollinating the agile, organizational change, and change management worlds.

Today on Day 3 of Agile 2024 , the word change was mentioned plenty of times during the Reimagining Agile panel:

• We need to grow our capacity to change.
• We need to embrace change.
• The core ideas of agile have remained, the containers within which agile is used and expressed have changed.
• We're in a new wave of change, and agile is a must.
• the pace of change is accelerating.

To piggyback on that, Ken Rickard and I hosted a session called, oddly enough, Agile is About Change for the Extreme Open Space.

I started with a quick story. **Disclaimer - it's the end of Day 3 and I tired so I am being intentionally brief.

Back in 2015 I spent a couple of weeks in the land down under running a bunch of workshops.

As luck would have it, there was a stodgy old change management meetup on a Tuesday night, and an engaging and lively agile meetup the next night, right next door.

The change people blamed agile people for not knowing anything about change and for disrupting and breaking their organizations.

The agile people blamed the change people for not knowing anything about agile.

It didn't take long for both "sides" to realize they were after the same outcome, but they simply expressed themselves differently.

Over the last 9 years, I've noticed change people peeking over the fence at agile and seeing "Big Business Agile", or "right-side of the manifesto agile" thinking that's what they need to do in order to "do change at people faster."

Agile people laugh. "That's not what Agile is!!!"

I've also noticed agile people peeking over the fence and seeing phased-based, linear change models and thinking that's what they need.

Change people laugh. "Seriously? We moved on from that a decade ago!"

Don't be offended by that story. Again, it's the end of day 3 of Agile 2024 and I'm tired so I'm being as brief as possible. But that's the pattern and we all know a pattern doesn't mean 100% true, 100% of the time for 100% of the people. But still, it's the pattern I've noticed.

I asked people in our open space session what they thought of the term 'embrace change'. The second the words left the front of my head, I heard someone loudly say "BLECH!!!"

Most people thought the intention of the phrase was good, but it meant:

• y'all need to blindly jump off the cliff.
• It's only consultants who say that or people with no skin in the game because it's a nice sound bite, but they don't have to live with the consequences.

Long story short, the group came to a few conclusions after we chatted about how to iterate our way through change:

1. Why would we agile people look at old change models that are linear, phased-based and solely plan-driven when they already know how to use agile? One person said, "ADKAR is the waterfall of change management." earlier that day.
2. What would happen if we transformed to agile in an agile way by: Planning more frequently; In smaller chunks; In shorter time horizons?

Ken and I shared a bunch of ideas that translated into these images:

• it's logical to say we need to capture the current state, paint a picture of the future state and then transition to it with a plan after our assess and analyze phases.
• We propose to see change as a continual dance between exploration and action . Visualize the change, work in short iterations and shift from push to pull. Use the insights about how people are reacting to the change into the design of the next iteration.

• We've heard the phrase, you can't do agile, you have to be agile. We disagree, you need both. Doing agile is optimization. Being agile is evolution. They are synergistic by nature. Once cannot exist without the other.
• (Bottom left): You cannot assess and make a plan to transform, mostly because no organization made a plan 10 years ago to transform into a bureaucratic nightmare, it just happened. It doesn't mean you don't plan at all, it means you don't assume you can do all of this up front. Start with what's right in front of you and the little RED NUMBER 8 thingys in the image above are 'Explore/Act loops'
• Co-create - don't iterate through change after deciding what the change is, build the change with the people affected.
• Don't get stuck in the rigidity trap by only optimizing.
• The circles along the wavy line represent change events. Sometimes 'optimization' gets more attention, sometimes 'evolution' does. As events happen, that feedback drives the next iteration.

• shift to continual alignment.
• the conversation that creates the canvas captures the 'big picture'. Movers will love it. Moveables will want social proof. Immovables won't like it. Note we didn't say "they'll resist" - Resistance isn't a thing. People respond to change and we must use that response as input into the design of the change, not a blaming mechanism.
• Movers will leave if their pace of change is faster than the organization's pace of change. Moveables can become Movers after seeing social proof.

Long story short, agilists in the audience know agile. They wouldn't use "waterfall" for software projects, so why would they use "waterfall" for changing their organization?

To summarize, I believe it was Jim Highsmith on the panel who said:

The core (values and principles) of agile is the same. The containers that express it (frameworks, methods) have shifted over time.

He used a Star Wars metaphor. Some people saw Star Wars in the theatre. Others on VHS. Others on DVDs, and others on streaming services. The containers (VHS/DVD) have shifted as the world evolved, but the core (the awesomeness that is Star Wars) is the same.

Agile is and will always be just fine but for some reason, people might want to dig out the VHS copy and be disappointed when the picture quality is a too fuzzy to enjoy.

I will nap now. Thoughts?