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.