Greg Vaughn's Blog

Business Archives

Mission Impossible: Requirements

Mr. Big Shot at AverageCorp has just given a four sentence vision statement of a new software project. Your mission, if you choose to accept it, is to understand what in the world he's talking about and make him happy with the resulting software.

This blog entry will self destruct in 30 seconds....

This entry is a follow-up to my Fundamental Problem with Extreme Programming, the great comments it generated, and Philip Brittan's XP, User Champions, and Software Vendors. It's great seeing the conversations flow. It helps me to refine my own ideas as I get feedback from a larger group than just the folks I meet in person. I've also recently read a free requirements chapter of Christopher Duncan's book, The Career Programmer which I've just added to my reading list.

Like Philip, I have been in a situation with a self-appointed project champion who knew the business and was extremely interested in software. It was great to develop on that project for a while, but things went south very quickly when she started throwing around political clout she didn't really have and ended up leaving the company. Be aware of the failure mode of this approach. We became scapegoats when she left even though we'd done everything she asked of us.

I've known very few software projects that fail due to technical reasons. It's almost always political. It is usually an issue of either not understanding the business needs, or writing the software to please the wrong person(s). Because of this, focusing on optimizing the efficiency of the pure development effort, like XP, doesn't really help the underlying issue. Those of us typically introverted, logic-ruled developer types are going to have to determine to learn something about corporate politics. Yes, I actually believe that though I do not relish it.

What this means is that we're going to have to identify the head person that needs to be happy with the software, get some high level of understanding of what it'll take to do that, plus get him to delegate the details to someone or some group that we'll spend a lot more time with to wring out the details. Convincing him to spend his business people's time on this is going to require something akin to espionage. We've got to get inside his head and figure out how to present things in such a way that they further his individual goals. Also, keep in mind that his personal goals may not always be in line with just improving the corporation's bottom line (the logical position we techies like to argue from). In some cases, he'd get more political clout by having control of a bigger budget. We've got to learn what motivates him and adjust our approach based upon this knowledge

I'm not advocating dishonesty, but we techies need to step out of our navel-gazing tech-only mode and learn something about those topics that we typically say with a sneer on our face or while rolling our eyes -- politics, marketing, business processes, chain of command, etc. This is going to vary from project to project, and therefore a one-size-fits-all, the true cost of requirements are in your face, approach of XP doesn't work. It can work in the rare case you've got a project sponsor who's open to it, but your toolbox needs to have more options available to you.

I also have the feeling that demonstrating to the business sponsors that we know what they want politically in addition to the software technicalities, and learning to speak their language can also help with the issue of having our jobs outsourced. The real issue of requirements is figuring out what it'll take to please the person in the right political position. Enterprise software is never developed in a political vacuum, and we can either choose to accept that fact and work within its framework, or continue in our frustration and gripe amongst ourselves at how things should be done.

Fundamental Problem with Extreme Programming

XP requires too much of an investment from the business. Even aside from the obvious on-site customer that XP requires (and Mr. Stephens makes a good case that the best you'll get is a junior person) there's the regular unfinished (and unpolished?) versions of the software they're expected to use and give feedback about in the Planning Game every few weeks. There's also the ideal of the business users working to develop the acceptance tests.

It's like watching sausage being made. Business users are not techies, and generally don't want to become techies. They want the software, and they want it with a minimum of their effort. The overall development efficiency that XP is built around actually decreases the business users' efficiency in doing their own job during the development. They find it tiring to think like a techie and answer all the detailed questions about how various requirements interact and handling all sorts of 'what if' scenarios.

Please, don't misunderstand me, gentle reader. I do respect XP. It has served as the spark that got people (me included) thinking more about Agile methods in general (though the ideas go back much further than that). I've written in more detail about why I choose to associate myself with the Agile movement rather than XP before. The gist of which is best explained by comparing XP to Free Software (FS) and Agility to Open Source Software (OSS). XP/FS adhere to uncompromising purity of their ideal. Agility/OSS agree with those ideals, but realize compromises must be made in the name of practicality. XP/FS have actually become special cases of the broader Agility/OSS categories.

I guess I'm just a practical sort of guy.

This work is licensed under a Creative Commons License.