As a manager, what is my place in Scrum?
Scrum and the stakeholders, episode 2
The ‘Scrum and the stakeholders’ series discusses the place of several stakeholders in Scrum. All its articles have this theme and can be read on their own.
Introduction
Scrum knows 3 roles: Product Owner, Development Team and Scrum Master. People from outside the Scrum Team are addressed as ‘stakeholders’. On top of that the Scrum Guide mentions ‘committee’, ‘employees’ and ‘organisation’, but the umbrella term in Scrum is ‘stakeholder’.
Often stakeholders have no insight in what kind of role they can play. The series ‘Scrum and the stakeholders’ aims to clarify the place of the different stakeholders within Scrum.
Every Scrum environment is different, so there is no clear-cut answer that applies to all situations. Therefore we will discuss the different options to help you decide what is the best solution for you.
This article will discuss the manager who works with a team to achieve company goals.
There are all kinds of types of managers and many possible management layers. This all determines the place of the managers within Scrum.
The characteristics of a Scrum Team
“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.” — Scrum Guide 2017 Schwaber and Sutherland
A manager that is acting outside of the Scrum Team should keep this in mind. A directive management style does not fit with Scrum. Management best functions serving the team, rather than taking control. There’s already a servant leader role within Scrum that helps the team to use Scrum effectively (the Scrum Master). For other things that a team requires the manager could step in.
Life cycle of a Scrum Team
The Scrum Guide does not specify how Scrum Teams are formed, because this will differ greatly per organisation. However it is safe to say that management often is involved with forming the team and establishing the Scrum Master, Product Owner and the Development Team. I advise to follow an approach where self-organisation plays a big role. A nice example — where we formed multiple Scrum Teams — is the marketplace concept as described here:
During their life cycle the composition of the Scrum Team may need to change. Management can play a role to facilitate it, although I advise that the Scrum Team brings forward their requirements on this. This also applies for decisions to dissolve a Scrum Team.
Sprint Planning
The Sprint Planning is the event where the Scrum Team determines the Sprint Goal and the work to be performed to achieve this Sprint Goal. Managers can be present at the Sprint Planning, but they should know that as a stakeholder they do not determine the Sprint Goal or the Sprint Backlog. The Sprint Goal is determined by the Scrum Team and the Sprint Backlog by the Development Team. There is an event where managers could be involved in what to do next, impacting the next Sprint. This is the Sprint Review, discussed later.
Daily Scrum
The Daily Scrum is an event for the Development Team. This is the part of the Scrum Team that creates a potentially releasable increment of the product. At the Daily Scrum they plan the work for the next 24 hours. If others are present then they should not disrupt this event:
“The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.” — Scrum Guide 2017 Schwaber and Sutherland
Obviously this applies to managers too.
Sprint Retrospective
The Sprint Retrospective is an internal event for the Scrum Team (Product Owner, Development Team, Scrum Master) to inspect itself and plan for improvements. Scrum Teams address what went well, but also what needs improvement on people, relationships, processes and tools. This calls for an environment that allows them to feel safe to be effective. This is why this typically is no place for the stakeholder, which includes managers. But then again: the Scrum Guide does not state no-one outside the Scrum Team can be present at the Sprint Retrospective.
Many believe that managers should be present at the Sprint Retrospective — as a guest — so that they can get an understanding of what the issues are within a Scrum Team. I advise to be careful with this. The dynamics of a Sprint Retrospective can change and people might feel uncomfortable to discuss what they really feel. Although this is useful information as well it generally will make the Sprint Retrospective ineffective in the long run if this isn’t addressed. There are several ways to address it:
- the manager doesn’t attend the Sprint Retrospective anymore;
- the manager knows her/his place in a Sprint Retrospective and respects the outcome of this event.
Sprint Cancellation
In the early days of Scrum, managers were the ones who determined if a Sprint should be cancelled (when a Sprint Goal becomes obsolete). As soon as the Product Owner was introduced this changed. Now it’s the Product Owner who determines if a Sprint should be cancelled. Of course she/he will be doing this under the influence of stakeholders. And managers are a logical source of information that can result into cancelling a Sprint.
Refinement
Refinements exist to make Backlog Items ready to be picked up in a Sprint. It can be a good idea to invite stakeholders, like a manager, to clarify what is needed.
Sprint Review
Ever since the Sprint Review came to existence the managers have been prime stakeholders. If your organisation has management then this is most probably still true.
During the Sprint Review stakeholders help to determine what to do next. This is important information for the next Sprint Planning. As a stakeholder the managers typically will join the discussion about timeline and budget.
Outside of the Scrum events
There’s life outside the Scrum events. And there are all kinds of informal ways to interact with the Scrum Team. A manager may have a HR role towards members of the Scrum Team and might discuss with Product Owner and Development Team ideas for technical improvements on the product environment. How this is done all depends upon the Scrum Teams who choose how best to accomplish their work, as the Scrum Guide is not explicit about this.
The manager as a Product Owner
It is entirely possible that a manager is a suitable Product Owner, responsible for maximizing the value of the product resulting from work of the Development Team. Earlier versions of Scrum even specifically mentioned this as an option.
The manager as a member of the Development Team
It is also possible to have a manager as part of the Development Team to help build a potentially releasable product increment. This all depends on what is considered to be part of the responsibilities of the Development Team to build the product.
Also: you could have management Scrum Teams:
The manager as Scrum Master
The Scum Master is a servant leader of the Scrum Team. It is entirely possible that the traditional manager is replaced by the Scrum Master. This is one logical way to embrace self-organising teams, maybe even making them self-managing.
I do believe that the combination of traditional manager (with HR responsibility to the Scrum Team) and Scrum Master is difficult. Having a Scrum Master responsible for HR related topics adds to the responsibilities of the Scrum Master and these responsibilities aren’t complementary. In fact: they only will often complicate the relations between this person and Scrum Team members.
Conclusion — Discover your best way to involve your manager!
Scrum is suited for a wide variety of environments. Scrum is a framework with self-organising teams. There are many ways to implement self-organisation.
One Scrum Team could have more traditional managers, another Scrum Team may be self-managing with servant leaders only. Also: managers may be HR responsible only, but could also have a voice in where to go as a department. These are factors that determine the place of the managers within Scrum.
Managers are pivotal for the success of Scrum: they should help clarify why the organisation choose to work with Scrum and should lead by example. Managers should certainly not hinder self-organisation of the teams.
