Recap - the alignment trap
Research form Bain consulting suggests that in three-quarters of companies IT is neither aligned with business or effective at what it does. They suggest that companies that attempt to resolve this by first focusing on alignment, make the situation worse. IT costs increase while sales fall.
Conversely, by taking the slightly counter intuitive course of improving effectiveness before improving alignment then IT costs fall and sales increase. If the company then goes on to improve alignment then sales rocket (35% above average) while IT costs remain below average.
Bain have nothing to say about Agile but it isn't difficult to see how this phenomenon relates to Agile adoption. Because Agile methods concentrate on effectiveness they help the company improve delivery do little to improve alignment with the business.
Questioning the research
One group of respondents don't accept the research. As with any research there are genuine reasons to question it. One shouldn't take research on face value and a good many people went and read the original research.
While the research did not specifically consider software development it is clear development activity was included in the work. Neither did the research did not specifically consider Agile or any other method. It simply considered less effective and more effective IT departments. Still the research fits well with the current understanding of Agile and anecdotal evidence.
One correspondent pointed out that little is said about how alignment was measured or defined. And of course it is always possible to question the technical basis of research or ask for a larger sample size. Still, with these caveats considered the research seems to hold up.
It is also true that alignment is not just about requirements. Aligning IT with the business needs more than just defining the right things to build, it must also involve priorities, resource allocation and outcomes among other things.
This can't possibly be right
Another reoccurring reaction can be summarised as "This can't possibly be right, how could it make sense to do the wrong thing?"
Nobody is suggested companies deliberately do the wrong thing. If you have an IT group maintaining a payroll system then it is reasonable to assume that the developers will be fixing bugs and enhancing the payroll system and not developing a new version of Grand Theft Auto.
Poor alignment occurs not because the team are heading in the opposite direction, rather alignment is poor because the team are not heading in completely the right direction either.
By maintaining the current payroll system this team may simply be prolonging the life of a system the company has decided to outsource. Therefore while their effort is not damaging the company neither is aligned with the company objectives.
Secondly one needs to consider the context of the research, namely, alignment is being considered in comparison with effectiveness. If your organization is experiencing problems - and the chances are it is simply because 74% of companies do - then it is faced with the question of which to improve first: effectiveness or alignment?
The insight from the research is not that it is not wrong to improve alignment, rather, when effectiveness is poor it can be harmful to focus on alignment first.
This fits with my own experience: when delivery is ineffective it is not 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 and XP. Evo, for example, does consider requirements in more depth but few teams use Evo. On the whole the requirements side of the equation is absent from the popular Agile practices.
There is work, good work, on the requirements discovery process from people like Chris Matts, Luke Hohmann, Mike Cohn and even a little from myself. Several comments on the February's piece pointed to this work.
The important thing here is that this work falls outside the mainstream Agile methods; too many teams that have adopted Agile have deficient requirements processes.
Requirements more important than ever
The truth, as usual, is more complicated than it first appears. Some people have interpreted "Requirements Come Second" as a call to ignore requirements. In fact the opposite is the case: business alignment is more important than ever.
Consider a company that is initially stuck in the maintenance zone with falling sales. They adopt Agile and their sales improve by 13% on Bain's figures. Agile has done a great job!
Now if they can stay effective and get aligned sales will improve by 24% more. Being aligned with good requirements has real benefit. Ultimately it generates more value than simply becoming effective alone.
Achieving alignment
While many companies will continue to struggle with IT some will, by adopting Agile and other techniques, succeed in creating effective IT groups. Of these some will take the next challenge and improve the alignment with business need and strategy.
Managers need to lay the foundations of improved alignment even as they start the Agile transition while taking care to avoid the alignment trap. Its as if the first runner in the relay race has started and the second must be ready to pick up the baton. This means building a corps of skilled Product Owners.
We need to move beyond talking about the Product Owner in terms of the Agile cycle. Backlog management, user stories and such is all-necessary but does not go far enough, there is much more to being a Product Owner than is commonly recognised.
Product Owners need to look deeper into the application domain, understand users and the business, then have the vision to create roadmaps. However the skills needed differ depending on nature of the organization.
In companies that create software products - ISVs and others who generate revenue from the sale of software to multiple customers - the Product Owner roles need to be staffed by Product Managers.
Conversely, in corporate IT departments and service providers - companies which create software for their own use or for the use by a single client - the same role needs to be staffed by Business Analysts.
The Product Owner role is actually two different roles that present the same interface to an Agile process. Correctly staffing the Product Owner role to match corporate need is the first step in aligning Agile teams with business needs.
Links
Original Agile Journal article, Requirements Come Second
Further reading
Original publication in "Avoiding the Alignment Trap" in MIT Sloan Management Review, October 2007.
User Stories Applied, Mike Cohn, 2004, Addison-Wesley
Innovation Games, Luke Hohmann , 2006, Addison-Wesley
About the Author
Allan Kelly is a London-based consultant and interim manager specializing in Agile adoption. His first book, Changing Software Development: Learning to be Agile was recently published by John Wiley and Sons. He is a qualified Product Manager and Project Manager, and holds a BSc in computing and an MBA in management.
