Source: http://www.jrothman.com/mpd/agile/2017/03/becoming-an-agile-leader-part-1-define-your-why/

Define Your Why

Your agile transformation isn’t proceeding the way you thought. People use the right agile words, but they’re not changing how they work. Teams aren’t collaborating, managers still talk about “resources,” and the projects aren’t delivering finished value. Your agile transformation is stuck.

Maybe it’s time to return to your why. Why is your organization moving to agile? Do you know?

Ask the people who wanted agile these questions:

• What is valuable to us?
• How will we measure what is valuable?
• What is the first deliverable we can achieve to provide value?

When you ask these questions,  people start to remember why they wanted agile in the first place. I’ve heard answers like these:

• We want to release something more often than once a year (or longer).
• We want to increase the quality of our products.
• We don’t want to hear customer complaints as often, for releasing or bug reports.
• We want to have fun.
• I want to master this code base.
• I want to learn how to automate which tests.
• I want to feel as if I’ve done a great job.

Managers often want to see revenue increases, customer happiness, and a decrease in the cost of providing customer support and project cost. Teams often want more satisfaction with their work and a feeling they have done right by the customers.

If you are an agile leader, you can develop measurements to help both sides see what they’re aiming for and how to get there. These measurements help people see why they are changing and if they are accomplishing the change—the why. But, first you have to know the why. (And, don’t be surprised if everyone has a different why!)

Who to Approach

Now, it’s time to talk to people across the organization. The question is this: Who do you talk with, to unwedge your agile transformation?

You know that the org chart is one way of seeing the system. And, there are many other ways to see your system. One way is an organizational map.

The organizational map helps you see who might have interests, pain, or power in different areas of the organization. You can then decide who and how to approach each of those people. Given their interests, you have some idea about how they might respond.

Every single time I’ve worked with people to create their organizational maps, they have learned something. Most often, they realize that someone else in a corner of the organization has key information for agile success. Sometimes, the transformation advocate realizes that another person has less or more power than we expect. Sometimes, the agile advocate realizes that if they supply some key measurements, they might be able to unlock the agile transformation.

Sometimes, people are surprised that developers or testers are the people with power and help. Sometimes, it’s people across the organization, such as someone in Finance or HR. Your transformation allies can be anywhere in your organization.

The organizational map helps you see who is helping your agile transformation, who is neutral, and who is not helping. This map, with names blacked out, is from participants at last year’s Influential Agile Leader.

In my experience, the people who are neutral or not yet helping are not “resisting change.” They are not skeptics, although they may act skeptical.  Here’s what I have found most often: they haven’t discovered the usefulness of agile to achieving their goals.

If I understand the why for agile and understand their interests, power, and pain, I have an entry into asking them what their goals are, especially if the map didn’t make that obvious.

Nurturing and maintaining an agile transformation is hard work. I like knowing who I should talk to, to make sure I’m gaining the most benefit from all of my work. I can gain allies in my measurement-gathering and in the actions I want to take for the agile transformation. I might even consider a change for how to transform the organization.

How to Create Allies

Now, how do you create allies so you can unwedge your agile transformation?

First, here’s a big question: do you have a relationship with this person? If so, terrific. You have options as below. if you don’t have a relationship yet, it’s time to build a relationship.

Let’s assume you have some sort of relationship with this person. In that case, you might ask for coaching.

You might say, “Hey, wait a minute, Johanna. I’m the coach (or leader in some way). Why would I ask for coaching?”

When you ask for help, as in coaching, you offer your other person (often called a client) a gift. You offer explicit permission to explore options with the other person’s support. This is especially helpful if the other person is your peer or is senior to you in the hierarchy.

I know, this is turning the normal definition of coaching around. Many people think that if they are one of the agile transformation leaders , they have to have all the answers. No, you don’t. You might not know what the smallest possible change is. You might not be aware of the forces that prevent change (I’m assuming good intentions on everyone’s part). You might not know what this person might gain or lose with an agile transformation.

Asking for help is a sign of strength, not weakness. Asking for help shows transparency and a willingness to consider other options.

You might “lead” the coaching conversation by saying something like this: “Here’s what I’m seeing. We’ve done this and that and gotten these results. Do you see the same things?” If the person has different data, wow, that’s great to learn. If you have the same data, you might continue, “I’m concerned we’re stuck. I see these options to solve these problems. Do you see something else?”

When you ask for other options, you open the conversation (and your brain) to possibilities you might not have seen before.

This coaching conversation is very different from, “I’m the agile expert and I’m here to help.” You might be the agile expert. You are definitely there to help. And, you need to enter the other person’s context to understand what’s going on for that person.

You might be thinking, “Oh, this is going to take time.” Well, it will. These are one-on-one conversations. You might have to wait a week to get on someone’s calendar. And, what have you got to lose? What’s the worst thing that can happen?

Determining Next Steps

Now, it’s time to think about what you will do next.

You might be thinking, “I know what to do next. I have a roadmap, I know where we want to be. What are you talking about?”

Influence. I’m talking about thinking about discovering the short-term and longer-term actions that will help your agile transformation succeed with the people who hold the keys to your transformation.

Here’s an example. Patrick (not his real name) wanted to help his organization’s agile transformation. When he came to the Influential Agile Leader, that was his goal: help the transformation. That’s one big goal. By the time we got to the influence section, he realized his goal was too big.

What did he want, right now? He was working with one team who wrote technical stories, had trouble getting to done, didn’t demo or retrospect, and wanted to increase the length of their iteration to four weeks from two weeks. He knew that was probably going in the wrong direction. (There are times when it’s okay to increase the length of the iteration. This team had so much change and push for more delivery, increasing the time was not a good option.)

He thought he had problems in the management. He did, but those weren’t the problems in the team. When he reviewed his why and his map, as in Part 1, he realized that the organization needed an agile approach for frequent delivery of customer value. If this team (and several others) could release value on a regular basis, the pressure from the customers and management would lessen. He could work with the managers on the project portfolio and other management problems. But, he was sure that the way to make this happen was to help this team deliver frequently.

He realized he had two influential people to work with: the architect and the QA lead. Both of those people looked as if they were “resisting.” In reality, the architect wanted the developers to refactor to patterns to keep the code base clean. The QA lead thought they needed plans before creating tests and was looking for the “perfect” test automation tool.

He decided that his specific goal was to “Help this team deliver value at least as often as every two weeks. Sustain that delivery over six months.” That goal—a subset of “go agile”—allowed him to work first with the architect and then with the QA lead and then both (yes, he practiced all three conversations in the workshop) to achieve his small goal.

Patrick practiced exploring the short-term and long-term deliverables in conversations in the workshop. While the conversations didn’t go precisely the same way back at work, he had enough practice to move between influence and coaching to see what he could do with the people in his context.

It took the team three more iterations to start delivering small stories, but they did. He spent time enlisting the architect in working in the team with the team members to deliver small stories that kept the code base clean. He asked the architect for help in how to work with the QA lead. The architect showed the lead how to start automation and refactor so the testers could test even before the developers had completed the code.

It took that team three more months to be able to regularly deliver value every week, without waiting for the end of the iteration.

Patrick’s original roadmap was great. And, once he started working with teams and management, he needed to adjust the deliverables he and the other coaches had originally planned. The influence conversations allowed him to see the other people’s concerns, and consider what small deliverables all along the way would help this team succeed.

Some of what he learned with this team helped the other teams. And, the other teams had different problems. He used different coaching and influence conversations with different people.

Learning to Learn

Now, it’s time to think about how you and the people involved (or not involved!) learn.

As an agile leader, you learn in at least two ways: observing and measuring what happens in the organization. (I have any number of posts about qualitative and quantitative measurement.) Just as importantly, you learn by thinking, discussing with others, and working with others. The people in the organization learn in these ways, too.

The Satir Change Model is a great way of showing what happens when people learn. (Learning is a form of change.) Here’s the quick intro to the Change Model: We start off in Old Status Quo, what we did before. Along comes a Foreign Element, where someone introduced some kind of change into the environment. We have uneven performance until we discover our Transforming Idea. Once we have an idea that works, we can continue with Practice and Integration until we have more even performance in New Status Quo.

In the Influential Agile Leader, you have a chance to think alone with your pre-work, by discussing together such as when you draw your map in Part 1, and by working together as in coaching and influence and all the other parts of the day. One of the most important things we do is to debrief all the activities just after you finish them. That way, people have a chance to articulate what they learned and any confusions they still have.

Every person learns in their own way, at their own pace. With interactions, simulations, and some thinking time, people learn in the way they need to learn.

We don’t tell people what to do or how to think. We suggest options we’ve seen work before (in coaching). We might help supply some options for people who don’t know of alternatives. And, the participants work together. Each person’s situation is a little different. That means each person has experiences that enrich the entire room.