The three pillars of Scrum implementation: awareness, accountabilities, events

People say that Scrum is simple to understand, but difficult to master. Of course it's correct, but the truth is that the main difficulty is not in Scrum itself, but in your ability to be clear about the roles and responsibilities within your organization, and your consistency and perseverance.

In Kanban we say "Stop starting and start finishing". It's right mindset no matter what you practice – Scrum, Kanban or something else. So, how can we implement Scrum in its entirety?within the organization?

1) Help your team to become more aware of benefits of using Scrum

If you read the Scrum Guide carefully, you noticed that Scrum brings blameless culture?and thus provides psychological safety for the team and most likely for the entire organization, because "the purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness" – not to find someone who was guilty if something really went wrong during the Sprint.

"The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. ... The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved." Thus Scrum promotes a culture of continuous improvement – Kaizen, and if the motivational system in your company works well then all your team can enjoy some tangible bonuses ($) from it.

For the person who is accountable for maximizing the value of the product – the Product Owner – Scrum might be helpful for building right business relationships with too persistent stakeholders. Such approach may help this Product Owner to learn how to say NO, because "those (stakeholders) wanting to change the Product Backlog can do so by trying to convince the Product Owner".

2) Define specific accountabilities within your team

"Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master."

As you can see on this picture, the Developers (Development Team in Scrum Guide 2017) are accountable for building the thing right – HOW we build our product; the Product Owner is accountable for building the right thing – WHAT we must build; and the Scrum Master is accountable for building it fast – it's about the efficiency of the process and its VELOCITY.

Scrum Artifacts

Scrum has three artifacts – the Product Backlog, the Sprint Backlog, and the Increment. They are designed to maximize transparency of key information and represent work or value. Each artifact contains a commitment:

• For the Product Backlog it is the Product Goal – Product Owner's responsibility, because he is "accountable for maximizing the value of the product resulting from the work of the Scrum Team".
• For the Sprint Backlog it is the Sprint Goal – Developers' responsibility, because they are "the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint".
• For the Increment it is the Definition of Done – Scrum Team's responsibility, because "the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint".?

So which responsibilities does the Scrum Master have? According to the Scrum Guide "the Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team’s effectiveness, including:

• coaching the team members in self-management and cross-functionality;
• helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
• causing the removal of impediments to the Scrum Team’s progress;
• ensuring that all Scrum events take place and are positive, productive, and kept within the timebox;
• facilitating stakeholder collaboration as requested or needed;
• removing barriers between stakeholders and Scrum Teams;
• leading, training, and coaching the organization in its Scrum adoption."

As you see, the Scrum Master is a key role for Scrum implementation within the organization, and if Scrum doesn't work properly, it may happen for these four reasons:

1. Absence or violation of Scrum roles.
2. Absence or violation of Scrum events.
3. The Scrum Master is incapable to do his/her job properly.
4. Organization is not ready for Agile/Scrum yet.

Warning!

In case of immature organization the Scrum Master most likely would be a "voice of one crying in the wilderness", and I think you know about prophet's destiny in human history. Why I think so? Because the Scrum Guide 2017 called the Scrum Master "a servant-leader for the Scrum Team". This is not a managerial role, and it's right, because it's almost impossible to be a coach and boss, at least at the same.

And the final issue here that I want to address is that if the Scrum Master is not an indifferent person, then there is a probability that he/she may be engaged in the Karpman's Drama Triangle by taking on the role of the rescuer, and this is a destructive way to go from psychological perspective.

The Drama Triangle was first described by Stephen Karpman in the 1960s. It is a model of dysfunctional social interactions and illustrates a power game that involves three roles: Victim, Rescuer, and Persecutor, each role represents a common and ineffective response to conflict. – I will cover this topic in another article later.

3) Ensure that all Scrum events take place and are positive, productive, and kept within the timebox.

"Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required. Failure to operate any events as prescribed results in lost opportunities to inspect and adapt. Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum."

1. Sprint (max. 1 month) is a container for all other events. "A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint".

2. Sprint Planning?(max. 8 hours) – addresses the following topics:

• "Topic One:?Why?is this Sprint valuable? – The Product Owner proposes how the product could increase its value and utility in the current Sprint.
• Topic Two:?What?can be Done this Sprint? – Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint.?
• Topic Three:?How?will the chosen work get done? – For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done".

3. Daily Scrum?(max. 15 min.) – "it is a 15-minute event?for the Developers?of the Scrum Team to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work".

4. Sprint Review?(max. 4 hours) – "The Scrum Team presents the results of their work?to key stakeholders?and progress toward the Product Goal is discussed".

5. Sprint Retrospective?(max. 3 hours) – "The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness".

As we remember, one of the responsibilities of the Scrum Master is to ensure that "all Scrum events take place and are positive, productive, and kept within the timebox".

In short, that's all. Now you are ready to go!

And please keep in mind that only motivated people will be able to "turn a selection of the work into an Increment of value" because "successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect, and Courage".