BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Requirements Come Second - What Comes First?

Requirements Come Second - What Comes First?

This item in japanese

Bookmarks

Allan Kelly has published Requirements Come Second in this month's issue of the Agile Journal.  In this article he sites Avoiding the Alignment Trap in the Fall 2007 issue of the MIT Sloan Management Review which basically states that IT companies fail miserably when they focus on business-IT alignment before getting their ducks in a row and becoming technically competent. 

Allan starts by saying there are typically two major attributes of problem solving: doing things right (technical ability) and doing the right thing (understanding the problems correctly).  He states:

During management training many managers are taught the importance of doing the right thing over doing things right. This is good advice but in the case of problematic IT groups could make the situation worse.

He then brings in data from Avoiding the Alignment Trap:

Research from Bain & Company[2] shows that a staggering 76% of all IT organizations are neither effective in what they do nor aligned with the business needs. We can think of these two criteria as "doing things right" and "doing the right thing."

Allan then says that, traditionally, Agile software development has really focused on "doing things right":

Traditionally Agile improves the effectiveness of development teams. While Agile doesn't ignore requirements the thrust of most Agile processes is to improve effectiveness. Successfully improving effectiveness would allow a team to move from "maintenance zone" to Bain's "well oiled" quadrant. By being more effective companies do things right but don't necessarily do the right thing.

Still, the returns for "well oiled" IT are impressive. The 8% of companies in this category demonstrate below IT spending 15% below average while sales grew at 11% per annum.

This is one way of explaining why we've been so successful as a community and (possibly) why now the focus is on "what next?" and there is talk about The Whole Enchilada. The Agile community has done well in "doing things right" and now is focusing on "doing the right thing".  The arguments about doing everything, and forcing business alignment to come hand-in-hand with "well oiled" IT is an interesting proposition.

Allan then shows us the alignment trap:

But what about requirements? Moving to "well oiled" doesn't address the need to produce what the business wants. What if, instead, we followed the managers' instinct? What if we improved alignment and focused on doing the right thing before doing things right? Wouldn't this be better still?

The answer is No. Bain label this group of companies "alignment trap". While they are more aligned to business need their effectiveness is still poor. These companies see higher IT spending, up by 13%, and more worryingly sales falling faster, 14% per annum than the "maintenance zone" companies. It turns out that doing the right thing poorly is a terrible place to be. This 11% of companies are in the worst place possible.

This is different way to look at the current situation in the Agile community as we decide where to go next. Allan's summary makes a good ending to this news post:

So the message is clear: The first step in Agile adoption must be the fix the delivery machine. Improve the effectiveness of the development group.

As effectiveness improves focus can switch from how to what. The changes required here are if anything more far reaching. They are also more long-lasting.

To date Agile methods have had relatively little to say about requirements and business alignment. The current crop of Agile methods largely focuses on development and project management practices. As more companies adopt Agile - and become well oiled - we should expect to see a renewed focus on requirements discovery and business alignment.

Rate this Article

Adoption
Style

BT