Page 192 -

Chapter 6 • agile Modeling and prototyping 159

CONSULTING OPPORTUNITY 6.3

To Hatch a Fish

“Just be a little patient. I think we need to add a few more fea- Wally chimes in, “Yeah. Why point out our mistakes to
tures before we turn it over to them. Otherwise, this whole proto- everyone? Besides, when they see the prototype, they’ll forget
type will sink, not swim,” says Sam Monroe, a member of your any complaints they had. They’ll love it.”
systems analysis team. All four members of the team are sitting Belle finds a memo in her notebook from their last meet-
together in a hurriedly called meeting, and they are discussing the ing with the hatchery managers and reads it aloud. “Agenda
prototype that they are developing for an information system to for meeting of September 22. ’Prototyping—the importance of
help managers monitor and control water temperature, number of rapid development, putting together the user analyst team, get-
fish released, and other factors at a large, commercial fish hatchery. ting quick feedback for modification. . . .’” Belle’s voice trails
“They’ve got plenty to do already. Why, the system began off, omitting the last few agenda items. In the wake of her com-
with four features and we’re already up to nine. I feel like we’re ments, Monroe and Wally look unhappily at each other.
swimming upstream on this one. They don’t need all that. They Monroe speaks first: “I guess we did try to get everyone
don’t even want it,” argues Belle Uga, a second member of the primed for receiving a prototype quickly and to be involved
systems analysis team. “I don’t mean to carp, but just give them the from day one.” Noting your silence up until now, Monroe
basics. We’ve got enough to tackle as it is.” continues, “But still waters run deep. What do you think we
“I think Monroe is more on target,” volunteers Wally Ide, a should do next?” he asks you.
third member of the team, baiting Belle a little. “We have to show As the fourth member of the systems analysis team, what
them our very best, even if it means being a few weeks later in actions do you think should be taken? In a one- or two-paragraph
hatching our prototype than we promised.” email message to your teammates, answer the following ques-
“Okay,” Belle says warily, “but I want the two of you to tell tions: Should more features be added to the hatchery system
the managers at the hatchery why we aren’t delivering the proto- prototype before giving it to the hatchery managers to experi-
type. I don’t want to. And I’m not sure they’ll let you off the hook ment with? How important is the rapid development of the pro-
that easily.” totype? What are the trade-offs involved in adding more features
Monroe replies, “Well, I guess we could, but we probably to the prototype versus getting a more basic prototype to the
shouldn’t make a big deal out of being later than we wanted. I client when it was promised? Complete your message with a
don’t want to rock the boat.” recommendation.

possess the self-confidence to allow their customers to question, critique, and sometimes com-
plain about the system under development. Analysts learn from their customers, who have been
in business a long time.
THE BASIC PRINCIPLES OF AGILE MODELING. In a perfect world, customers and a software
development team would see eye to eye, and communication would not be necessary. We would
all be in agreement at all times. But we know that the ideal world doesn’t exist. So how can we
bring our software development projects closer to the ideal? Part of why this will not happen is
that so far we are trying to operate on a vague system of shared values. They’re a good beginning,
but they are really not operationalized to the point at which we can measure our success in any
meaningful way. So we work to derive the basic principles that can help us check whether what
we are doing in our software project is actually measuring up to the values that we share.
Agile principles are the reflections and specifications of agile values. They serve as guide-
lines for developers to follow when developing systems. They also serve to set agile methodolo-
gies apart from the more traditional plan-driven methodologies such as SDLC as well as object-
oriented methodologies.
Agile principles were first described by Beck and have evolved ever since. These principles
can be expressed in a series of sayings such as:
1. Satisfy the customer through delivery of working software.
2. Embrace change, even if introduced late in development.
3. Continue to deliver functioning software incrementally and frequently.
4. Encourage customers and analysts to work together daily.
5. Trust motivated individuals to get the job done.