My article, Requirements Come Second , in a recent issue of Agile Journal caused something of a fuss. The piece was picked up by several more sites and was widely commented on - both on websites an in my inbox. I'm not entirely surprised by this reaction, I've been discussing this research for a year or so now and often find it surprises people. Given this level of interest it is worth looking at how people responded.
It is also worth restating the key message: Requirements are an essential part of maximising business value, but when an organization is struggling with effectiveness it is best to start change by improving delivery.
The responses were often in agreement with the research. Several people reported that it explained what they had seen personally when organizations adopted Agile methods. However there were some voices raised in disagreement and it is interesting to look at these in more detail.
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