Status:

Awaiting proof reading.

Why use Scrum?

In short – you should use Scrum because if you implement it properly it will improve your product quality. It will enable you to deliver on time and on budget. It will allow you to adapt the product to changes in market and client desires.

The main goals are:

• Deliver a product that matches or is better than what the client wants.
• Deliver on time.

In a perfect world the following would be true:

• The client never changes his/her mind.
• There are never any nasty surprises.
• From the outset we know exactly how to build it - down to the last bit.

In the real world:

• The client pretty much always changes his/her mind.
• Unforeseen things do happen.
• We learn/discover along the way how to best create the optimal product.

With the traditional “Waterfall” process you try to anticipate everything and specify how it all should be developed. Specifications are written and signed by various people including the client. It is not possible to anticipate everything and this is shown clearly in the facts. According to Standish Group who has studied more than 40,000 projects over 10 years, the average cost and time overrun for IT projects in 2004 is about 70%.

Scrums solution is to make the development adaptive. The development is divided into smaller cycles called “sprints”. A sprint is time limited to typically between 1 to 4 weeks. Each sprint contains functionality that must be developed, tested and prepared for delivery.

You may think that this method gives a lot of overhead but the fact is that it actually cuts development time. The reason is that the modules are fully developed. In a normal project where test normally is in the last stages, errors can take long to debug because many have been coded sometimes 3-12 months earlier. Another benefit is that a person responsible for the product (in Scrum called the Product Owner) is present after each Sprint to evaluate what has been made. This means that misunderstandings are discovered earlier and will take a lot less effort to correct than if they are discovered at the end of the project.

There is also a psychological effect. If your deadline is less than 1 month away rather than 12-18 months the coder will start coding right away rather than sit and think there is plenty of time. This effectually deals with the normal cycle where you work lightly in the beginning, then ramp up the speed and work 24/7 for the last weeks up to the deadline.