by Jason Little

I learned that “agile” was a thing around 2007. Before that, in the early 2000’s, the team I was working with was already following the values and principles, more or less, and we were using elements of Scrum and Kanban.

We had ‘daily huddles’, we did weekly team meetings to figure out how to work better and be happier at work (AKA: agile retrospectives), and we limited the number of projects we conducted simultaneously.

After I learned agile was a thing, I pretty much considered anyone who didn’t get it to be an idiot. It didn’t matter what was important to them, as long as they were being agile, I was happy. If they weren’t, I’d clunk them over the head with an agile stick. If that didn’t work, I’d clunk them with a bigger agile stick and eventually give up because I was clearly smart and they were clearly hopeless.

In some cases #agile is the answer and in others it’s not 

@jasonlittle on Twitter

After running into a few brick walls I realized that the problem wasn’t those people, the problem was me. I didn’t take the time to understand their perspective and what was important to them.

Recently I had a conversation with a team and someone asked me what made this agile stuff stick in organizations and what made it not work. I told him that it’s up to the people who have to live with the outcome.

At some point the pain of the status quo will exceed the pain of the change and then it’ll stick. I told him there’s little I can do as an external coach to make it happen. I can poke the system, I can be a megaphone for a team if they don’t feel safe and I can ask lots of dumb questions since I’m not a permanent fixture of the system, but I can’t make the change work.

Sometimes people only need somewhere for their team to sit so they can collaborate better

@jasonlittle on Twitter

I’ve seen many times where agile coaches get frustrated that they can’t get the organization they’re working with to be more agile and I remember that same feeling. It took many learnings to realize that I was actually be hired to help people solve problems. Agile might be the answer in some cases, and in other cases, it might not be. Sometimes people only need somewhere for their team to sit so they can collaborate better.

If you’re working on a change that seems stuck, or if you’re having a hard time influencing people, here’s my challenge to you:

Challenge: Create a system empathy map

I don’t know if and empathy map a thing, but it’s something I find helpful to explore how the system around me is affected by the change I’m being asked to do:

1. What departments, teams and groups of people are affected?
2. What do they stand to gain?
3. What are their current pains?
4.  What’s in it for the people within those containers? (ie: in the case of agile, do the project managers think they’re going to be out of a job because Scrum doesn’t have a project manager role?)
5. Which groups are highly affected by the change? Which ones have a minimal impact on their daily lives?

To get an idea of it, see the Management 3.0 Practice of Personal Maps or learn directly in a workshop

Validate your assumptions with the people in the system who have to live with the consequence of the change

1. Create change personas: Understand that some people value certainty more than others and they might fear the change
2. Work in the whitespace between people with differing opinions and leave your opinions out of the conversation unless you’re asked, or unless you’ve asked for permission to share your thoughts!

Navigating change can be hard. It’s pretty easy to say that we need to empathize with the people being affected by change, but it can be difficult to paint a picture of what the system dynamics look like. Try creating this diagram and see if it helps you avoid some of the pitfalls I fell into until I learned it wasn’t all about me!

Share your experiences here in the comments section below.

Also Read: ‘ Three types of empathy work developing’