If you’ve worked in a large organization, you know how slow and difficult it is for them to change.  The thing with Enterprise Agile (or any other large organizational change), is they tend to follow the same pattern:

Appoint a centralized department to devise an enterprise-wide process, while pockets of movements emerge, and then figure out how to get other people to change, without involving those other people.

It’s this ass-backwards thinking that got our organizations into this mess in the first place, so how can we expect it’s going to be any different this time around? We standardized project management with a centralized PMO, yet no one knows what is going on with our projects. Then we standardized HR, yet our employees are disengaged. We standardized process improvement teams, yet we don’t improve anything. Now we’re standardizing Agile, and in some cases, Innovation groups, and, surprise, that’s not working either.

Some causes are the commitment to over-specialization, and process-first thinking. How can we use a framework, operating model or method to ensure successful change?

Well I suppose you could try this:

What will you do with the people who don’t fit into the new picture?

Unless you’re the person who’s responsible for those 2 fields, in that one table, in that one database, you might be ok, but odds are, there isn’t a place for everyone (in their existing functional role), in the new organizational structure. Some teams don’t need managers, some do. Sorry.

A few years ago I did an experiment using the Management 3.0 Meddlers game to design a system a work by modelling the existing hierarchy. Management 3.0 is the first application of Agile to management, and the purpose is better management with fewer managers. Nowadays every group is jumping on the how to make managers more agile bandwagon. In my view, they’re missing the point, and placating the status quo. I am looking directly at you, Certified Agile Leader program from the Scrum Alliance. In the words of Grampa Simpson…”FOOOR SHAME!”

Ok, back to our Meddlers experiment. After drawing an example, we designed the new system of work using the Meddlers game pieces. We stayed high-level in order to protect this particular organization’s privacy. The result:

As organizations move to Agile, most people throw out the term ‘value streams’, or ‘full-stack teams’. Easy to say, hard to do.

So we started there. Let’s design that value stream. Now let’s look at the existing hierarchy. Now let’s move people to the new system and see who’s leftover. Whenever I’ve tried this, the conversation quickly turns to…”uh…uh oh.”

In other words, this discovery process made the effort and scope of change real. The discussion was no longer about titles, roles, value streams, and process. The discussion was around how to approach this massive shift in how our people, and work are organized.

This is the hairball we need to untangle, and that’s only going to happen through conversations with people who are responsible for those systems (physical, virtual, and people systems), and the people doing the actual work.

Recently I visited another enterprise organization that was starting down the road of their Agile journey. Of course, they were following the same pattern of every other enterprise organization I’ve worked with, or visited. Have a centralized group create a standardized process, and push it out. They wanted to know how they could create more awareness and desire. Yes, they are a Prosci shop.

As we modelled out their system, it became clear what the problem was, and I left them with this question:

“I see you’re a Prosci shop (as was obvious by the way they talked…oh…and the ADKAR blocks sitting on their desk), now imagine I come in with a new change process that you must follow. How would you react?”

The initial reaction was a bit of shock, and I could see a reaction of “but, we have to use ADKAR…that’s our method…” and a few seconds later, the lightbulbs went on:

“OOOOOH! That’s EXACTLY what we’re trying to get other people to do!!” Here’s a test. Next time you’re at a conference, listen to how many times you hear “how can I get them to…” or “we need to change behaviours…“. Start with yourself. Always.

Now, let me back-up a bit. I have never worked with anyone in an organization that didn’t have good intentions for the models they use, or the creation, and pushing of new processes. The people tasked with these mountains to climb are handcuffed by the system they work within, and they are tangled up in the hairball just like everyone else. In fact, I worked with an individual contributor (I hate that term…simply trying to protect the innocent here!), who had on his performance mandate:

“ensure a minimum of X Agile projects are run. Ensure the creation, and execution of an Agile rollout plan across the organization”

Really?

An individual contributor had the ENTIRE organizational transformation on his performance review? Makes perfect sense! #sarcasm.

In one way or another, we are all handcuffed by a system that encourages individual contribution, and accountability. As a facilitator of change, it’s our job to help figure out how to undo this. Problem is, we don’t own the change, and we don’t have the power to do it. Remind me again why we do this? 8-/

For starters, let’s agree that the way we approach organizational change today is un-natural. It’s not how humans interact. There’s no standardized way to organize your kitchen. You don’t one day get a flyer in the mail showing kitchen utensil organization 4.0 with a due date for implementation. There’s no standardized process you follow to buy your groceries. When people are unhappy with the status quo in our societies, they do something about it. They contact a local member of government, or use public forums to state their case. Societies evolve naturally, not by implementing a new walk-your-kids-to-school framework based on best practices for putting one foot in front of the other.

In order to change our organizations for the better, we need to visualize, and understand that hairball, and how the fibres interact with each other. While I had to re-create this for privacy reasons, I’ve tried this experiment twice. The goal is to understand the dependancies across a large organization so the decision makers can make a more well-informed choice about how to approach the change:

Obviously this won’t make sense to you. It’s the creation of the artefact that generates the learning.  Here’s how the conversation flowed:

• what teams or projects exist today?
• how are these teams linked by projects or programs?
• who are there customers?
• what applications/systems do they own? (That is, close to 100% autonomy)
• what applications/systems do they integrate with?
• who owns those other systems?
• what type of constraints (audit, compliance, marketing, legal etc) exist?
• how is work co-ordinated today?
• what is, and isn’t working given how that work is co-ordinated?
• how does work get sequenced, prioritized, and budgeted for?
• which stakeholder would rather be eaten by a shark than change that system?
• who are our early adopters who are fed up?
• is there a better way to co-ordinate the teams?

For those keeping score at home, this is co-creation of change by using a coaching stance. You could use a teaching stance and simply design the system for the organization, but they aren’t going to learn anything.

Those questions led to the creation of the diagram I drew on the whiteboard. I’ll show an example here:

Think of this as Organizational Chart 2.0…or maybe 3.0 if that sounds more hip. Do kids still say that? Anyway, organizational design patterns aren’t a new concept, however they’re typically visualized by functional responsibility, and don’t take into account the other parts of the organization that make it difficult to change.

This might make a little more sense, but here are the highlights:

• Red X’s show co-ordination points.
• Thickness of the blue line between Business and Delivery shows stronger constraints (IE: freedom of information act, segregation of duties, other audit stuff)
• how teams/projects are linked into programs
• impact of the dependancies between market-facing teams and backend teams (indicated by H, M, L)

If that’s still too tasty of a hairball to make sense of, here’s a video overview of how to construct it:

Is this going to ensure successful transformation? Nope. It will, however, communicate how hard large-scale transformation is, and why our delivery has grinded to a halt.

Think of this as a big 3D puzzle of your organization. Put it on a wall somewhere and add/change it over time. Societies don’t run on linear org charts. Sure there are mayors, board members, council members, and citizens, but the key is in how they interact with each other.

Once we crack the nut of using social design, and the idea of social movements to organizational change, the more likely our organizations will be equipped with the adaptability they need to survive the next wave of disruption.