Aug 14, 2009

Who should play the role of a Scrum Master in our teams?

Currently most of our teams have a dedicated person to play the role of Scrum Master for all 3 types of projects we do. Is that the right setup? Here's how I see it...


Type 1

Small teams working on simple project demands e.g. Client Connect, SugarCRM
>> My take: A project team member (product owner or someone from the dev team) can play the Scrum Master role. They can rotate it among them as well. More thoughts below...

Type 2

Teams working on projects with complex sponsor, vendor, technology, coordination risks and demands e.g. Digital Strategy, MyTime
>> My take: We need a dedicated person to play the role of a SM for large projects

Type 3

Everything between 1 and 2
>> My take: Same as type 1


We should consider the following facts during staffing project types 1 and 3:
- everyone in a team may not be able to play the role of a Scrum Master (only a few can in our 150 person team)
- heads-up (forest) vs. heads-down (trees) perspective on projects need to be ensured
- balance between "what" (product owner focus) and "how" (Architect’s focus ) something is built
- Scrum discipline: teams might compromise e.g. its “okay to live with these impediments”
- Anything else to consider?

Thoughts?

3 comments:

  1. I agree that for small teams (Type 1) it may make sense for someone in the team to play the SM role, keeping in mind the SM is more than an impediment remover, they are team enablers. However, for those Type 3 projects, you may need a dedicated SM role (partial allocation of someone’s time to focus on the role).
    Why?
    Very often and if the roles are shared, Product Owners, Developers, etc…tend to focus on their primary role (in this case) either to deliver a product backlog or deliver software (especially when there are time constraints and pressures), and it becomes of less importance the responsibilities of a Scrum Master (beyond impediment removal).
    What are some of these responsibilities that may be overlooked?
    Help the team build trust and gel together, work collectively & feel shared ownership, build relationships with sponsors, encourage improvements if things have reached a plateau, ensure work is challenging and the right opportunities are given to all team members, help the team by contributing with stories (if needed) to meet project goals, and overall continuously inspect and ensure.. some examples:
    Is team effectively leveraging the retrospectives?
    Are burndown charts utilized to communicate w/ sponsors and influence decisions on scope?
    Is the backlog structured properly so there are no surprises later on?
    Is the team over committing on stories?
    Etc, Etc…
    Other things to consider:

    Any organizational impediments project may phase?
    How seasoned is the team and stakeholders with Scrum? Have they worked together previously?
    Can team motivation be improved?
    Are the project goals clear?
    Etc…

    ReplyDelete
  2. Thanks Yva. You make great points on what could be missed when a team member (business analyst or engineer) plays the scrum master role...

    How do/should we address them?

    (A) Today we add a separate person with partial allocation to play the scrum master role

    (B) Could we let a team member take the scrum master role, if he/she has the skills and experience

    ----------------------------

    I see opportunities for (B) and think it can work for us given that:

    - our teams are smaller, experienced and agile
    (avg team size is 5 (down from 14, five years ago)... primarily due to Agile and our preference for experienced engineers. We now hire experienced, agile-minded, multi-skilled engineers/BAs)

    - the "natural" leader in a team emerges and plays the role of scrum master (coaching etc.)

    - there are already some roles to provide project oversight in our organization (portfolio lead/architect roles). Additional oversight might be too much?

    By the way, (B) is already happening in some project teams and the results are encouraging.

    (B) is not a perfect solution and will require attention to address the challenges you've listed and others we will encounter. As our teams get better, (B) can lead us to small, effective teams.

    ReplyDelete
  3. Yva and I discussed offline as well and we seem to agree on the overall line of thought. Yva is an experienced PM in our group and had the following recommendations for those who chose to play the role of SM:
    (1) take time to learn about the role and (2)allocate time to play the role (don't just go through the motions)

    ReplyDelete