Flexibility and changing requirements

["Lisa Wright" <liwright -at- earthlink -dot- net>]

Barry Kieffer wrote:

>I seem to remember being in a seminar led by JoAnne Hackos when she
brought up this very scenario. She was explaining the concept of
creeping scope and how it affects documentation plans. It was something
like this:

Looking at a house plan is like looking at a documentation plan - many
people cannot understand what is going to be delivered until they see it
start to take shape. Now that they see it taking shape they say: "Hey
Ms. Contractor, I would like the kitchen larger, can you move that load
bearing wall over a few feet - how much time and how hard can that be?"

*************************
This is a valid, if somewhat extreme, analogy. (Yes, I suppose there are
scenarios where a requested document change is as proportionally drastic
as moving a load bearing wall. But it's hardly the run-of-the-mill
situation.)

This is the whole idea behind XP programming--you design as you go.
You're flexible. You don't invest a lot in developing things that are
miles down the road. You deal with the here and now. You plan for short
iterations of a product based on known requirements. Actually, you're
not even supposed to deal with ALL the known requirements, though that
one's a struggle. "Just ignore the 2-ton elephant in the corner. He
doesn't get involved until *much* later!"

The key part is that you are highly flexible. Hackos is right: people
often don't know what they want until they begin to see it take shape.
So instead of running them through the "you didn't stick to our process"
mill, you have a process where change is a natural, expected,
encouraged, nay, critical part of the process that enables you to get
the best product with very high customer satisfaction.

I apply this approach in my own writing, though it's hardly formalized.
It lets me respond quickly to new features and functions, to the
tweaking and refining that the developers always do, to last minute
customer requests. I very much recommend reading up on XP just to get a
sense of the dynamic involved. There are several books, including
"Extreme Programming Explained." Despite it's very flexible nature, it
is a structured process full of planning and checkpoints, so everybody
can be happy.

By the way, this approach is being used outside of software. When they
built Invesco Field at Mile High Stadium in Denver, the general
contractor decided to use a "design-as-you-go" approach, and they got
some of the most interesting features of the stadium by including ideas
that developed after they broke ground. They completed it almost a year
earlier than they would have if they'd had to do all the planning up
front, and it's been extremely well received by both the football team
and the fans.

Lisa


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you 
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of 
your book. What are you waiting for? http://www.iuniverse.com/media/techwr

Have you looked at the new content on TECHWR-L lately?
See http://www.raycomm.com/techwhirl/ and check it out.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.