Early delivery (Scrum)

Scrum promotes the idea that at the end of each sprint, something workable is delivered and that this starts happening as soon as possible: Preferably within the first one or two sprints.

Reasons

Why this emphasize on early delivery?

Get through the fear

Programmers might have an intuitive recoil from early delivery, for the confrontation with reality, might be too painful. In a certain way, it's much more attractive to keep working without delivering, and keep believing that you are making the most piece of software that has ever been developed.

As long as a piece of software has not been delivered, it is still a promise.

I believe this might be the most important reason for early delivery: Get through the pain; make it real.

Make it real

As long as nothing tangible has been delivered, the whole endeavour is theoretical. It must become real. ASAP.

Frequent feedback

Getting frequent and early feedback is probably the same as get through the pain. It is also more specific: Building a piece of software is more complex and more abstract than e.g., building a bridge. Therefore you need feedback from the end-users.

Risk mitigation

• Early and frequent delivery reduces the risk of delivering something that doesn't meet the stakeholder expectations
• It also helps to inventorize risks involved in decisions concerning what to build now, and what to postpone, or what not to do at all.

Delivering business value

The sooner something working is delivered, the sooner business value is delivered.

Visibility & transparancy

Through early and frequent delivery, the development teams is making it tangible what the heck they are doing.