Horizontal Alignment

So far we have looked at the vertical component of organisational alignment - which level of the business is pushing for change. Today we will look at the other dimension. 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 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.

Sure, 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 - signed 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 at a fixed cost. Any serious conversations over 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, its 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.

We'll look more at what an aligned organisation looks like and how to get there in a couple of weeks, but next we'll take a look at what happens when the push for agile comes from the other direction - from business.