Scrum. Part 1

The famous American inventor Thomas Edison invented the light bulb 140 years ago. It would be more correct to say that he was the first to make the light bulb as we know it. To achieve this goal, Edison needed to conduct about 2 thousand different experiments, and in the end he succeeded.

Don’t think that this article will be about the invention of the light bulb. It’s about Scrum, or rather about one of the Scrum events – a sprint retrospective.

I would like to emphasize how important it is in any business to improve, develop and apply new approaches. This is the essence of the sprint retrospective, since this event, according to the Scrum Guide, has two goals:

inspect the past sprint in relation to people, relationships, processes and tools

create a plan to incorporate these improvements into the team’s workflow

During the retrospective, the team needs to identify and discuss:

What went well in the past sprint is to continue to use those team actions that positively affect the result of our work

Events that negatively affect work – apply some improvements and eliminate this negative impact

For example, the team lacks a detailed description of the requirements of the tasks, or some plug-in can be used in the work, or maybe Kolya and Petya have such a tense relationship that they cannot continue to work together, and the conflict needs to be eliminated. All these examples can be discussed in retro style, to think about how the team can eliminate these problems, increasing the efficiency of their work. The result of such discussions should be recorded and applied in the future.

It should be noted that for a sprint lasting 1 month, the retrospective should not exceed 3 hours; it is held at the end of the sprint and before planning the next one. It is important for planning to consider information from two previous events: a revised product backlog and improvements that the team can use in their work.

Also, at Project manager courses, they teach that the whole Scrum team participates in retro – the development team, Product Owner and Scrum master.

The development team is engaged in the creation of the product, and only she owns the sprint backlog – a list of tasks that the team takes into the sprint

The Product Owner is responsible for achieving maximum product value and this is the only person who is responsible for the product backlog – a list of tasks with product requirements

The Scrum Master is responsible for promoting and supporting Scrum according to the system manual

The master is given an important role in the retrospective. First, he must facilitate all events. Secondly, the master encourages the team to improve the development process and work approaches. He is primarily responsible for organizing the Scrum process.

The Scrum Master applies the principles of facilitation and moderation when doing retro. Nowadays, these two concepts have practically merged into one, and many argue that they are one and the same.

Common are:

Organization of the group work process aimed at achieving the goals set for the group

The moderator or facilitator leads the group according to a clear plan, as a result of which the participants must achieve the desired result, understood by everyone and accepted by each of them

Both the moderator and the facilitator should not influence the final product of the discussion and impose their opinion

At first glance, these concepts are identical, but there are still small differences between them.

The moderator restrains the group within some framework and does not allow the discussion to lose the essence, and the facilitator gives more freedom of action to the team, facilitating its group work. The moderator leads the group to the desired result in a systematic and structured manner. The facilitator helps the group to come to a result, drawing on the participants’ own experience, leading the discussion participants to important, but non-obvious decisions. For the Scrum Master, when conducting retro, it is important to find a middle ground – to facilitate the group’s teamwork and not let the team go beyond the discussion.

For retrospectives to be useful and interesting, the Scrum master needs to prepare carefully for them. To prepare for the retro Scrum, the master needs to have his own checklist, which will help not to forget and not miss important points. Below is an example of such a checklist:

TOPIC COURSE

Project Management
Check list

How long is the retrospective? The scrum master keeps track of the time limit so that the retro is not too long.

Where can you find the results of the past retrospective? They need to be recorded somewhere so that the Scrum master can review them with the team.

Has feedback been considered regarding retrospective improvements? It’s important to get feedback from the team on how the retrospective went.

What tasks did the Scrum Master have to accomplish based on past retro results? If the master promised to do something, then it is necessary to tell about the status of these tasks.