Page 517 - Using MIS

Q6 How Can Scrum Overcome the Problems of the SDLC? 485

give us another $100,000 and another 6 months, and then we’ll have it done.” If management de-
clines, which it might because at that point, the time and money are sunk, it is left not only with
the loss but also with the unmet need that caused it to start the SDLC in the first place.
In short, the SDLC assumes that requirements don’t change, which everyone who has ever
been within 10 feet of a development project knows is false, and it’s very risky for the business
that sponsors it.

What Are the Principles of Agile Development Methodologies?
Over the past 40 years, numerous alternatives to the SDLC have been proposed, including rapid
application development, the unified process, extreme programming, scrum, and others. All of
these techniques addressed the problems of the SDLC, and by the turn of the last century, their
philosophy had coalesced into what has come to be known as agile development, which means
a development process that conforms to the principles in Figure 12-20. Scrum is an agile tech-
nique and conforms to these principles.
First, scrum and the other agile techniques expect and even welcome change. Given the
nature of social systems, expect is not a surprise, but why welcome? Isn’t welcoming require-
ments change a bit like welcoming a good case of the flu? No, because systems are created to
help organizations and people achieve their strategies, and the more the requirements change,
the closer they come to facilitating strategies. The result is better and more satisfying for both
the users and the development team.
Second, scrum and other agile development processes are designed to frequently deliver
a working version of some part of the product. Frequently means 1 to 8 weeks, not longer. This
frequency means that management is at risk only for whatever costs and time have been con-
sumed in that period. And, at the end of the period, they will have some usable product piece
that has at least some value to the business.
Thus, unlike the SDLC, agile techniques deliver benefits early and often. The initial benefits
might be small, but they are positive and increase throughout the process. With the SDLC, no
value is generated until the very end. Considering the time value of money, this characteristic
alone makes agile techniques more desirable.
The third principle in Figure 12-20 is that the development team will work closely with the
customer until the project ends. Someone who knows the business requirements must be avail-
able to the development team and must be able and willing to clearly express, clarify, and elabo-
rate on requirements. Also, customers need to be available to test the evolving work product and
provide guidance on how well new features work.
The fourth principle is a tough one for many developers to accept. Rather than design the
complete, overall system at the beginning, only those portions of the design that are needed to
complete the current work are done. Sometimes this is called just-in-time design. Designing in
this way means that the design is constantly changing, and existing designs may need to be revised,
along with substantial revision to the work product produced so far. On the surface, it is inefficient.
However, experience has shown that far too many teams have constructed elaborate, fanciful, and
complete designs that turned out to be glamorous fiction as the requirements changed.

• Expect, even welcome, changes in requirements.
• Frequently deliver working version of the product.
• Work closely with customer for the duration.
• Design as you go.
• Test as you go.
• Team knows best how it’s doing/how to change.
Figure 12-20 • Can be used for business processes, information
Principles of Agile (Scrum) systems, and applications development.
Development