Oct
15
Ab Initio Development
October 15, 2005 |
I was re-reading an older book on patterns that I happen to have (Patterns of Software, by Richard P. Gabriel) this morning. While working through the first essay, he said some things that really reminded me why Agile methods are problematic in the business settings in which I work.
The core problem, the one that Agile (and most iterative approaches) waves away, is not Big Design but Big Implementation. You can’t start small, and build, and build, and deliver value to the users because the value is exactly zero until the whole thing is in place and they’re able to shut down the old. Until that transition point is reached, until what you’re constructing better than what is currently there, there’s nothing to give the user and you can’t ask them to use it and give you feedback, at least not in a consistent fashion.
When there’s no system, when you’re building something totally new, then it can be a lot easier. To make a comparison, let’s say you’re building a word processor. Most Agile methods start as if you’re working with a user who currently writes everything out in longhand. So, for a first iteration I could just have something that lets me type out information and then print it off. Save? Hey, you mean I could change a document after starting it rather than write it out from scratch again? Cool! OK, let’s do that. Fonts? Wow! …and so on. From the perspective of a person with nothing, each feature adds to the value of the end product.
A business app, on the other hand, is more like designing a word processor for someone who’s used Microsoft Word 95 for the last decade, and needs you to support 90% of what it does while adding new features. They’ve got 10 years of files that need to be readable by the new application. They’ve got a bunch of macros that they want to see integrated as core functions. Mail merge has to work. They want to be able to cut and paste from a bunch of different office applications–and all of these things have to work before they can stop using Word 95.
This is, I think, where much of the disconnect between developers and business users occurs–because the developers try to get the business users to set differing priorities on features that the business users view as minimal satisfiers. When developing ab initio, that’s easily done–but it’s hard when you have to replace something that already works.
Comments
What I'm Reading- Agile Requirements Information Model (4) – Subset For Agile Programs (a): Features and Feature BacklogScaling Software Agility
- The Great Implication of Context-Driven MethodologyJames Bach's Blog
- User stories versus Use CasesBusiness Analyst Blog
- Can Use Cases Possibly be Agile?Agile Product Owner (.com)
- A little bit of levity for the holidays from iRiseThe iRise Blog
- The end of reposiphilia?The Forrester Blog For Technology Product Management & Marketing Professionals
- IT ethics and the recessionIT Project Failures
- Risk Assessment ModelingEDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology
- Test Requirements, Don't Test CodeHerding Cats
- Enterprise architecture is optionalBizRules Blog