How Managers slowly got removed from Scrum
Scrum then and now, part 11
The ‘Scrum then and now’ series discusses the evolution of Scrum per specific topic. All its articles have this theme and can be read on their own.
Scrum has been around for years. Jeff Sutherland and Ken Schwaber presented it to the world at OOPSLA in 1995. They based it on “The New New Product Development Game“ (1986) by Hirotaka Takeuchi and Ikujiro Nonaka.
Since 1986, many elements of Scrum have not changed at all. By contrast, some other parts of Scrum have continued evolving. With this series I aim to show you how radically Scrum has changed over the years, from 1986 to now. Through this I wish to achieve transparency on why certain ideas about Scrum materialised and help raise understanding on the current definition of Scrum.
“You have to know the past to understand the present.” — Carl Sagan
With this article, it is my goal to give you an overview of the evolution of (project) management’s role throughout the years. These roles used to be mentioned a lot in the early days of Scrum, but got removed from Scrum altogether.
The New New Product Development Game
The paper that started the ball rolling — ‘The New New Product Development Game’ — is very elaborate in explaining how management should approach teams with this new way of working. Here are some pivotal items:
“Top management kicks off the development process by signaling a broad goal or a general strategic direction. It rarely hands out a clear-cut new product concept or a specific work plan.” — The New New Product Development Game discussing “Built-In stability”
Here top management acts like a Product Owner before this concept existed. They bring forward what they wish to have achieved but will not tell how it should be done — which basically discusses another key aspect of Scrum: self-organisation.
“On a day-to-day basis, top management seldom intervenes; the team is free to set its own direction. In a way, top management acts as a venture capitalist. Or as one executive said, “We open up our purse but keep our mouth closed.”” — The New New Product Development Game discussing “Autonomy”
Here Hirotaka Takeuchi and Ikujiro Nonaka emphasise that the team is autonomous with no day-to-day intervention of top-management. Again they point out how the new way of working impacts management. Management does not give up control completely:
“Management establishes enough checkpoints to prevent instability, ambiguity, and tension from turning into chaos. At the same time, management avoids the kind of rigid control that impairs creativity and spontaneity.” — The New New Product Development Game discussing “Subtle Control.”
But this is a different type of control. It is to make sure that the teams that work autonomously are working on the right kind of thing. It’s to assess if the team is going in the right direction and to get everyone on the same page — the precursor of the Sprint Review.
The first Scrum paper — 1995
With the OOPSLA paper in 1995, Sutherland and Schwaber introduced their own adaptation of Scrum. Here management was part of what was called the SCRUM Control Team:
“Management: Led by the Product Manager, it defines initial content and timing of the release, then manages their evolution as the project progresses and variables change. Management deals with backlog, risk, and release content.” — Ken Schwaber 1995
Note that the Product Owner still didn’t exist. This explains that management — led by the Product Manager — deals with what is to be built and with the (product) backlog. Management of risk is also interesting to bring forward. Nowadays one of the main reasons to use Scrum is to control risk by having an iterative and incremental approach. This was not addressed like this in 1995.
Management also determines when to release features:
“When the management team feels that the variables of time, competition, requirements, cost, and quality concur for a new release to occur, they declare the release “closed” and enter this phase.” — Ken Schwaber 1995
Here again management does the job of the future Product Owner, by determining when to release a set of features.
First Scrum Book 2001
First interesting note from the book “Agile Software Development with Scrum” is the following:
“The Scrum Master represents management and the team to each other” — Ken Schwaber and Mike Beedle 2002
Besides the fact that this is in no way an easy role it also brings forward that management doesn’t have a direct influence on the team. The Scrum Master is the person “in the middle”. That doesn’t mean that management has no role to play. On the contrary. Management is mentioned quite often.
The first Scrum book brings forward that a Team Leader, Project Leader or Project Manager often assumes the Scrum Master role and then brings forward:
“It’s likely that many impediments will have to be initially removed, this position may need to be filled by a senior manager or a Scrum consultant” — Ken Schwaber and Mike Beedle 2002
In 2002 the Scrum Master hasn’t yet fully evolved into a coaching role as it is now. This is why the step from Project Leader or Project Manager to Scrum Master made a lot of sense. Now the Scrum Master role is dramatically different. For more on the transformation of the Scrum Master role, click here.
The book also has the following roles for management:
- Management, the customer and the Scrum Master identify and institute a Product Owner.
- Management and the Scrum Master form the Scrum teams. “Scrum team” is a confusing term and therefore later renamed to “Development Team”. For more on the evolution of the Development Team, click here.
- By listening carefully during a Daily Scrum management gets a sense of what’s going on. But as they are not part of the Scrum team they should not speak up.
- During Sprint Planning management is one of the parties to help determine the Sprint Goal (as are customers, users, the Product Owner and the Scrum team). The Scrum team then determines what work will have to be done and creates the Sprint Backlog.
- During the Sprint Review management comes to see what the team was able to build with the resources provided. Users, customers and other stakeholders also participate in the Sprint Review.
- Management is one of the parties that may need to cancel the Sprint when the Sprint Goal becomes obsolete. The Scrum team (the 2002 name of Development Team) can also cancel the Sprint.
First edition of Scrum Guide — 2010
Some practices that were described in the first Scrum book are still presented in the first Scrum Guide. As a tip it repeats that management, together with the customer and the Scrum Master, may instantiate a Product Owner.
There’s another tip involving management too: the Product Owner role may very well be played by a department manager (for in-house development efforts).
There are some important changes since 2002 though:
- It’s now the Product Owner that is allowed to cancel a Sprint, although one of the reasons can still be that management determines that a Sprint Goal becomes obsolete.
- Management isn’t specifically mentioned as participant for any Scrum event. Instead the Scrum Guide now talks about ‘stakeholders’ (Sprint Review) or doesn’t mention them at all (Sprint Planning, Daily Scrum).
Second edition of Scrum Guide — 2011
One year later there’s no mention of management or project leader anymore, same with references to customers. The Scrum Guide sticks to three roles (Development Team, Product Owner, Scrum Master) and mentions stakeholders.
The current Scrum Guide still has no mention of managers. They may or may not be stakeholders of the Scrum Team. If an organisation has managers, then they probably are. However Scrum is a framework that can be used in any environment, which includes environments without managers.
Conclusion — from manager to stakeholder
Hirotaka Takeuchi and Ikujiro Nonaka were the ones that brought forward the initial ideas of Scrum back in 1986. In 1995 this idea was adapted and brought to a larger audience by Jeff Sutherland and Ken Schwaber. Scrum was a totally different way of working in the mid-nineties, so it is quite logical that this needed to be elaborated in quite some detail. One of the things that needed to be emphasised was the changed role of management. Hence the authors did cover quite some ground to clarify the differences and the impact that Scrum made on traditional organisations.
Also: the Product Owner didn’t exist in early Scrum and management essentially had a Product Owner type of role in those days.
Since the early days there has been a trend — truly starting with the second Scrum Guide — to strip anything that didn’t touch the essentials of Scrum. This is why any reference to management was removed. Management now fits in the term ‘stakeholder’.