The Philosophy of Scrum

The core of the Scrum approach is
the belief that most systems development has the wrong philosophical basis.
The stated, accepted philosophy is that systems development process is a well
understood approach that can be planned, estimated, and successfully completed.

The failed projects, inappropriate
systems, and ineffective productivity tools are seen as proof that the development
process needs more rigor, that if we can get those unruly developers to actually
follow it, these maladies will go away.

Scrum states that the systems development
process is an unpredictable, complicated process that can only be roughly described
as an overall progression. Cookbook, step-by-step approaches do not work because
they aren't adequately defined and don't cope with the unpredictability of systems
development.

Scrum defines the systems development
process as a loose set of activities that combines known, workable tools and
techniques with the best that a development team can devise to build systems.
Since these activities are loose, controls to manage the process and inherent
risk are used.

The following maladies occur as a
result applying the wrong philosophy and techniques to systems development:

By the time the system is delivered,
it is often irrelevant or requires significant change. This occurs because
environmental inputs are used only during planning.

Management actually believes
that it can predict the cost, delivery schedule, and functionality that
will be delivered.

Developers and project managers
are forced to live a lie...they have to pretend that they can plan, predict
and deliver, and then work the best way that they know how to deliver a
system. They build one way, pretend that they build another way, and are
without controls.

Scrum is applicable to internal IS
Organizations. Scrum will relieve IS Organizations of these terrible symptoms.

The approach is called Scrum. It
starts with the acceptance that this is a complicated, unpredictable world and
development environment. It also starts with the premise that you can't predict
or definitively plan what you will deliver, when you will deliver it, and what
the quality and cost will be. It starts with the assumption that you can estimate
these, and then negotiate them according to various risks as you proceed. It
is understood at the start, that you will deliver the best possible software
given the circumstances, and that following any cookbook approach won't improve
the definition of "best", and will only hinder appropriate responsiveness to
the complexity and unpredictability.

The reaction of many IS organizations
to this approach includes "we can't do that, everything will be out of control..."
and "our board of directors will never approve funding to build an undefined
product." However, that is exactly the way it is right now: out of control because
of the inability to respond to unpredictability, and the funding is for products
whose definition changes from the first day of the project.

As the divergence between those who
are succeeding with a Scrum-like development process and those who are failing
with SEI-CMM type processes increases, the heat of the argument is rising.

ADM and VMark have formalized the
Scrum process, based on packaged software vendor experiences, because they feel
that OO will suffer and possibly fail using the current development philosophy.

Scrum is applicable to new or existing
systems that use clean interface or objects and components. Scrum enables component
based development. Scrum tolerates on the job learning. As a matter of fact,
Scrum is a knowledge creating process, where tacit knowledge is created and
shared as work progresses. Collaborative teamwork ensures knowledge sharing
and creation.