Page 515 - Using MIS

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

from the event. At this point, there are four different versions of the requirements. If the changes
to requirements are not carefully managed, changes from the four versions will be mixed up,
and confusion and disorder will result. No one will know which requirements are the correct,
current ones.
Similar problems occur with designs, program code, database data, and other system
components. The term configuration control refers to a set of management policies, prac-
tices, and tools that developers use to maintain control over the project’s resources. Such
resources include documents, schedules, designs, program code, test suites, and any other
shared resource needed to complete the project. Configuration control is vital; a loss of con-
trol over a project’s configuration is so expensive and disruptive that it can result in termina-
tion for senior project managers.
The last major challenge to large-scale project management is unexpected events. The
larger and longer the project, the greater the chance of disruption due to an unanticipated
event. Critical people can change companies; even whole teams have been known to pack up
and join a competitor. A hurricane may destroy an office; the company may have a bad quarter
and freeze hiring just as the project is staffing up; technology will change; competitors may do
something that makes the project more (or less) important; or the company may be sold and
new management may change requirements and priorities.
Because software is thought-stuff, team morale is crucial. I once managed two strong-
headed software developers who engaged in a heated argument over the design of a program
feature. The argument ended when one threw a chair at the other. The rest of the team divided
its loyalties between the two developers, and work came to a standstill as subgroups sneered
and argued with one another when they met in hallways or at the coffee pot. How do you
schedule that event into your WBS? As a project manager, you never know what strange event is
heading your way. Such unanticipated events make project management challenging, but also
incredibly fascinating!

Q6 How Can Scrum Overcome the Problems
of the SDLC?

The systems development life cycle (SDLC) process is falling out of favor in the systems devel-
opment community, primarily for two reasons. First, the nature of the SDLC denies what every
experienced developer knows to be true: systems requirements are fuzzy and always changing.
They change because they need to be corrected, or more is known, or users change their minds
about what they want after they use part of the system, or business needs change, or technology
offers other possibilities.
According to the SDLC, however, progress goes in a linear sequence from requirements to
design to implementation. Sometimes this is called the waterfall method because the assump-
tion is that once you’ve finished a phase, you never go back; you go over the waterfall into the
pool of the next stage. Requirements are done. Then you do design. Design is done; then you
implement. However, experience has shown that it just doesn’t work that way.
In the beginning, systems developers thought the SDLC might work for IS and applications
because processes like the SDLC work for building physical things. If you’re going to build a run-
way, for example, you specify how long it needs to be, how much airplane weight the surface must
support, and so forth. Then you design it, and then you build it. Here waterfall processes work.
However, business processes, information systems, and applications are not physical; as
stated, they’re made of thought-stuff. They’re also social; they exist for people to inform them-
selves and achieve their goals. But people and social systems are incredibly malleable; they
adapt. That characteristic enables humans to do many amazing things, but it also means that
requirements change and the waterfall development process cannot work.