More and more of programmers’ interest is attracted by so the called agile project management methodologies. And there is a good reason for that because research done in USA showed that projects using this approach get better ROI.

The most popular methodologies among agile ones is Scrum – an approach created by Ken Schwaber in 1995. Schwaber is at the same cofounder of the Scrum.org, organization that teaches companies how to do agile and tries to standardize knowledge of Scrum. It is the Scrum.org where I had pleasure to start my journey with agile methodologies and where I received my Professional Scrum Master certificate.

Two main features of Scrum are iterative and incremental approaches towards code creation. Iterativity means that the work is done in cycles that usually take between 1 and 4 weeks. Each of them consists of:

  • Planning
  • Actual work (design, implementation, testing)
  • Demonstration or in short Demo
  • Retrospective that helps the team to learn from previous mistakes

Incremental approach means that after each cycle there is a ready and working product with new features. In Scrum you never start something that you can’t complete and show at the end of the cycle.

In Scrum there is a concept of a Backlog – a registry of all features that you would like to have in your product. In each cycle some of those features get selected and implemented.

A huge advantage of Scrum is providing a quick feedback to people responsible for business side of the project. The progress is clearly visible and measurable, so it’s easy to control spendings and organize other activities in the company. Each functionality that got implemented is instantly ready for testing and checking whether it meets business requirements as expected. In case it doesn’t – there’s still much time to introduce changes.

The advantages of Scrum are clearly visible when you compare it to the previous methodology – Waterfall. This approach had it roots in classical project management thought and assumed designing the whole application before writing the first line of code, implementing the whole application right from the start (till the project was finished you could not run anything. In a similar way a car is not functional with only two wheels) and testing your assumptions on at the end of the project when you could finally run the code. The effects were sometimes very cruel. Waterfall led many projects to an epic disaster by showing problems in assumptions way to late in the project, generating additional costs, creating low quality applications and sometimes falling prey to contractual penalties when the deadline was not met.