How the Agile Manifesto translates into Scrum

„Agile“ has evolved into a best practice for software development and has been described by the values described by the Agile manifesto(http://www.agilemanifesto.org/ ):

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

In the following Blog I’ll describe how these values translate into the Scrum artifacts. Scrum artifacts are underlined.

Individuals and interactions over processes and tools

All necessary organization and rules originate from the interactions within the team. The team decides about responsibilities and will manage (external) disturbances collaboratively. The Scrum master helps the team to resolve impediments and assures the (self given) rules are obeyed.

Interactions are amplified by reducing the usage of tools. That’s why Scrum teams prefer Scrum boards with paper cards for task planning and tracking over than (electronic) tools.

Working software over comprehensive documentation

The second value reminds you that the first goal is to create working software that brings value to the customer. Since the subject of the documentation often changes faster than comprehensive documentation can be created too much documentation is just a waste of resources. Agile teams favor delivering software early and often (ideally using continuous integration) to ensure requirements can be validated.

However, documentation is important for further development and maintenance – the challenge is to find the right balance between the necessary documentation and the creation of paper that is never read again. The retrospective after each sprint helps to consider also long term consequences.

Customer collaboration over contract negotiation

The customer is represented by the Product Owner, a role define in Scrum. The product owner understands the customer and has profound business expertise. He is available to the team at any time such that interaction is the main source for alignments.

To avoid any kind of negotiation, the backlog (= open task list) is sorted by the product owner according to the customer priorities, so the customer gets always first what he needs most.

However, this requires a thoughtful and reliable product owner.

Responding to change over following a plan

In Scrum the development is done in sprints, i.e. time boxed. Each sprint is a kind of a small project with a planning, implementation, and review phase. After each sprint the team is re-aligned to the customer needs when they take the topmost items from the backlog.

As most of the project plans are outdated as soon as they are published, it’s just consistent to abolish traditional project plans – only the time of the next sprint is considered. This is counter to traditional project management goals of controlling change and keeping to a plan.

The burn down chart visualizes development speed and progress. In doing so unnecessary work is avoided and the risk of failure is controlled.