Certified Scrum Master

Earlier this week I attended a Scrum Master course in order to become a so called "Certified Scrum Master". During 2 days in a workshop like manner we got the opportunity to discuss software development from different points of view and also do some hands-on exercises.


In reality, the principles of Scrum are very easy. You have the Product Owner, who's responsibility is to create and manage the Product Backlog. The Product Backlog is a prioritized list of all functions which are wanted in the product. This is a living document and changes as work progresses.

Next we have the The Scrum Master who's responsible for guiding and protecting the team, i.e a technical project leader of some sort (although it's not correct to use this term).

The Scrum team consists of +/- 7 people preferably with different skills such as programmer, tester etc.

The Scrum framework itself centers around a Sprint. A Sprint is a repetitive cycle, ~30 days, in which the team does its work. It starts with Sprint Planning in which the team chooses and estimates the amount of work which is to be done in the Sprint. During the Sprint the Scrum Master holds Daily Scrum meetings with the team and asks 3 simple questions:

1) What have you done since yesterday?
2) What will you do today?
3) What is hindering you?

During the Sprint no one is allowed to disturb the team and come with additional work requests.

The Sprint ends with a Sprint Review in which the product increment is demoed and discussed. This is followed by a Sprint Retrospective which functions as a lessons-learned session.

This all sounds very simple. Is Scrum some magical "fix-it-all" method then? Well no. However, Scrum adheres from the only certain thing about software engineering: That we do not know what the product will look like in the end. So if the "target" is moving then it is appropriate to adjust your work accordingly along the way. This is a very different approach from the more traditional Waterfall model in which development is looked at as iterative, but straight-forward phases such as planning, design, coding, testing and integration.

The more realistic view on how software development works in reality is the main reason why I believe Scrum may be a good choice. Continual adaptation to the current circumstances as well as the opportunity to vent all potential problems. This is the aim of the Daily Scrums. Any problems and hinders needs to be brought to the Scrum Master for him/her to fix.

Although I now have a new title to use on my CV and more knowledge about Scrum it will take actual experience before I can say much more about it. Scrum may not be appropriate in all organizations and projects, but I intend to give it a try in my current work and see where it will take me. I'm looking forward to it!