Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Requirements Come Second - What Comes First?

Requirements Come Second - What Comes First?

This item in japanese


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


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Doing the wrong things doesn't help

    by Lionell Griffith,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Doing the "The Whole Enchilada" is likely the worst, worst thing you can do.

    What you must do to achieve good results is very dependent upon the results you must achieve. There is no such thing as a universal solution for all problems nor a universal best way to solve them - ie no Silver Bullet. Its as simple as, if you don't know what must be achieved, you can't know the right things to do nor the right way to do them.

    Its the right problem, correctly identified, and clearly understood in context that is the starting point. Without that, you are doing nothing but thrashing about and spouting bullshit. Maybe that is the best you can do. If so, admit it rather than pretending. You really don't know what you are doing.

  • Re: Doing the wrong things doesn't help

    by Amr Elssamadisy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Its the right problem, correctly identified, and clearly understood in context that is the starting point.

    That is, in fact, what our intuition tells us. The numbers tell a different story. If you start working on 'getting the right problem' without the technical capability, you end up paying more and doing less. The original article from the Sloan Management Review is quite specific about this.

    IMHO I don't think 'getting the right problem' is a binary decision and although we may not be completely aligned with Business at times, we are rarely clueless.

  • Re: Doing the wrong things doesn't help

    by Lionell Griffith,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If you don't have the right problem, correctly identified, and clearly understood in context, you are not at the starting point. You are still back in the barn mucking out stalls. You have a lot of work to do before you can start. In fact, you don't even know which horse you are going to ride (ie you can't know what technical capability will be needed). The most you can do is guess.

    Doing development by guess by golly accident is not very effective at solving the real problem. Especially when you don't know what the real problem actually is. You might accidentally stumble onto it but could you recognize it if you did?

    Its much too early to apply any particular "The Whole Enchilada" except perhaps the scientific method. The scientific method is a truck load of whole enchiladas from which all "Whole Enchiladas" that work are derived.

    The reason the numbers are so bad, the fundamentals were not addressed in any coherent and rigorous way - ie by the scientific method. A particular "Whole Enchilada" was used without concern with it actually being applicable to the problem or context at hand. It was largely a religious exercise of following prescribed dogma. This simply does not work except by accident.

  • Re: Doing the wrong things doesn't help

    by allan kelly,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Basically I agree with Lionell, you have to know what your doing.

    But, in the context of the Sloan piece, and the in which I wrote the Agile Journal piece is different.

    The starting point is not a blank sheet of paper, the starting point is a dysfunctional IT group and you want to fix it. The group is doing something and the options are to either to improve what they do, or how they do it. Which do you do first? - do it right, or do the right thing?

    In the long term requirements are more important than ever (as I say in my article) but in the short term, when you are fixing things the first thing to fix is how things are done.

    Another way of thinking about this is from the iterative view. You start with a general goal, e.g. "build a payroll system" and rather than get into the details you build an effective team to tackle that problem. Over time the team will zero in on the details.

  • Re: Doing the wrong things doesn't help

    by Lionell Griffith,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I always vote for doing the right thing. Then and only then, focus on doing it right. Most likely by incremental improvement. Doing the wrong things superbly well does not help. It doesn't even help you discover the right thing to do. It simply burns time and effort and keeps your focus off of what you really need to do.

    This is true even for an dysfunctional (aka incompetent) team. However, if your team is in fact incompetent, you are hosed before you start mucking the stalls. They would have a hard time finding the stalls let alone know how to muck them.

    As I have said in other contexts, if you want to evolve a Cindy Crawford (or your super model choice) at least start with the same specie and not an alligator. An incompetent team is that alligator.

  • Re: Doing the wrong things doesn't help

    by Justin Arbuckle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    An interesting collection of metaphors Lionell. Indeed, If you don't know where you're going...any road will get you there.

    Perhaps I am missing the point here, but alignment evolves, as does elegance in design, through iteration. You know you have an incompetent team if that does not occur. It's like Jazz, you know it when you see it.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p