When Do You Go Meta?

I’m working with clients on their agile transformations. I’m working on that book project I alluded to several weeks ago. These efforts have at least this in common:

We need to work with other people to finish the work.

And, surprise, surprise! People have their own ideas about what to do and when. In at least one agile transformation, the senior management will not consider changing anything about the culture: what they reward, what people can discuss, and how people treat each other. Sure the teams can do “whatever they want” but the managers won’t change. Yet.

In the book project, we just received a request for yet another addition. I can see why. I’m not unsympathetic to the request. And, we must stop adding more scope to this project. We must!

The managers have a ton of data about what they think has worked in the past. They think everything is hunky dory. They see no compelling reason to change.

In the book project, the people requesting additional scope have always done it this way. They see no reason to change either. Not yet.

I bet you have stories like this from your work or your home. What do you do? I see at least these choices:

• Persevere, regardless of the environment. One of my clients calls this “beating my head against the wall.” Keep working on that agile transformation, regardless of management, hoping they will change. Keep taking more scope on that project.
• Stop working altogether on the work. Another client calls this “giving up.” Stop trying to help the organization learn and use agile. Stop working on the book project.
• Discuss the problem and work to discover more options. I’m calling this one “let’s address the real problem in the room.”

I’m not a fan of beating my head against the wall or giving up. When I see problems like these, it’s time to go meta.

Going meta means it’s time to go up a level and look at the system that causes these perceived problems. Instead of trying to solve the problem we see: managers who don’t encourage and by their actions may actually discourage agile or the scope creep request, it’s time to look at the system and the larger environment.

Here are some ways to go meta:

• Ask questions about the values people have. Context-free questions might be quite useful here.
• Ask questions about the quantitative and qualitative data people have.

Here are context-free questions you might find helpful:

• What does success look like?
• Why are these results desirable?
• What is the solution worth to you?
• What problems does this system solve?
• What problems could this system create?

For the data, you might ask:

• What do you see and hear (about this concern)? This question helps people articulate their quantitative data.
• What do you see as challenges? What do you see as surprises? (You might ask more.) These questions get to people’s feelings.

When you try to learn about the other person’s perspective with context-free and data-based questions, you might create possibilities for a different conversation, one that includes alternatives you might not have considered.

My clients and I are having these conversations now, so I can’t report on the progress in these projects. I have used questions like this to break the logjam of seemingly insurmountable problems in organizations. These questions help everyone see alternatives and to work together to create new options.

That, dear adaptable readers, is the question this week: When do you go meta?