8 Key Aspects of Scrum Master Role

Ever since I was a child I have had this instinctive urge for expansion and growth.
To me, the function and duty of a quality human being
is the sincere and honest development of one’s  potential.
Bruce Lee

Working as active Scrum Practitioner for almost 9+ years I have come up with my understanding of what is Scrum Master’s role, service to the team and key responsibilities. Earlier I have written about what Scrum Master should master, here I would like to concentrate on 8 Key Aspects of Scrum Master work. Focus areas so to say. Here those are….

Facilitator

• Facilitates Sprint Planning Meeting
• Facilitates Sprint Review Meeting
• Facilitates Backlog Refinement (aka Grooming) Meeting
• Facilitates Sprint Retrospective Meeting
• Facilitates Daily Scrum
• Facilitates Release / Roadmap Planning Sessions
• Facilitates whatever/whenever else Team and/or stakeholders communication is required to be facilitated (not about any collaboration)

Purpose: to improve shared task clarity, planning, bring in more transparency over status quo for team to see where do they stand (and plan to go, and what have they achieved and how they want to improve) and their work results, help team to be able to enhance communication and perform their daily work

Team Builder

• Cultivates “us” vs. “me” culture and mindset
• Enables and fosters team to self-organize
• Helps team to make decisions
• Supports team through stages of its development
• Coaches individual team members on communication, collaboration and teamwork when necessary
• Increases “bandwidth” of communication among team members
• Observes team and talks to every single team member
• When required does one-on-ones to help through raising conflicts
• Navigates conflicts (involves management when necessary)

Purpose: to build up better team => better understanding each other => improved collaboration among team members => improved team performance

Team Guardian

• Guards team agreements, decisions and process (e.g. retrospective decisions, agreed “howtos”, DoD, DoR, review process, etc)
• Make team stick to its agreements, drives teamwork and respect towards owning decisions, leading to performance improvements
• Keeps balance between fulfilling business (Product Owner) needs and maintaining team sustainable pace, so that business needs are addressed by PO requests while team development and pace is not forgotten.
• Makes sure environment is as Team empowering as possible. Empowerment raises team feeling of ownership that rises up dedication and servers to better results
• Helps the team and Product Owner to maintain their artifacts (product backlog, sprint backlog, task and action boards, sprint/release burndown charts, tickets comments, story maps, etc.)

Purpose: create and maintain environment where high demand is possible. Here is why that is important

Impediment “Fisher” & Resolver

• Creates environment for effective impediment “fishing” and removal. Cultivates transparency and information radiation as pre-requisite for impediment clarity and removal
• Enables team to respond to impediments
  • Raises awareness of team’s impediments
  • Coaches team in resolving impediments (the one’s that could be solved by team)
  • Helps team to discover new impediments (wastes). Constantly questions the status-quo
  • Helps to resolve impediments / take ownership of those cannot be solved within / by team
• Improves efficiency of the team by helping with eliminating impediments
• Escalates and follows up on impediments to where they belong

“High Focus” Promoter

• Shields team from external interferences (extra tasks, todos not agreed with Product Owner, etc)
• Enables team to concentrate on most important todos, achieving “state of flow” and high concentration.
• Helps to avoid wastes caused by context-switching and to avoid team member burn-outs
• Gardens team’s sustainable pace, so that combined with “empowered” environment of high demand is possible
• Increases feeling of “urgency” and highlights how much is left to achieve (e.g. tickets, story tasks, story points, etc.), e.g. with the help of burndown charts, tickets left, etc.
• Helps team to focus on regularly achieving small thing to create feeling of fulfillment and good progress

 Motivator and Coach

• Promotes positive thinking, open, honest and respectful feedback culture
• Motivates team to improve team productivity regularly
• Helps to raise team morale, to increase dedication and to improve team deliverables
• Helps to create feeling of achievement
• Creates environment of excellence and continuous improvement (and mindset of seeking for improvements)
• Creates mindset of “quality first”, intolerance to poor quality and continuous improvement
• Regularly takes care of team’s “happiness” (and involves management when necessary)
• Coaches and teaches required mindset, frameworks and engineering practices (Lean thinking, Scrum, Kanban, XP, pair programming, continuous integration, test automation, etc.)
• Teaches and integrates new team members into working process and agreements (and into the team)
• Serves as agent for change and positive challenger of the team
• Reflects integrity and leads by example (e.g. being on time, continuously self-improving, sticking to agreements, etc.…)

Reflector

• Reflects Lean thinking and Agile principles to the team
• Reflects on reality and promotes transparency on status-quo to question
• Makes things measurable where applicable and possible to illustrate team progress: brings transparency about what is done, how much is achieved, so that weaknesses are easier to identify and potential improvements are easier to see
• Helps team to radiate information (e.g. burndowa, burnup charts, impediment boards, hapiness matrix, knowledge matrix, peerwork matris, etc.)
• Introduces required measurements for team to see regularly its work results (e.g. tickets achieved, stories done, story points achieved, bugs popped up/fixed, retrospective decisions implemented, ..)
• Uses collected data to think and question team and act if required

Agileist: outside of Scrum Team

• Shares Agile/Lean mindset within organization
• Shares best practices and tools, so that other Scrum Masters can benefit / see different perspective of managing things and company can benefit from enriched toolbox of methods and practices
• Collaborates and helps other Stakeholders to learn how their requests could be fulfilled with the team doing Scrum (or Kanban), so that other Stakeholders could get their requests address while team’ pace is also protected
• Helps to improve organization by creating learning organization
• Helps to address organization’s impediments

Last and not least there are many other things that do not belong to this structure. Those are dependent on situation and circumstances.  And those are still handled by great Scrum Masters 🙂

When self-organization does NOT work: teamwork hints

Scrum is based on “Empower the Team” Lean principle that prescribes self-organization. This means that regardless of age and experience team members are equal and serve as managers to one another. There is strong rationale behind: people that do the work are the best to manage it as they own responsibility of results and know best how to handle it.

Daily stand-up or daily SCRUM is a team tool to reflect on changing reality and adapt accordingly.

I’d like to point out some cases when self-organization does not work as should and help those teams out to boost their productivity.

Let us discover some sick stand-up/self-organization symptoms first…

1. Refraining from exposing problems (ignorance of reality):

• Task takes longer than planned and reasons are not clear to everyone (or something holds back people from raising problems);
• Task is blocked and impediment is not exposed/raised (this also may indicate some other problem with task that is not comfortable to raise);
• It’s just a way it is (yes we all know that we’ve planned 4 hours for that task, but as usual it takes us 2,3,5,… times longer or this guy always messes things up, we can do nothing, etc…);
• Team does not reflect during a day on changing reality (just in stand-ups), leading to impediments piling up and being addressed late, so that they mask something else;
• Etc…;

2. Intolerance to critical feedback:

• Team member pushes back heavily when someone tries to rise a problem related to his/her task;
• Raising problems considered as de-motivating and team silently prefer to hide them until it’s too late;
• Team members prefer to stay “nice” to each other rather than constructively criticize their plan in order to adapt it daily;
• Etc…;

Those two are inter-related. As a team member one will hold back from giving critical feedback if receives push back from his/her peer leading to confrontation and poor->no self-organization…

Scrum Masters, look around. Don’t you observe those symptoms during your stand-ups and/or during daily work?

If yes then…

Try out following cures ….

• Talk to push-backers one on one, try to understand what makes them do so? It could be personal issues with team members, lack of positive feedback or self-esteem, or other personal or inter-personal problem(s). It also could be absence of trust (readiness to look vulnerable to the team).
• Explain that feedback is not oriented towards person, rather towards team (exposes problem) as there are no personal problems in a team, since problem causes wastes, further slowness, incompleteness and later sprint failure of entire team.
• Focus person on constructiveness rather de-structiveness when exposing problem and coach on asking why 5 times, usually it helps to come up with adequate counter measures to remove root cause of the problem;
• Educate other team members that raising questions is crucial and needed, but highlight issues and offer them to try out different ways to do so (there may be personal barriers for push-backers, so more “gentle” way may be less stressful while lead to the same result, e.g. instead of asking “Why you did not finish this task so far”?, try “What holds you back from completing this task”?
• Cultivate more solution oriented then problem stating approach (as solution is vector, while problem is scalar);
• Talk to entire team that problems are normal and ignoring them just postpones failure. So they require courage to face and team spirit to overcome, that makes difference between team and group of people. Exposing problem does not mean it shall become energy-drainer and de-motivator, rather it’s in-time red flag that shall re-focus team on next right thing to do;
• If conflict is unavoidable and your peers do not go with “exposing problems approach”, steer it, but not let pile it up (nice article on conflict avoidance here);
• Launch team storming to “shorten the distance” between team members, so that exposing problems is more constructive and easy (see: “Teamleads, “Storming”, Self-organization and Entropy”)
• Propose and drive team branding activity to help them find out shared values and motivators (see: “Team DNA: how to Brand up your team”);

To summarize, work both ways with ones who raise (also including you if you are in SM role) and with ones who push back to make raising problems comfortable and easy.

Good Luck!

Teamleads, “Storming”, Self-organization and Entropy

“To shape it, destroy it” Lao Tzu.

Recently I had a Scrum introduction for a small team of developers at my friend’s office. There were huge amount of questions I dealt with.  However one looked more challenging to handle: “How team of developers can work without team lead? How group of 5-7 people can be equally responsible for success?” Followed by “It simply will not work. You suggest to destroy everything. One needs to tell them what to do” statement.

Well  my immediate answer was: “Team needs to be formed and as soon as “one boat in ” unavoidable  storming starts that makes team glue and self-manage in most natural way, so that no specific role needed to tell them what to do”.

Afterwards this question lead to insights on how it would be easier to explain  self-organization and steps to get there to Agile newbies…

Old style symptoms

• What if group of people that just starts to work together does not want to glue, or it takes much time for them to form and come to storm?
• How to make them storm earlier and faster?
• What if you observe stand-ups when no one interested in what others did/up to and everyone report to Scrum Master?
• Silent (or 100% happy) retrospectives?
• People avoiding conflicts?
• Or you see how people with old-style mindset wait that someone will tell them what to do?
• Poor or no peer-management?

All these are the symptoms of no teamwork. These teams will unlikely deliver on time, having quality in.

As Ester Derby states: “Groups that avoid conflict won’t be able to face tough issues or handle the creative conflict that generates new ideas”.

Well, self-organization requires definite mind-shift, time and efforts. If that does not happen, team facilitators (coaches, scrum-masters) need to make them storm. Sometimes “throwing” team into storming helps here. Here is how.

“Throwing” team into storming

Here is simple, fast (and a bit harsh) way of doing it. Usually applicable when there is not much time to hit the deadline:

1. Take (or invent) the deadline. A bit less than realistic is fine. Needs to be challenging. That is easy, ‘cos business usually has them.
2. Make it clear when achievement considered as success and when it’s considered as failure, based on outcome.
3. Communicate the deadline and cultivate sense of urgency within team. Tell the team that business needs predictability;
4. Point out that all this matters if the outcome (product) is releasable;
5. Bind team objective with result  (and eventually a paycheck);

Observe hawk-eyed

Look what happens with forming stage team when it goes under pressure like this. It immediately starts storming.  It simply has to storm, otherwise it will be unable to realize their potential as a team and eventually will be closed down (I intentionally worsen things here).

This is pretty much like in physics. You increase “pressure” and the measure of disorder of the closed system, called entropy increases as well. Storming is kind of  disorder. The outcome of it however is the order.

That’s just beginning. Observe what happens further. Some people will start to manage peers. Some will invent norms. Others will start to call for those. Some will start to follow. Not all. Some. Some may become “Mavericks”. Others, resisting  “bad guys”.

Team starts storming. It’s hard, harsh, emotional, but normal and needed. It’s unavoidable step for team to really glue together, fit best way and become a TEAM. It’s the price to pay to get team on their path towards being truly self-organized and hyper productive.

As an Agile leader (or Scrum master) you need to observe this stage very closely and take care of conflicts to resolve them in the way to lessen distressing impact on team members. In short, – take care of people!

After a while you will figure out that storming goes down (although it never ends, just becomes more “constructive” and less hard to do) as your team starts to balance each other and  having some “roles”. It depends on individuals managerial skills, characters and combination of people in the team.

“The end” of Storming

I’ve seen team that ended up storming phase having several “team leads” (almost entire team) that managed each other. But compared to one formal team lead, they’re deserved and recognized leaders rather than formal authorities. Therefore, such a team is way stronger as managerial unit than a team having single and given team lead.

Let me explain that differently….

Several managerial roles in such a team are mutually complementing, since everyone manages some parts/aspects, focuses on different areas, sees picture from different angles that fits together naturally and keeps right balance between chaos and “autocracy”. Among other benefits of working together, self-organized team has an ability to compensate each other’s negative sides that allows them to become way better.  Rare person can compete with such a “balanced mix”.

That makes self-managed team stronger.

And my answer to the question in the beginning would be “YES”. At some point you need to destroy things to re-shape them.

Related articles

• Team DNA: how to Brand up your team
• TEAM: 7 indispensable ingredients for “Together Everyone Accomplishes More”