Organisational Alignment

When I refer to Organisational Alignment, what I mean is which parts of the organisation are going to be supporting enterprise agility? Where is the push coming from? Who thinks it’s a good idea? Who are your main supporters? Who is just along for the ride? Where will your main obstacles come from? Generally, unless you are exceptionally lucky, the desire for organisational agility will be coming from a relatively small part of the organisation. Where that part is located in relation to the wider organisation is crucial. The rest of the organisation will generally be either unaware, indifferent or actively hostile.

Organisational Alignment is a factor that most of the current agile scaling frameworks either ignore, gloss over, or worse, assume. How the organisation is aligned is a really key thing to know. Where the support for agile is coming from will seriously affect how agile can be introduced, how far it can go before it meets resistance, the type of resistance it can meet and so on. If you ignore it, or assume you have alignment where you don’t, you can be hit with issues from completely unexpected directions.

Having worked as a coach in a number of large organisations, I have found that organisations tend to align around agility in a number of fairly standard ways. These are my alignment patterns. There are two dimensions to an alignment pattern - vertical (which layers of the organisation’s management hierarchy are aligned) and horizontal (which parts of the organisation are aligned).

I have identified three vertical patterns (bottom up, middle out and top down), and two horizontal patterns (IT lead and business lead) plus a “fully aligned” pattern that represents the ideal state for an organisation looking to adopt or expand organisational Agility.

Understanding, and influencing the organisational alignment is the key factor in a successful adoption of Enterprise Agility. If you can pick which alignment pattern you are dealing with, that gives you some insight into the sorts of issues you will experience when managing a transition to organisational agility.

Knowing your alignment pattern lets you pick the right adoption pattern to get the best success. Alignment patterns enable adoption patterns. Adoption patterns enable execution patterns. The three levels of pattern feed off each other. Pick the right combination and the patterns reinforce each other. Pick the wrong ones and they will interact destructively.

Essentially, different alignment patterns work well with certain adoption patterns while blocking others. Pick the adoption pattern that matches your alignment pattern and things will go smoother than picking one that is incompatible.

Beyond just understanding alignment, the ability to influence alignment is also critical. The degree to which the organisation is aligned will limit the degree to which it can adopt an agile approach. Each agile alignment pattern has a natural agility limit. Once you have hit the current alignment’s limit, if you want to go further you will need to influence the organisation into a new alignment pattern which has a higher limit.

Most of the work in enterprise agility is not in the mechanics of agility (the execution patterns) but in flipping an organisation from one alignment pattern to the next. Get the organisational alignment right and the agile mechanics will start to take care of themselves.

The Patterns

Bottom Up

Bottom up is on the vertical dimension and it’s really simple - the folks at the bottom of the organisation want to go agile but management is resisting. This is a really common situation. The dev teams know about agile; they may have used it in other organisations, they may have learned it at university, they know the benefits and want to apply them to their work in this organisation. Management, though, are reluctant (if they aren’t - great… but that’s a different pattern which I’ll cover later).

In an organisation with bottom up alignment, agile is usually very easy to get started at the team level (in fact individual teams may already be using agile and just not telling anyone) but very hard to expand beyond that. It’s also very hard to keep agile going, as it’s continually causing friction with the rest of the organisation. All organisations have a built-in immune system that tries to eliminate things that challenge the status quo. This is a particular problem with bottom up adoptions.

To work successfully in a bottom up environment, it’s really important to pick your battles well. The organisational immune system will be fighting back all the time and it’s much stronger than you are. A purist approach won’t work here, you will need to be pragmatic. Pick key battles that you know you can win. Accommodate the organisation on the rest. This may well make you do things that make you cringe (Gantt charts for an agile project anyone?) but persevere.

It’s often a good idea to start small. Start at the team level. Pick the right place to start. Pick one area which is an easy win, preferably with sympathetic (or at least not outright hostile) management and focus your efforts there.

Build quick successes. Don’t even think about scaling beyond maybe a couple of teams. Better to have one small area that does an amazing job that lots of little pockets of ho-hum success scattered everywhere. Get the teams running well. Build up technical practices. The organisation will see benefit from this. Publicise the benefits as widely as you can.

Win management over, even if it’s in just one small area. Then they get to brag to other managers about how great their part of the business is running. That will go a long way towards winning the rest of management over.

If you can win management over, you have just changed the organisational alignment and a whole bunch of options open up for you.

Top Down

In this case, the top levels of the organisation want agile but the levels below them are resisting (again, if they aren’t… great, but that’s a different pattern). This can be a tricky pattern as senior execs may want agile but often don’t know much about what it is and what it means for their organisation. With most agile adoptions, you need to spend a lot of time educating your detractors; with this pattern you may need to spend as much time educating your supporters as well.

They probably see agile as a delivery methodology and expect it to be implemented that way. They don’t see it as a major cultural change at all levels (including theirs). Tread carefully. Don’t lose them. It’s very easy to go in too hard, making it seem like too big a change, too quickly. Senior managers got where they are by successfully managing risk. They tend to be quite risk averse. They will want to see a strategy that manages organisational risk during the transition.

The trick with this pattern is to work out how far down in the organisation the resistance goes. Is it middle management and the delivery teams? Or are the delivery teams supportive and the blockage is in the “frozen middle”. If it’s the latter, you can work top down and bottom up, which makes your life much easier. Use your successes with the delivery teams and the influence of your senior supporters to unfreeze the middle.

Often middle management are frozen due to pressure from above to deliver. They probably have KPIs based on waterfall measures that their bonuses depend on. They have established power structures and relationships based on old ways of doing things. Fortunately, these can be fixed with the help of senior management. Get the KPIs aligned to agile measures. Work with senior management to minimise the threat to bonuses and power structures.

Work from below as well in the same way you do for a bottom up alignment - start small, where you do have middle management support, and get quick wins. Use those (with support from above) to bring more middle management on side.

If the resistance goes deeper though, right down to the dev teams, then you have a much bigger problem. Although dev teams are often the first to jump on board with agile, in some organisations the dev culture can be quite stagnant and resistant to change - “we’ve been doing it this way for 20 years… why change?”. This is particularly true of organisations with a lot of complex legacy infrastructure.

If you have resistance right the way down, you really have your work cut out for you. Find the point of least resistance - a dev team that is supportive - and use that as an example to get the rest of the organisation unstuck (with lots of help from above). Or a middle manager who is supportive and use that support as a way to get their teams moving. If there isn’t a point of least resistance, you may need to create one. Use your management support to build an agile capability. Pick supportive people from around the organisation and move them into your new agile capability. Hire in talent if necessary.

You can try introducing individual practices one at a time to minimise change - try a fortnightly retrospective first. Then maybe a visual management board (VMB), then a stand-up and so on. Let the teams see the benefits of the practices then introduce more.

Again, use your senior management influence to unblock the middle. Get agile KPIs in place. Make bonuses dependent on organisational ability. Get the middle unfrozen.

Top down gives you a powerful lever. A stuck organisation is a formidable obstacle though. Even with a powerful lever it’s too big to move in one piece so apply your lever strategically. Get one piece moving and the rest may move more easily. Try to get more of the organisation aligned.

Your biggest risk though, in a top down transition, is losing your executive support. Keep those folks on side. Give them wins. Show them the benefits. Educate them on agile. Actually, at exec level you are often better off talking about Lean rather than agile. Lean is in business language. Agile was born from development and has a lot of development language in it. I tend to pitch to executives using Lean and position agile as the way we implement Lean within IT delivery.

Middle Out

As the name implies, this uncommon pattern occurs when change is being pushed by the middle of the organisation - middle management.

Actually uncommon is an understatement, middle out is so rare that I have never seen it in the wild. It’s still worth looking at though, as winning over middle management is key to the success of both the top down and bottom up patterns we looked at previously. By looking at why middle out is so uncommon, it can help us to understand what prevents change from occurring at this level in large organisations, and to see what we can do to change that. What we are talking about here is the phenomenon of the frozen middle.

The frozen middle is a term that has been around for a few years. It refers to the tendency for organisational change to get stalled or frozen as soon as it hits the middle management layer. Top management wants a change but middle management seems to be locked into place and the change just dies. The common tendency here is to blame middle managers. We compare them to the pointy haired boss in Dilbert cartoons [MAY NEED TO INSERT A COPYRIGHT HERE OR SOMETHING]. We send them on change management courses. But nothing seems to work.

The real reason nothing works is that it’s not their fault at all. As Deming identified back in the 1950s -

“The workers are constrained by the system, and the system belongs to management”. [NEED FOOTNOTE WITH REFERENCE]

Middle managers are constrained by the organisational structures and cultures that are really the responsibility of top management. Middle managers are not frozen because they are obstinate or backwards. Most of the middle managers I have encountered are acutely aware of the need for change. They support the change. What they can’t see though, is how to implement that change within the constraints they have. They are frozen because the organisation locks them into place.

The most common constraint the organisation puts in the way is how people are measured. Often, even though an organisation is asking for a change, the KPIs against which managers are measured (and often paid) reflect the old state rather than the desired new state. The classic example is an organisation that wants agility but measures its managers against a percentage of signed-off requirements delivered on time. What organisations are essentially asking managers to do is make a choice between implementing change or scoring well on their next assessment. It’s a well known phenomenon in psychology that measuring something makes it look important, so by having the wrong measurements in place, the organisation is sending a signal (unintentionally) that the change isn’t important, but the old behaviour is.

The other common one is cross-functional change. Managers generally have a very narrow area of focus - a particular team or product or process - but the sort of changes organisations are asking for require a broad, cross-functional focus. Implementing change may require a dozen or so managers (who are already busy doing their day jobs) to collaborate. Real change becomes a logistical nightmare so you get token changes in narrowly focused areas or “I can see the point but can’t see how I can implement that here”.

There are a bunch more impediments I could list here but the key message is this - the frozen middle is not a problem with middle management. It’s a problem with the system and the system is a senior management problem. There is a lot of talk about “developing our middle managers as leaders” and suchlike to “thaw the frozen middle”. None of that will work without fixing the system. The frozen middle is a senior management problem and as such, needs to be solved by senior management.

Until senior management fixes the systems by aligning measurements and organisational structures to align with the desired change, middle management will remain stuck.

IT Lead

Most businesses are split vertically into different layers of management and also horizontally into different operational units. Every enterprise does this a bit differently but in most of them the main split is usually between “business” and “IT”.

Business groups connect directly with customers and come up with new products and features. IT groups tend to sit in the background and do… geek stuff. Now, those who have been doing agile for a while will know that one of the things agile does is to break down this artificial split, and align IT teams directly with the business. For an organisation right at the start of its agile journey though, you are more likely to see this split structure than not. When planning the transformation, one of the keys is finding where the drive for agile is coming from. Is it Business? Or is it IT? Both situations have different challenges.

If the push is from IT (which is usually the most common) your challenge will be to engage the business. Within the organisation, agile may well be seen as “an IT thing” - something that those geeks do to be more productive. It is often very difficult to bridge the gap and get business teams properly engaged.

Why would you want to engage business? Surely we can get a lot of value just concentrating on the IT side of the fence - introduce tech practices, get continuous integration and continuous delivery pipelines in place, drive down defects, get the IT teams humming. Sure, you can. But without business on board, you have no way of knowing whether all that effort is going into producing the things the business really need. You may be producing wonderful product, but product that does not meet the needs of the customers. If it’s just IT teams working in isolation, chances are they will be producing the wrong thing, and all that effort will be wasted when the product fails to meet market needs.

Yes, there will be some kind of signed off requirements spec to tell the team what to do, but how often have we seen a requirements spec that accurately captures all the business needs? Or one that captures only what is really needed, with no gold plating? Or one that keeps up to date with changing business conditions?

You really need to make sure that the business teams are along for the ride as well. A lot of the time they just keep on doing whatever they have been doing for years - signing off requirement specs etc, then handing them over to the IT groups with no collaboration. The usual symptom here is that the “product owner” will be from IT, and not from the business. They are a product owner in name only. All they can do is some basic prioritisation around which story to build first out, of the set of signed off “must have” features, that all have to be delivered in a fixed time, and at a fixed cost. Any serious conversations over minimum viable product (MVP), or whether we are building the right thing, are just not possible.

The best way to break this down is to start getting real business product owners involved. Normally there are business stakeholders identified; one of them is probably your natural product owner. Seek them out, encourage them to come on board and really own the backlog. They will probably be reluctant at first - “I’ve already given them the requirements… just deliver them” but once they see that their top priority item gets delivered to them fast, they tend to become supporters very quickly. Be strict on backlog ordering though, these guys are used to chucking a requirement spec over the fence with everything marked as “must have”. The idea of strict ordering will be difficult. I had one PO tell me it was like choosing which of his kids he liked the best. But again, when they see that the priorities they set translate directly into important stuff delivered quickly, it doesn’t take long for them to see the value.

Incidentally, it’s really, really important that the IT teams do actually start delivering. If they don’t, the business guys will never see the value of collaborating. I really can’t stress enough just how important this is. If stuff isn’t being delivered to the business regularly, and (most importantly) as promised during planning, you will not get the business on side.

Once you have a few good product owners in place, and a few good teams regularly delivering value, you can start to engage the business teams more directly. Use your supporters to build that bridge. What you are aiming for is a fully aligned organisation where work flows in small chunks, in a steady pipeline from business to IT and right to the customers.

Business Lead

If IT Lead is one direction of alignment, then the other is obviously Business Lead. This is much less common than IT lead. Agile has its origins in software development and the IT side of an organisation is usually much more aware of agile and agility as a concept than the business side, so it’s natural that the drive for agile would come from there. Business lead does happen though. The problem is that when it is business driving agility, it’s either because the business is really advanced and is actively seeking out ways to transform itself (great but not likely), or they have issues with their IT department and have heard of this thing called Agile, which apparently makes IT departments deliver stuff.

Yes, if the push is from business, it’s usually because there are delivery issues and someone in business has seen agile and sees it as a way to make the IT people deliver faster, or better, or cheaper, or some combination of all three. Even when business is asking for agile, it is still (most of the time) seen very much as an IT thing. The brief is usually “go make our IT teams agile”. Of course the IT teams just love business folks telling them how to write software, don’t they? If your business is in the “really advanced and looking for ways to transform itself” category then it’s likely your IT department is as well, and your life just got a whole lot easier. But that’s a different pattern.

Push from business can be a really awkward situation. The problems with delivery are usually very real and will have many causes. Some of which will be the IT team’s problems and some will be very squarely business problems. The IT teams may be starved of resources and talent. They may be saddled with ancient legacy systems. They may just be old-fashioned and unwilling to change (there are conservative IT people… and a lot of them work for big companies). Either way, you need to work out where the delivery problems are coming from. There will probably be multiple reasons.

Your biggest problem is unlikely to be the delivery problem though. It’s likely to be a serious “Us vs Them” culture. There will be zero trust, and possibly even zero real communication between the two sides of the business. You will need to get the two sides talking to have any chance of fixing any of their problems.

IT will generally resent this push by business to tell them how to do things. Their perception of the problems will often direct the blame to business - “if they hadn’t cut our budgets… “ or “if they would only let us fix up tech debt…”. Business will generally frame the problems as being IT’s fault - “if only they would focus on delivering what we want”. Business is also likely to resist change itself - “Agile is a dev thing… we hired you to change the devs so go do that and leave us alone. We’re fine”. This is another case where you may need to spend more time educating your supporters that you do educating your detractors.

The best way to tackle this is as a problem-solving exercise. List the delivery problems. Get both business and IT into a room to discuss them. Map out a value stream together. Find the pain points. It will soon become clear that to fix any of these problems will need buy-in from both sides.

Prioritise the problems with business and IT. Pick the most important one you can solve quickly and work with both sides to solve it. Build trust and, even more importantly, build alignment. Get both side working towards a common goal.

If you can get the organisation to agree on a set of outcomes and work together to reach them, you have reached the holy grail of alignment patterns - the aligned organisation.

Fully Aligned

In discussing the other alignment patterns, I made mention of a wondrous state that could be achieved where the whole organisation shares the same goals and is working together towards a common goal. Welcome to the Fully Aligned pattern.

This is the end goal for any enterprise agile adoption. This is the pattern that will really let you grow agile within the organisation and firmly embed it into the culture. This isn’t just a desirable end state though. In my experience this is a necessary end state if agile is to thrive and become part of the organisational culture. Without full alignment, agile tends to wither away to a sort of agile-ish (or fragile) set of practices that are followed without really understanding why, and more importantly without really delivering real business benefit. If agile is to deliver real benefits at the enterprise level, you need to achieve alignment.

Before you run screaming at the thought of getting all however-many tens of thousands of people in your organisation all aligned (which sounds like an impossibly daunting task) you will be relieved to know that you don’t have to get alignment across the whole organisation to be successful. The key here is that big organisations aren’t really one organisation. If you look closely at them, they are a collection of multiple, smaller businesses under a common banner. Each of those separate business will have its own leadership, its own culture, its own challenges.

The trick here is that these sub-units may or may not correspond to the organisation’s official organisational structure. What you need to find are the value streams.

These value streams may align to the organisational structure. Some large organisations are broken up into vertical markets where that organisational structure is responsible for everything to do with delivering into that market segment. More often though, value streams cut across the organisational boundaries. To deliver a product release, you may require resources from a frontline business unit that deals with customers, plus resources from an IT delivery business unit and a production support business unit and so on. Organisational structures are typically organised vertically around job specialties or technical competencies, while value streams tend to cut horizontally across multiple business units.

What you are aiming for is alignment across a value stream, or set of related value streams. This is the smallest subset of a large organisation where you can make a real, sustainable change. An optimisation of a value stream will make a measurable difference to the organisation’s bottom line. Optimising only part of a value stream won’t, or may even have a negative impact, as this results in sub-optimisation - the part you optimise will run better but often at the expense of other parts of the stream, which then eat up all the benefits (and often more).

The biggest problem you will find is that unless an organisation is already thinking in terms of value streams (in which case they probably don’t need you), the organisation’s value streams will be tangled. Many streams will all intersect at some shared service team, get hopelessly muddled, then branch out into another set of streams which will then converge and intersect and so on. This makes untangling a single value stream extremely difficult without a lot of re-organisation, which your current level of organisational alignment may not support.

In this case, do the best you can. You may need to find a set of streams that can be untangled together or, if things are a real mess, zoom further out until you can see a logical separation that you can work with. Often this is at the business unit level. Important - if you zoom up to the business unit level, you need to make sure your business unit is customer facing. It needs to be a real business unit not an internal one. Often the most obvious place to start is the IT business unit but here, you have every value stream in the company coming together in one huge knot. Untangling that means untangling the whole company. Choose a customer facing business unit and it will allow you to split off a small subset of their IT mess rather than tackle the whole thing at once.

As your level of alignment improves, and you can start having conversations about restructuring, you can start to untangle the mess and zoom back in again.

So, first find your value stream, or stream of streams depending on how the organisartion is set up. Now you need to see how it’s aligned. Is it all contained within one element of the organisational structure (in which case your life just got a lot easier), or does it cut right across (in which case your life just got harder)? As soon as you start to cut across organisational elements, you start to run into organisational politics. Take a look at the existing alignment patterns. Is the value stream alignment top down or bottom up? Is it IT or business lead? That will determine your initial engagement and how far that engagement can go. What you need to do now is start to improve the alignment until you get the whole stream aligned.

By working along value streams, you get alignment more easily than working within regular organisational structures. The reason is that most business units do multiple things - the IT business unit will have teams servicing dozens of different parts of the business, all with different goals. Aligning that will be a huge mess. However, a value stream is already aligned around getting stuff done. That gives you an existing common focus to work with. Everything can be pitched around improving progress towards their goal. The difficulty, of course, is that most organisations don’t recognise what their value streams are, so they will need to be educated. You will also run into a lot of empire protecting - if a team is now seen as part of a value stream, and is managed as part of a value stream, it may loosen a manager’s hold over that part of their corporate empire, so be prepared to deal with that resistance.

Once you have aligned one value stream, build out to the adjoining ones. Build off the initial success and align the whole organisation stream by stream. You will find that different value streams have different alignments; for example your first stream may have been aligned bottom up, but your success with that one gets noticed by senior leaders in other streams, which results in a top down pattern in the next one.

You won’t be able to do this on your own. Big enterprises are a lot of work. You will need a team to help you. In each value stream you will need to build a team of champions to take some of the load and make sure things keep running when you are elsewhere.