Two of the most common questions I am asked by customers is how to successfully implement Agile and SOA in their organization. While there is no silver bullet answer, the question is not really all that specific to SOA and/or Agile. The question is about how to drive change.
Change is hard because of the unknowns involved which amounts to a certain degree of risk that must be undertaken when implementing change. In their excellent book "Fearless Change: Patterns for Introducing New Ideas”, Mary Lynn Manns and Linda Rising discuss the following personas that are involved in any kind of change process:
- This is new so it is cool. (Innovator)
- This is an interesting idea, but I want to hear more before making a decision. (Early Adopter)
- I want to see what other people think about the new idea before I make a decision. (Early Majority)
- I’ll accept the new idea when I have to. (Late Majority)
- It’s always been done this way … why do we have to introduce anything new? (Laggard)
You can apply these personas or roles to any kind of organizational change. Regardless, there are two common ways that change begins and often fails: Top-Down and Bottom-Up.
Let’s look at scenarios for each, which interestingly apply to both Agile and SOA.
Top-Down
CIO: I am sick and tired of getting beat up by the business because we are perceived as slow. OK, well maybe we are slow, but we have so many applications that we integrate with and they are so closely coupled to one another that when one application goes down, a domino effect ensues. This is why 70% of my resources are allocated on “production support”, but the reality is that we are a “code-and-fix” shop. This needs to change or I will be out of a job 18 months from now.
If the technology organization knew any better, they would already be a business enabler, and I am tired of being berated every week at the CEO’s staff call. Morale is at an all-time low, my star developers are burnt out and ready to quit and we need to change, now. I am going to organize a town hall meeting and roll out plans for us to minimize waste, and become more flexible to business needs effective on Monday.
Analysis
Obviously, we have an Innovator on our hands. Aside from thinking about her job security, the CIO is convinced that there is a better way. Unfortunately, she is about to make what will likely be a grave mistake. She’s underestimated the time and effort it is going to take to win the Late Majority and to what extent the Laggards will do all they can to see to it that this new way of doing thing fails, and fails fast!
Why? Because people need to feel involved. No, scratch that. People need to be involved in change. Otherwise, they will naturally resist due to fear. If they are not a part of the solution, then they must be a part of the problem. Early Adopters can certainly help, but as far as the Late Majority and Laggards are concerned, Early Adopters are safe because they are already aligned with the CIO and should therefore not be trusted.
Sound familiar?
Now lets look at a typical Bottom-Up approach.
Dev-Lead: The business is out of touch with reality, but rather than complain about it, the best we can do is make sure that we are the best damn development shop in the company. How else are we ever going to be able to keep pace with the ever changing requirements and Rube Goldberg machine that is our so called enterprise architecture. In fact, if we apply the right techniques to our design and process, it will soon become visible that we are not the problem and the organization will finally recognize our brilliance and the error of their ways.
Analysis
While the dev-lead gets an A for effort, and will likely grow the skills of his team significantly by doing all the right things, the reality is that nobody in the organization cares about architecture, design patterns or methodology. If the organization is not bought in, it doesn’t matter how efficient or well oiled the development machine is, or how loosely coupled and perfectly factored the services they produce are. No one will use their services until they are sanctioned by the business, so at the end of the day, a mini-empire has been built but nobody outside of the group is aware of just how much value this team brings.
Middle-Out
Did you notice what persona has been lacking in both of these approaches? The Early Majority. This persona is the most critical to embracing change, even more so than the Early Adopter on one extreme and the Laggard on the other. Why? Because while the Early Adopter will undoubtedly help your cause, organizational capital is key to this person truly influencing the change. That is not to discredit the value or the impact of the Early Adopter (particularly for helping your confidence and providing you with much needed PR support), but these people are few and far between. The Laggard, on the other hand is either going to become a Late Adopter or will become irrelevant because he will leave the organization. Often, this is just the way the cookie crumbles.
The key is to get the Early Majority engaged and supportive of your efforts. They will provide the swell that will eventually form a wave of success, but you have to start small and focus on how you can make them successful. So who are these people? Well, they typically aren’t executives because they are off running the business. We also know that focusing exclusively at the team level is not the answer either because they need visibility and buy in to ultimately succeed.
The answer? Middle management. Middle management is the lifeblood of your organization that makes your organization thrive. These are the line-of-business managers responsible for the daily operation of their business unit, product managers who are focused on ensuring their products continue to be successful so they can get continued funding, and program managers who are navigating these armada of initiatives towards the strategic vision that your CIO’s boss is leading. Each of them have targets, goals and problems that need solving. Help them and they will in turn help you. Help enough of them, and you will have mini-snowballs growing across your organization that will result in an avalanche of success.
But How?
Identify what the business drivers are behind their goals and capture those as your requirements. Ask them to prioritize them and then pull a small team together and estimate them. Understand your resource realities and propose a small step forward. Something not so small that it will go unnoticed, but at the same time, not so big that it is doomed to fail. Execute on it and review your results. Now, repeat the process, iteratively learning from your mistakes.
As you do, more and more will start to take notice. Moreover, they will be involved. Before you know it, each of these wins will gain you an Early Majority made up not only of people you have helped in the process, but share ownership because they are an active part of the solution.
What if I Fail?
The key to driving change from the middle-out is that the responsibility for success and failure doesn’t fall to one sole individual. Even if you do fail, it is better to fail early and small than late and big. This is why Top-Down change rarely works- by the time the organization realizes they’ve failed, the entire initiative is doomed. With a middle-out approach, failures are learning opportunities that can be refined and reapplied incrementally without risking organizational failure. This is the key to the middle-out approach.
“If you are not willing to risk the usual, you will have to settle for the ordinary" -Jim Rohn