Business Lead
Last time we looked at one horizontal alignment direction - IT lead; today we'll look at the other - 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 is natural that the drive for agile would come from there. Business lead does happen though. The problem is that when it's 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 guys 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.
This 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 guys... and a lot of them work for big companies). Whatever the cause, you need to work out where the delivery problems are coming from. There will 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 go 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. We'll look in more detail at this elusive and mysterious beast next time.