possible to have good conversations about what to do. Organizations that cannot deliver spend a lot of their time agonising about their inability to deliver. The narrower the delivery pipe, the hard it is it to decide what to deliver.
The Bain research offers another explanation, and again it is one that fits with the Agile agenda: the loss of effectiveness is in part due to complexity. Keeping IT departments effective means controlling complexity. Improving alignment alone does nothing to improve effectiveness.
Once complexity is managed, once organisation can deliver then it is time to tackle alignment. Its a question of timing.
Do both together
Some respondents asked why an organization couldn't move diagonally, from the maintenance quadrant to the growth quadrant in one bound. As attractive as this idea is there are several reasons to take the longer route.
Tackling effectiveness then alignment allows management and staff to focus on one issue at a time. Rather than spread available time and resources thinly it is better to achieve one thing at a time.
Attempting both changes at once will increase the risk of change as well. Should the team succeed in increasing alignment but fail to bring about the necessary effectiveness improvements the group would move themselves into the alignment trap, the worst place to be. Sequencing the change remove this risk entirely.
My experience suggest one reoccurring causes of the alignment trap is a breakdown of trust. When IT departments fail to deliver on business needs the business responds by demanding the next project is bigger, better and faster than the previous one because they don't trust IT to deliver. At some level the hope is that by asking for a lot more they will get a little bit more.
The IT department responds promising less and erring on the side of caution. Estimates are increased, time and cost budgets padded.
The result is an arms-race and a breakdown in trust. It is no longer possible to have a constructive dialogue between the two groups.
When IT acts to put its own house in order first, adopts Agile and moves itself from the maintenance zone to well-oiled zone it demonstrates it can deliver. As the delivery record improves trust is rebuilt, dialog improves and it is easier to fix alignment.
My method already does this
Another response has been to claim that Agile method X already bridges this divide. The claim may hold for some methods for the most popular Agile methods, XP and Scrum, the claim does not stand up to analysis.
XP is very delivery focused and deals with requirements by an onsite-customer. XP is based on the belief that the customer will know what to do. The method itself says nothing how the customer knows what needs doing or what methods they use. There is no equivalent of TDD for customers.
The XP customer provides both the requirements and is the subject matter expert. There is no space here for a longer term or strategic business view. Simply being the user of a system is not enough to meet business needs.
The Product Owner role in Scrum is an improvement on XP. But Scrum says nothing about how the role is to be performed beyond the Scrum process. There is nothing wrong with this, neither does Scrum say anything about developers using continuous integration or refactoring.
Scrum, rightly, has a well defined limit on practices. It so happens that ensuring business alignment falls outside this limit. Were Scrum to include the necessary practices the method would balloon in size.
Not all Agile methods are Scrum