Page 191 -

158 part 2 • inforMation requireMents analysis

Figure 6.4
Values are crucial to the agile Simplicity
Communication Agile
approach.
Values
Feedback
Courage

Typical agile practices such as pair programming (where two programmers collaborate,
described later in the chapter), tasks estimation, and unit testing rely heavily on good communi-
cation. Problems are fixed rapidly, holes are closed, and weak thinking is quickly strengthened
through interaction with others on the team.
A second value of the agile approach is simplicity. When we are working on a software
development project, our first inclination is to become overwhelmed with the complexity and
bigness of the task. However, you cannot run until you know how to walk, nor walk until you
know how to stand. Simplicity for software development means beginning with the simplest pos-
sible thing we can do.
The agile value simplicity asks us to do the simplest thing today, with the understanding
that it might have to be changed a little tomorrow. This requires a clear focus on the goals of the
project and really is a basic value.
Feedback is the third basic value that is important when taking an extreme programming
approach. When you think of feedback in this context, it is good to consider that feedback is
wrapped up with the concept of time. Good, concrete feedback that is useful to the programmer,
analyst, and customer can occur within seconds, minutes, days, weeks, or months, depending
on what is needed, who is communicating, and what will be done with the feedback. A fellow
programmer may hand you a test case that breaks the code you wrote only hours before, but that
feedback is almost priceless in terms of being able to change what is not working before it is
accepted and further embedded in the system.
Feedback occurs when customers create functional tests for all the stories that programmers
have subsequently implemented. (See more on user stories later in this chapter.) Critical feed-
back about the schedule comes from customers who compare the goal of the plan to the progress
that has been made. Feedback helps programmers make adjustments and lets the business start
experiencing very early on what the new system will be like once it is fully functional.
Courage is the fourth value in agile programming. Courage has to do with the level of trust
and comfort that must exist in a development team. It means not being afraid to throw out an
afternoon or a day of programming and begin again if all is not right. It means being able to stay
in touch with one’s instincts (and test results) concerning what is working and what is not.
Courage also means responding to concrete feedback, acting on your teammates’ hunches
when they believe that they have a simpler, better way to accomplish a goal. Courage is a high-
risk, high-reward value that encourages experimentation that can take the team to its goal more
rapidly, in an innovative way. Courage means that you and your teammates trust each other and
your customers enough to act in ways that will continuously improve what is being done on
the project, even if they require throwing out code, rethinking solutions, or further simplifying
approaches. Courage also implies that you, as a systems analyst, eagerly apply the practices of
the agile approach.
Analysts can best reflect all four values through an attitude of humility. Historically, com-
puter software was developed by experts who often thought they knew how to run a business
better than the local customers who were the true domain experts. Computer experts were often
referred to as “gurus.” Some of the gurus displayed large egos and insisted on their infallibility,
even when customers did not believe it. Many gurus lacked the virtue of humility.
However, maintaining a humble attitude during systems development is critical. You must
continually embrace the idea that if the user is expressing a difficulty, then that difficulty must
be addressed. It cannot be ignored. Agile modelers are systems analysts who make sugges-
tions, voice opinions, but never insist that they are right 100 percent of the time. Agile modelers