What a Scrum master should know about Scrum

I got a call from my kiwi friend this morning. He got a job as a Scrum master in Auckland and had some questions about Scrum itself. I decided to put it on the virtual paper so that others can have some benefit from it as well. This article is not about explaining the Scrum process, it is about the principles behind.

Why Scrum?

A development team wants to deliver to the client something he will be happy about. The problem is the client does not know what he wants. He discovers it step by step. The same applies for the developers. Their work is usually more about research than writing a code – they also discover the best solutions as the project goes on. So let’s admit that no one is able to know everything in advance. You learn things when trying them out. Once you accept this, there is Scrum to support you.


Scrum is based on short iterations (2 – 4 weeks) of product development. The important aspect of the iteration is the style of work – developers do everything to deliver functionality which can be immediately released. This means they do a little bit of architecture, design, backend, frontend, testing just enough to complete the desired functionality.

And this is the magic of Scrum – at the end of each iteration, the client gets part of his product ready to be released or changed if he wishes so. Seeing something done in SW development after 2 to 4 weeks is a huge advantage both for the client and the team. It helps the client to discover what he wants or even better – what he does not. The team gets the feedback soon and often.


There are always changes and some work thrown away. Again – let’s accept it and try to minimise it. Instead of giving away a 6-months work, the team is exploring the right direction together with the client – by trying different paths, searching for the right one by abandoning the blind ones. Short iterations help the team and product owner to learn faster and discover the right solution sooner.

Getting to the market

When using Scrum, you are able to launch your product to the market much earlier. In Scrum, the product owner sets the priorities to the features he wants to be part of the product. The dev team then starts developing the most important feature first. Once the core feature of the product is done, you let the people use it and collect their feedback. The sooner you launch your product, the sooner you start achieving your goal – getting users, new customers, earning money – whatever your goal is.



People are afraid of launching a product which is not complete in their eyes. They are afraid of what users will say – it is not done and it should be. But let’s put it in this way: you launch your product with the basic functionality only. You gather feedback from users, you implement it to your product and show them the result. Everyone is happy when being listened to. And by doing this, you listen to your customers. Like that, they will be more likely to provide you with more feedback.

Empirical learning

Small and frequent releases make developers learn faster because they get a chance to deliver their work completely, including all the tasks related to the release such as running the performance test, merging all the code etc. You let them experience the whole process of SW development within one iteration – research, development and release – they discover whats wrong immediately and not at the end of the project. Based on this experience, developers can provide better estimates on the remaining features and work with the manager’s expectations.


In Scrum, the product owner says what he wants and why. Developers need to know the purpose of the desired feature so that they can design a good solution. Developers have freedom in choosing their solution. They also define how much work they can make within the iteration. This trust provided to the team is necessary. Not many people find amusing to follow step by step instructions from their boss. Software development is about creativity a lot and creativity grows from freedom.


This freedom is conditioned by the team’s responsibility though. The team makes all the best to accomplish what they committed to. Even if it means one has to leave his usual role inside the team and do something less funny – as for example a backend developer helps to the tester with the tests. All this for the sake of a achieving a goal at the end of the iteration.