Page 201 -

168 part 2 • inforMation requireMents analysis

The fourth lesson we take from the agile approach is that the 40-hour workweek improves
effectiveness. Even the hardest-hitting developers are susceptible to errors and burnout if they
work too hard for too long a period. When the development team is together, however, every
moment counts. Working at a sustainable pace is much more desirable for the life of the proj-
ect, the life of the system, and the life of the developer! We all know the parable of the hare and
the tortoise.
The fifth lesson we draw from taking the agile approach is that balanced resources and activ-
ities support project goals. Managing a project doesn’t mean simply getting all resources and
tasks together. It also means that the analyst is faced with a number of trade-offs. Sometimes cost
may be predetermined, at other junctures time may be the most important factor. The resource
control variables of time, cost, quality, and scope need to be properly balanced with the activities
of coding, designing, testing, and listening.
The last lesson we take from agile modeling approaches is that agile values are crucial to
success. It is essential to the overall success of the project that analysts wholeheartedly embrace
the values of communication, simplicity, feedback, and courage in all the work that they do. This
type of personal and team commitment enables the analyst to succeed where others, who possess
similar technical competencies but who lack values, will fail. True dedication to these values is
fundamental to successful development.

Comparing Agile Modeling and Structured Methods
As you have seen, agile methods are developed quickly, they reportedly work, and users are
customers who are directly involved. While it is true that projects developed by using agile
methods often require tweaking to work properly, agile developers admit that tweaking is
part of the process. The agile approach implies many short releases, with features added
along the way.

Improving Efficiency in Knowledge Work: SDLC Versus Agile
Researchers Davis and Naumann (1999) developed a list of seven strategies that can improve
the efficiency of knowledge work: reducing interface time and errors, reducing process learn-
ing time and dual processing losses, reducing time and effort to structure tasks and format
outputs, reducing nonproductive expansion of work, reducing data and knowledge search
and storage time and costs, reducing communication and coordination time and costs, and
reducing losses from human information overload. These researchers believe this is impor-
tant because, based on their study of a group of programmers, they claim that the best pro-
grammers are 5 to 10 times more productive than the worst ones. They further point out this
ratio is only 2:1 for workers in clerical or physical tasks. Their suggestion is that software can
help improve many situations.
We use the standard, traditional systems development approach of structured methods to
compare and contrast how structured approaches versus agile methods would implement the
seven strategies proposed to improve the efficiency of knowledge workers.
While adopting more software may indeed improve performance, it is reasonable to suggest
that changing an approach or a methodology may also improve performance. Consequently, we
will examine each aspect of knowledge work productivity through lenses from both structured
and agile methodologies. Figure 6.8 lists the original seven strategies for productivity improve-
ment and explains what methods are used to improve the efficiency of systems development for
both structured and agile methodologies.
In the upcoming sections we will compare and contrast structured approaches with the agile
approach. An overarching observation about the agile methodology is that it is a human-oriented
approach that permits people to create nuanced solutions that are impossible to create through
formal specifications of process.
REDUCING THE INTERFACE TIME AND ERRORS. Systems analysts and programmers need to
analyze, design, and develop systems using knowledge work tools that range from Microsoft
Office to sophisticated and costly CASE tools. They also need to document as they develop
systems. It is important that analysts and programmers are capable of understanding the interface
they use. They need to know how to classify, code, store, and write about the data they gather.