I’ve been involved with Scrum since early 2008. It all started with an information day held by HiQ in Stockholm, Sweden. In a series of articles I will elaborate on different subjects of the Scrum framework, on what I’ve learned so far. List of subjects is at the end of this article.
You, the reader, should have some idea of what Scrum is and hopefully you’ve been involved with some Scrum yourself. To get the basics; the “Learn About Scrum” page over at Scrum Alliance is a great introduction, and the Wikipedia article will set you in a good position for this series.
The main reason for writing this is to document my thoughts derived from my own experiences using Scrum. Henrik Kniberg wrote in his excellent “Scrum and XP from the Trenches” (2007) that “one of the most valuable sources of information (…) was actual war stories” (p.8), I agree and the time has come to tell you mine. And, in no way do I claim that the Scrum presented in the following is anything else than how I perceive and use it.
Each article will at least try to answer three questions:
With this question I will try to define the subject at hand. Definitions like these seldom brings any surprises but I’ve learned that with a presented definition it’s easier to keep the discussion closer to target.
In my opinion, responsibility for something is a task for one person only, not a task for a group nor for a function or anything not as concrete as one specific person. Can responsibility be given or delegated to another person? If the receiving person does not actively take on the responsibility, then no. A person takes responsibility for something, which means that if there is a specific responsibility connected to a role, then the person taking on that role are also taking on the responsibilities associated with it.
Why this matter is twofold; first, the person with the responsibility knows that the responsibility is his/hers and not shared with anyone else, everything connected to the responsibility is the task of the responsible, and second, consequently all other persons not responsible knows that there should be someone for that, but “it’s not me”.
My favourite example is how meetings often are conducted.
Someone tells someone else to set up a meeting and invite some persons to it. The invitation often lack information on what the meeting is about and almost never are there any agenda attached to the invite. The meeting starts, but there are really no clear facilitator of it, both the someone and the someone else tries to keep the meeting on point, whatever that was, then a third person might step in to try to sort things out, often a senior boss-like person. These meetings tends to end with the phrase “OK, that sounds great” or something that sounds like if all the participants agrees on something. The truth is, they rarely do.
With one simple rule meetings like this can become a thing of the past; the person inviting to the meeting is responsible for it, that’s the rule. The beauty of this is that it’s enough if only the inviter knows this rule because as soon as the meeting starts the inviter will welcome all, i.e. take charge of the arena, thus the other participants will see this and more easily know who’s responsible. Now the person responsible will make sure the meeting does what it set out to do, usually this is done by summarising the meeting in the end of it and making sure the participants agrees with the summary. This rule has saved many meetings!
In Scrum there are a couple of roles, each with different responsibilities connected to it.
The Product Owner is, as the title indicates, the owner of a product. This means that the Product Owner is responsible for the product in the context of the organisation. This person is where the rest of the organisation “dumps” its wishes for the product.
Then there’s the Scrum Master, this person is responsible for making the team work as undisturbed as possible and often work closely with the Product Owner. The “master” in Scrum Master does not suggest that this person in any way is supposed to be the team leader, rather it suggests that this person is the one responsible of teaching and maintaining the Scrum framework knowledge within the team. However, the Scrum Master is a servant-leader.
The rest of the team’s members also have responsibilities, however, there’s no generic one I can summarise it into. More about the team and the roles in it will be elaborated on in the article on the Scrum team.
Since I believe all things that needs to be done has to be assigned a person responsible for that thing, I will try to set the role I think should hold that responsibility.
This is where I tell you what I’ve learned so far when it comes to the subject at hand. There might be examples or other war stories to emphasise my points and hopefully you could bring something from this.
If there’s a specific subject you’d like me to elaborate on, please don’t hesitate to add this in the comments or contact me via any other media.