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 🙂

Getting them on it right: focus, energy, commitment and motivation

“Problems cannot be solved by the same level of thinking that created them.” Albert Einstein.

I was about to write another one in the scope of “Getting them…” targeted for Product Owners (PO), however thought that before getting them (stories) out of the sprints it is crucial for sprint success how to get them (team members) on it right…

So story going to be about how PO influences team focus and instills feeling of urgency and what happens if he/she’s not…

To understand this we would need to get back to Sprint Planning meeting (SPM). When PO makes final accords, accepts team commitment and sends team out to the sprint it is very important for everyone to stay focused on the Goals PO presented.

If PO jumps in mid-sprint, having unplanned acceptance criteria, special circumstances, etc… this sends a message: goal is void, direction is being changed, things that had been agreed at SPM are not valid anymore.

Scrum is tense way of delivering software. Constructive tension comes from high commitment and builds up high velocity (aka deliver fast lean principle) that is impossible to achieve without addressing limited and fixed number of issues within timebox.

Let’s understand how this works…

Higher velocity is achieved by staying focused on what is most important. As soon as this vector changes, something that had been important yesterday, becomes less important today, or something else emerges focus drifts away.

But velocity is not single thing this impacts…

More drastic effect this has on team morale, since besides team has to conduct context-switch (that has it’s own impact: see another related post here), but also it throws team into “Less” vicious circle that is:

• Less focus that eats up energy and leads to …
• Less energy that impacts productivity and leads to …
• Less commitment that impacts desire to work and leads to…
• Less motivation that drain attention and lead to …
• Less focus …
• Etc …

Understanding this will help PO to plan sprints in the way to avoid de-focus, protect sprints from interference (and team members from de-focus) and minimize impact of unplanned issues.

Of course fire-fights happen, of course they are important, but it makes sense to dive in root causes and build real quality in rather than fight consequences… and eventually turn circle back into “More..” :).

Team DNA: how to Brand up your team

“People like talking about people. Makes us feel superior. Makes us feel in control.
And sometimes, for some people, knowing some things makes them care.” [HouseMD #113]

As described in earlier post in “TEAM: 7 indispensable ingredients for Together Everyone Accomplishes More” one of the key elements of a strong team is Brand.

An idea to apply known brand-building practice to team management seemed to me interesting and made me write this blog post.

So I would like to cover a useful tool that can be applied to build up your team brand…

Team Brand is essential team motivator that cannot be given to the team (by company, management, money, etc.), it needs to be build inside, owned and maintained by the team. Actually this is type of “achievement” and “idea”-motivator for a Team (here cross-functional, self-organizing teams are meant, although practice is applicable for any team of small size).

In other words, Team Brand serves as an alignment on its core values/ways to achieve, inspires team by having strong and challenging core set, while distinguishes team among others.

Team brand may be built as any corporate brand starting from key cause or a purpose, moving from core through the benefits (qualities, values) to attributes (tools, norms) supporting and transmitting them.

Well, but an agile self-organizing team needs a hint  to start thinking of themselves as a “company”, having a “brand”. A hint that envisions this mind shift would sound like:  think of your TEAM as of an entrepreneurship and your collaboration as of an inspiring challenge! Imagine you’re running business with your peers (which is not that far away from reality, considering self-organized  development team doing SCRUM).

There are 3 questions to be addressed then by Team members together to get an alignment on:

1. WHY are we here, what we want to achieve together, what is our core, our strongest believe and our purpose? Why do we exist as a TEAM? Which core value we all share?
2. HOW we can make this happen? What principles (benefits, qualities) support this?
3. WHAT we exactly will do (and will NOT tolerate) to support each of the key principles we’ve agreed upon that contribute to our purpose?

A tool I recommend to use at this step to create and maintain team DNA is known “Team Radar” retrospective facilitation activity (see “Agile Retrospectives: Making Good Teams Great”  by Esther Derby and Diana Larsen for detailed explanation).

It simply suits best  this exercise.  Here it is used to gather data on team itself and perform self-assessment in the future.

An outcome applying this practice to an Agile self-organizing team may look like this:

As soon as agreed Team DNA is documented, printed out and placed in visible area (ideally at the team scrum board and/or also very usefull in retrospective room). This will serve as a point to refer/remind when choosing for right decision/action and will keep team motivated to comply everything they think, decide and do with their core.

But this “artifact” shall not be “curved in stone”. It’s living, since team is also living. So on and on reviewing it, team curves itself, making their brand stronger and more unique, by finding out deeper levels of their own common values, purposes, beliefs  and means, achieving them.

The more team does so, the more it finds it’s own distinctive way doing things and becomes more distinguished (“branded”) and valued by managers, stakeholders, POs, etc…

Good teams that value the way they perform and look, care about this and move further finding out more challenging cores, supporting principles and norms.

Besides that it’s a funny collaborative action that contributes to team building.

Brand up your Team, guys 🙂

Further reading/sources:

• “How to Build and Manage Your Brand (in sickness and in health)” ebook
• “Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))” by Lyssa Adkins
• “Branding Governance: A Participatory Approach to the Brand Building Process” by Nicholas Ind and Rune Bjerke.

How long does it take us to context switch?

Came across an interesting study (Quality Software Management: Systems Thinking by Gerald M. Weinberg) that draws relation between number of tasks in progress and time wasted for context switch.

Self-explanatory:

So if you are running two projects (do two tasks) paralleled, waste caused by brain context-switch is 20% (and you’re able to use effectively only 80% of your time), for three it’s getting worse – 40% wasted (only 60% used), etc…

The mechanics behind are simple: according to psychiatric studies when our brain is juggling different tasks, it is also trying to arrange focus and attention to those tasks. Therefore when we attempt to perform two complex cognitive tasks, the brain must shift its focus to manage one task at a time. This process is identified as “reaction-time switching costs” and represents a measurable period of time in which the brain is moving its focus from one task to another pretty much as computer’s CPU does.

The other consequence is that we get tired earlier, since switch itself eats-up brain energy and we are not able to do 100% switch (we’re not CPU, we’re humans!), so it is more like having main part of brain focused on one task, while some small part of it still stays with next (past) one.

All this makes limiting WIP (work-in-progress) vitally important to both productiveness and human health.