| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Whenever you search in PBworks, Dokkio Sidebar (from the makers of PBworks) will run the same search in your Drive, Dropbox, OneDrive, Gmail, and Slack. Now you can find what you're looking for wherever it lives. Try Dokkio Sidebar for free.

View
 

DayinthelifeofaScrummaster

Page history last edited by PBworks 16 years ago

Day in the Life of a Scrum Master

 

From an email to my apprentice recently (my attempt to take another angle at the control issue):

 

I wrote:

 

Subject: Day in the life of a Scrum Master, according to Ken

 

1. Ensure everyone is doing what they have agreed to do;

 

2. Determine where the Sprint is compared to where it could be and

update your own Sprint backlog ( & task board);

 

3. Work the product backlog;

 

4. A dead Scrum Master is a useless Scrum Master; and,

 

5. Use all of your senses, including common sense, and remember that you

have no authority.

 

From the CSM methodology v5.

 

 

to which the apprentice wrote:

 

No authority sounds rather scary!...in what context?:)

 

My reply:

 

The team is FULLY responsible for the outcome of the work, the product, what is demo'd. It is in this context that the SM is not a performer, and has no authority (i.e., to say "we should do this" or "here's how to approach it" or "you missed that".) The SM must keep the team aware of this fact, so they have motivation to solve problems themselves in a "whole team" manner, and not a CYA manner.

 

How to deal with this? Try "I've noticed...", "have you missed that?", "I have an idea - what do you think?" "It's up to you", or asking an OPEN question: "I've noticed we have Requirements in 5 places. Do we need all of these?" At first people find this threatening, assuming I am passive aggressively saying we DON'T need these. No, it really is an open question. You can assert this all you want, but the best way is to show it - ask them and REALLY let them tell you - no answer is wrong. Example: During the Requirements discussion, did you notice BL's back get up when someone asked whether we really need JUnit tests? So I asked "B, what do we lose if we get rid of them?" and from his answer, the questioner quickly realized that quality and thrashing is at stake, and the issue died right there. Now that they have discussed it THEMSELVES they should hopefully continue to manage that issue themselves. If not, another question may be in order.

 

The scrummaster IS responsible for herding the cats in the right general direction (have you seen that wonderful EDS video ad? It's hilarious: http://www.superbowl-info.com/bin/edscatherders.mov ).

 

The SM is the remover of obstacles (looking ahead, taking them out of the way, but not too far ahead in case of YAGNI: you ain't gonna need it). This includes getting these things ready for the team, in time: room, needed materials and tools (computer, markers, paper, whiteboards, chocolate, DBA, lunch, meeting rooms, onboarding etc.) This is why the SM should start work before the team hits the ground.

 

The SM is responsible for facilitation (getting people to play nicely together - oh my gosh, is this a challenge some days!! :-) But it is also rewarding, when you look and everyone is quietly collaborating and putting their best skills into the work.

 

The SM is responsible for having the big picture (not of the work itself - the team is responsible for that) but the big picture of the Working of the team - the process. This includes stakeholder relations (as you proposed yesterday - getting it off on the right foot and letting the team handle it from there).

 

Thanks for the good question. Hope this is helpful, or raises more good questions.

 

ciao

d

 

Comments

 

  • Yes, it is scary! (TM - Joe)

 

  • Toto, we're not in Kansas anymore.

 

  • Listen, listen, listen.

 

  • Decide what is the most important thing that the Team can work on now. (That is not part of the regular work.) More or less, what is the most important obstacle. For the Team. Not what is easiest for the SM to help with. Not what is most important to one person. To the Team. (Not always easy to decide.) -- Joe

 

.

.

Comments (0)

You don't have permission to comment on this page.