Change your organization, or change your organization

Dawn Cannan has a great post up called Change your organization, or change your organization. This is a phrase I use quite often to people, and something I struggled with because of this very thing:

There are many techniques for pushing through resistance, but how can you tell a fight that isn’t winnable? Or, at least, isn’t winnable for you?

It seems to be something you just "know", from what I can glean. And it is certainly not specific to organizational change. Kenny Rogers sang that wildly popular song The Gambler, "You gotta know when to hold ’em, know when to fold ’em, know when to walk away, know when to run…" The question I have always wondered is "*HOW* do you know?"

 

How does one know when it is time to call it in, when it is time to activate the second half of that phase?

At the Agile Developer Practices conference last week in Orlando, Mitch Lacey and I ran a session on ScrumButs. We had 5 ScrumButs that we were going to cover – until we asked everyone in the room to introduce themselves and list their top ScrumBut. This was the list. Notice what the majority are around. “Falling back to BDUF”. “Senior people doing Scrum but don’t want to (and actively sabotaging the process)”. “Talk the talk, but don’t walk it”. And in a session about ScrumButs, we found ourselves primarily talking about organizational values, team behaviors and elements of psychology that are solely around dealing with people instead of the process.

Remember that. People over process. You aren’t introducing a process. You are asking people to change. And people, unless they are in pain, don’t particularly want to change, thank you very much. All the models, all the processes, all the methodologies and principles and values are around one thing – we aren’t dealing with resources or teams or organizations. We are dealing with people. And people don’t fit into tidy mathematical equations, or checklists, or process flows.

In fact, one of the things around Scrum is that organizational impediments are exposed early and often, and the ScrumMaster helps to remove those impediments. Except those “impediments” are actually “people” – people that may be more powerful than whatever leverage you have, and who may not appreciate having a spotlight suddenly shone on them.

As an example, let’s say that the marketing team has always been the darlings of the organization – primarily because the development team works around the clock to get the battery of changes into production that stream from the marketing department. Suddenly, an “agile coach” comes in and posts a big visible chart showing that 62% of the developer’s time is spent on rework – rework that is coming from marketing not wanting to work together to have a cohesive plan. So the marketing VP calls the CTO, and suddenly there is no more agile coach.

What the Lean Proponents like David Anderson and Alan Shalloway discuss is that Lean principles simply report on and metric impediments, allowing the organization to decide if it is worth dealing with. And it certainly could be seen that a gentler introduction may allow greater change than a sudden one (see: How to Boil a Frog).

But at some point we come to a critical head. The team is struggling with wastes that the organization has no intent of removing. Concrete data is dismissed outright. The team can see what life could be like, but can’t seem to find the path to get there. So much so that the clarity of wastes the team sees is actually demoralizing. What then? What’s someone who is attempting to bring agility to an organization to do?

1. Reach out – Sometimes it takes a fresh voice to get ideas across. Try to identify the fear that is holding people back, and find ways to address that. Perhaps it’s training. Perhaps it’s one on one consulting (under the radar if necessary). Perhaps you’ve pushed stuff for so long that your words aren’t effective.
2. Practice what you preach – If you are promoting Test Driven Development, you better have some clue how to do TDD in that team’s code base, or find someone who can. The team needs the right tools, and if you are the one pushing it, they are looking to you.
3. Provide a learning culture – Make sure that people are given slack to be able to discover the lessons you are wanting to bring. It can be a tricky balance (see: The Dreyfus Model Experiment), but people are much more likely to fight for things that they came up with and own
4. Ensure the value system matches – If you are trying to bring frequent releases to an organization which ships once every 3 years, you need to find a way to align that with the other driving organizational values. If those values don’t match what you are trying to bring in, and you can’t find a way to relate them, then you are in for an uphill battle.
5. Be a seed – Sometimes you can plant a seed in soil, water it, give it light and do everything right, and not realize that the soil is only an inch deep, and so right after the plant sprouts, it dies. And you think, “But I did everything right!”. But your plant dying has given the soil a little more nutrients, a little more depth, and a little more opportunity for the next seed to survive
6. Use the law of two feet – In Open Space gatherings, there are several ways of describing when to leave a session, but my favorite is, “If your mind wanders, take your body with it”. If you are coming home frustrated, burned out, tired – that’s having an affect on you, your family and your team. The more you let that fester, the more chance you have of beginning to make irrational decisions which lead to a tearing down of things you’ve built
7. Ask, ask, and ask again – There are many people who have been there. Enterprise agile transitions. Startup failures. Team upheavals. We’ve seen it, we’ve lived it. Talk to people you know and respect. Explain the situation, being as objective as possible. Ask not for justification, but for advice on ways you can be better. And if 5 for 5 come back and say, “What the heck are you doing there?” – then perhaps it’s time to move on.

This particular topic is personal to me because as of last Friday I’m no longer coaching a team I respected and admired for all the things they let me put them through. And there were many times when I questioned what I was doing wrong, why I wasn’t getting it, and how I could improve. J.B. Rainsberger and Corey Haines termed it best in a discussion I had with them. J.B. said, “It sounds like a marriage that is on the verge of breaking up because of co-dependency issues”. And it’s true. I was worried what would happen if I left. I actually thought, “I’m abandoning them”.

Abandoning. Believing that a team that has been delivering software for 13 years was suddenly going to fall flat if I left. A team that has delivered 4.5 million lines of code. And while it’s true that I’ve seen other teams fall flat after I left, it usually was coincidental and me leaving was a direct relation to the sense of impending doom.

Once I realized how much I was letting them lean on me, I realized that I had to go. So I spent several months insuring that my selfish needs were met – that they had everything I thought they needed to keep on. And watched that the more I stepped back, the more that leaders came in and stepped up. Watched as the team was grilled by Ron Jeffries and Chet Hendrickson and knew the answers. They didn’t always practice them, but they knew them. And then, on Friday, met with the VP with the best conversation I’ve had:

VP: Is there anything that needs to be transitioned from a knowledge perspective?

Me: Any minor things are documented in this wiki, and most everything in there has already been picked up by someone on the team on their own over the past couple of months

VP: What about processes? Who owns those?

Me: The team owns the processes. They are already running everything just fine.

VP: Is there anything else?

Me: Nope, I think they have everything they need

 

No frantic last minute transitions. No fears of things cropping up they can’t handle. And best of all, no transition task list. By me simply stepping out of the way over the past several months, the team picked up the critical things. My fears of abandonment changed to the nervous fear of a parent watching their child drive off in the car by themselves for the first time. There’s always a nagging fear something really bad will happen, but all bets are that they’ll hit only some minor bumps and generally continue to improve.

Will it be all roses? Probably not. After all, we’re saying that there are underlying organizational impediments that were in the way, and that without a desire to change, won’t change unless a pain event happens. But because I worked to make sure they had the tools, and build transitional relationships, I know I can stay in contact with them and perhaps offer guidance in the future as things progress.

Dawn may be in a tough spot, one that feels like you are losing everything you’ve worked for. But really you were a vital role – that first hook into what looking at organizational flow, wastes and organizational agility can mean to your company. I relate it to a training class I did when I was still a firefighter. It was urban rescue, involving finding a trapped firefighter who had gotten injured in a high-rise office building fire.

Visibility is zero. You are covered in gear, with a mask over your face breathing air from your tanks. You have no idea what the floor plan of the building is, nor what is going to be in your way. All you know is that one of your guys is in there, trapped, hurt and running out of air and time.

So you and your partner head in. And you stick to a left search, meaning you’ll always follow the walls left. You have 15 minutes of oxygen in your tanks, but are only allowed to go in for 5 minutes to give you ample time. You can hear the PASS device beeping from the injured firefighter. You just want to get to him.

And then your teammate smacks the back of your helmet. The call has come in that you’ve been in too long. You have to come out now. You don’t want to come out now. Every fiber of your body wants to keep going, to go just a little bit longer, a little bit further.

But here’s the great thing. The whole time you’ve been going, you’ve had a hose, or a rope, or something else that is tied to the entrance. And so you loop the end on a halligan bar, jam it into the wall, and get out as quick as you can. And the next team is at the door, and within 30 seconds has followed your guide back to where you were, and is able to get the injured firefighter out 5 minutes later.

Sure, the guys who pull the firefighter out are the ones who get their picture in the paper. But I can tell you from experience that without a doubt those guys know they could not have done it without you, without the line you laid, the route you chose, the experience you gained.

And so it is with organizations. I wish we had more Chief Engineers in organizations and that managers would not be afraid to be leaders as well. I wish more organizations would approach the lean principles and not be afraid to assess the overall flow of waste in their organization and tackle that. I wish that more executives would not be afraid of exposing impediments and waste and addressing them head on, instead of being holed up in dysfunctions. And finally, I wish that agile adoption didn’t have to come from team members who suddenly see the value and fight to bring that value to their teams, their departments, their organizations.

But when you find yourself doing that, don’t let it destroy that value in yourself. Be cautious of tunnel vision. And don’t be afraid to walk away. Because that might be your most powerful tool in changing organizations.

So Dawn, I admire you for posting that article, for addressing the concerns you have. And I wish there was a way to tell you when to know. But take heart in this – the work you’ve done *has* had an impact in your organization, in your teams, an impact that won’t readily go away. Think not only about what will happen when you leave, but how you can impact other organizations with the knowledge you now have. And don’t be afraid to let go. You might be surprised at what happens next.