Responsibility in Scrum

You can’t escape the responsibility of tomorrow by evading it today
- Abraham Lincoln

The 2020 Scrum guide (in English) often talks of accountability across the 3 roles (Developer, Product Owner, Scrum Master). Each role is accountable for a certain number of things that contribute to the team responsability towards the product goal, via increments of value.

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required
Scrum Guide 2020

The Developers

The developers hold each other accountable as professionals whilst progressing towards the sprint goal. They are commited to achieving that goal and also instilling the notion of quality by adhering to the definition of done.

The Product Owner

They are responsible for communicating the product goal to the entire organization, making the product backlog tranparent and understandable and above all for maximizing the value delivered in each sprint.

The Scrum Master

Amongst the different responsibilities of the Scrum Master, they should accompany the Scrum Team in being self-sufficient, remove any and all obstacles in the way of the sprint goal and make sure that the Scrum events take place.

As the 2020 scrum guide says

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

So basically, it’s a all for one and one for all situation. If one person fails, the team fails (and vice versa).

Responsability

I listened to a great podcast that talked about Chris Avery’s model of responsability (https://www.scrum.org/resources/psychological-models-scrum).

The basics of it are that responsability is a state of mind, it can be learned. Our emotions can alter our perception of responsability, if we’re having a bad day, we are likely to react differently to any given situation than when we are having a great day. If we are open, we can change our level of responsability.

Chris Avery identified six levels of responsability.

1. Denial

We ignore the existence of something. You pretend like nothing has happened.

2. Lay blame

We admit that something has happened, but we immediately lay blame on someone else.
I find that this is often where most developers are. They use Git Blame, they blame other team members, former colleagues or maybe a third party that has worked on the application.
In my team, the Product Owner often shoulds the blame as he didn’t write the JIRA ticket correctly…

3. Justification

We accept the fact that there is a problem, we don’t look for someone to blame, but the situation itself is to blame.
It’s not my fault, it’s the application’s, it’s crappy old legacy code. It’s the browser. It’s my computer…

4. Shame

We admit that we are at fault for the issue.
I didn’t think the task through correctly…

5. Obligation

Something has happened and we are obliged to fix it.
I must / I have to fix that bug, oh God, it’s going to be a right pain in the bum.

6. Responsability

Being proactive, this is not a dead-end, we take an active part in fixing the issue because we want to do it (without moaning). This cannot be instilled and can only come from the person.

The three keys

Intention

The intention to take responsability when things go pear-shaped. Responsible people see problems as opportunities to improve things.

Awareness

Being aware of your current mental state can help you. If you’re having a bad day, take a moment before replying to the email.

Confront

Confronting yourself (honestly) to see what you can do to learn, correcr or improve

So?

I presented these ideas to my team a few weeks ago in the hope that we would have a greater sense of teamwork and would stop pointing the finger at others. Our team manager has seen a noticeable change in the behaviour of the team since this talk. There’s a bit less moaning, more just doing and there’s definitely a lot less finger pointing.

We also have a daily “how’s it going?” question on Slack so we realise ourselves and our team members can see what sort of state we are in mentally.

Just being aware of how we feel has certainly helped each team member in being more responsible.