Product Management and the 2020 Scrum Guide: Free at Last
Introduction
It was not the introduction of the Scrum software development method in 1995 or the authoring of the Agile Manifesto in 2001.
The turning point was the publication of the "Agile Software Development with Scrum" book by Mike Beedle and Ken Schwaber, in 2002.
This book linked Scrum together with the Agile Manifesto and commercial software development. Soon after publication, interpretations that the Scrum Product Owner role is related to or is an alternative to the Product Manager role began to appear.
This review outlines why product management is unrelated to Scrum, disassociates the Product Manager role from Scrum, and describes how recent changes to the 2020 Scrum Guide support this separation.
Scrum and American Football
American football is the most popular sport in the USA, and Scrum's concepts are very similar to American football's concepts.
Founded circa 1860 and patterned after the game of British Rugby, American football is a competitive team sport.
The game's objective is to win by accumulating game points awarded through progressively advancing an oval-shaped ball in a series of stages called Downs towards the rival team's end-zone (scoring area).
Downs in American football are short, time-limited point-scoring periods in which players are sprinting (running fast) with the ball to the rival team's end-zone.
In Scrum, Sprints are the equivalent time-limited point-scoring periods to Downs.
Various Time Restrictions apply to Downs, with the Down itself being time-constrained to complete a play. In Scrum, the idea of time limitations to complete the Sprint work is called a Timebox.
In American football, each Down is managed by an on-field tactical leadership role, the Quarterback, who prioritizes play options and decides which play to make to maximize the number of game points possibly achieved in a Down.
In Scrum, the Product Owner manages the Sprints and prioritizes the work and product features to maximize product gains, as the Quarterback manages the Downs.
In American football, the Football Coach is an authoritative figure who instructs, motivates, and inspires the football team. The football coach owns the master game plan and promotes the game's values and rules of play.
In Scrum, the Scrum Master is the corresponding role to the Football Coach.
In American football, the Football Coach works directly with the Quarterback, and this type of close synchronized relationship is not found in any other major sport. The corresponding relationship in Scrum is between the Scrum Master and the Product Owner.
The American Football Team comprises three entities: Quarterback, Football Coach, and the Players Team.
Correspondingly, the Scrum Team comprises three entities: Product Owner, Scrum Master, and the Development Team.
In American football, the Players Team is the group of individuals, physically on the football field, playing the game and scoring points.
The Players Team is self-organizing with each Down and cross-functional with various players owning different specialized skills (offensive, defensive, and kickers). There are no sub-teams, and all players are equal in the effort to win the game and equally accountable to the game's outcome.
In Scrum, the Development Team's characteristics (self-organizing, cross-functional, etc.) are very similar to the American football's Players Team.
In American football, there was no Team Captain role until 2007. Scrum was introduced circa 1995, which could reasonably explain why a Team Lead or Team Manager role is not included in Scrum.
The American football's Players Team engages in many on-field huddles, sideline gatherings, and locker sessions, essentially short Meetings, frequently conducted while standing up.
In Scrum, the corresponding is Ceremonies, essentially short meetings conducted by the Development Team while standing up.
Many pre-existing terms are renamed in Scrum.
For example, in Scrum, Documents are relabeled as Artifacts; Postmortems are relabeled as Retrospectives, Meetings are relabeled as Ceremonies, and so on.
Virtually all of Scrum's ideas of empiricism, transparency, adaptation, iterations, prioritization, etc., can be explained in the context of American Football.
In American football, Stakeholders are three groups with a vested interest in the game and constitute the Club Owners, the American Football Team, and the Spectators.
Included in the Scrum Guide but not explained, Scrum's comparable Stakeholders are interpreted as the Company, the Scrum Team, and the Customer.
In American Football, the Football Coach can often be seen holding a specialized Football Coaching Playbook, also referred to as a football coach's Notebook, Handbook, Organizer, or Notepad.
Originally printed on paper and held by a clipboard or spiral-bound, today's NFL coaches use a tablet with a special playbook software.
The Football Coaching Playbook is a general repository that contains anything about the game, including play sheets, statistics, dates, player information, special notes, to-do lists, and more.
In Scrum, the Product Backlog is the general repository for anything about the product, similar in purpose to American football's Football Coaching Playbook.
Five core Values morally guide the players of American Football and British Rugby, and similarly, Scrum also claims five core values.
American football's original five core values were Excellence, Commitment, Integrity, Courage, and Respect. Sometime after 2017, modified core values were introduced by the American National Football League (NFL).
According to ScrumAlliance.org, Scrum's five core values are Commitment, Courage, Focus, Openness, and Respect.
Both American Football and Scrum share three core values of Commitment, Courage, and Respect.
Owing to all the similarities, the likely conclusion is that Scrum was modeled after American football in an attempt to shape a collaborative team effort to build software.
Scrum Popularity
- Is Scrum a proper or wrong way to develop commercial software?
- Should American football, a contact sport, be the basis for a software development method?
- Would a non-contact team sports game be a better model for Scrum?
- Should an Individual sports game be the basis for a software development method for the individual programmer?
- Are sports games of any sort a sound basis for a software development method?
The answers to these questions and many others are important for the collective discussion but are practically no longer relevant.
Scrum is already firmly ingrained into companies and contemporary software development. And it has done so for at least 15 years.
Scrum is popular and enjoys widespread support from loyal and enthusiastic followers. About 70% of software teams worldwide use Scrum or some form of a Scrum hybrid.
The vast range of books, articles, blogs, and online discussions about Scrum keeps growing. Philosophical writings in search of theory, deeper meaning, or how to get Scrum to work are a daily occurrence.
Many companies and individuals provide training, consulting, certification, and implementation services related to Scrum.
Thousands more are employed in Scrum roles at all sorts of companies, and there are plenty of Scrum-related job openings on the market.
Atlassian, a multi-billion dollar Australian software company, has been very successful due to Scrum's popularity, which is used with Jira, Atlassian's main product.
Many practitioners are drawn to Scrum's simplicity. They believe in Scrum and identify with its values. Some are emotionally, almost religiously, invested in Scrum.
Others are drawn to Scrum openness to express their thoughts on software development and make a name for themselves by analyzing and explaining different aspects of Scrum.
The Scrum Guide has become a primary go-to source for Scrum proponents, the place where answers to most any software development questions are found, with people referring and quoting the Scrum Guide as the definitive source.
Scrum Criteria and Guidance
Scrum proponents say that Scrum is intentionally unclear and incomplete.
The argument is that all the missing descriptions, definitions, or explanations from the Scrum Guide are purposefully left out.
They explain that Scrum provides the framework but is purposefully insufficient to deliver products. It is up to the practitioners to complete Scrum's missing parts, all of the various processes and techniques required to develop a product.
To implement Scrum, one is forced to interpret terms and meaning from the Scrum Guide, in addition to supplementing Scrum's missing parts.
Paradoxically, Scrum thrives from being unclear. Vagueness allows for countless interpretations that could fit different people's situations and opinions.
Vagueness permits people to generate any Scrum interpretation they want to agree with. Ambiguity also contributes to Scrum being so widespread.
This vagueness has created an entire commercial industry of companies and individuals that interprets Scrum and helps implement it.
This industry zealously promotes Scrum as a method that works and detracts any dissenting or contrarian views.
Scrum proponents assert that Scrum's promise to deliver "Twice the Work in Half the Time" is realistic, but the benefits can be obtained only if all of Scrum is implemented. They say that partial benefits will not be achieved if Scrum is partially implemented.
But Scrum lacks methodological guidelines or foundation rules. Scrum has no internal mechanism to point out how to complete Scrum's gaps correctly.
Scrum's lack of methodological guidelines opens up a broad scope of interpretive possibilities without any methodological foundation. Consequently, Scrum interpretations are full of personal qualifiers: I agree, I disagree, In my opinion, In my experience, and I believe, I feel, and I think.
The result is that without any criteria and within such broad parameters, any Scrum interpretation cannot be objectively judged as "wrong" or "right".
In the absence of guidelines to resolve conflicting Scrum interpretations, Scrum practitioners scan the latest available Scrum Guide for a supporting quote or word, parsing it for purpose.
Or they do a word-count of a particular term, hoping that a higher frequency would signify some meaning.
With so many conflicting interpretations, a particular interpretation is often accepted if a majority agrees with it—an unofficial vote.
However, Scrum Guide interpretations have not been confined to Scrum and software development. They have also been extended to product management.
Claims that the Scrum Product Owner role is related to or is an alternative to the Product Manager role were made, overwhelmingly by people selling Scrum services.
Such claims undermine product management's professional identity and adversely affect perceptions of product management. They also detract from the strategic contribution product management can make by diverting or distracting it.
Scrum will not disappear anytime soon, so it's important to disassociate the Product Manager role from the Scrum Product Owner role and from Scrum.
The recent changes to the 2020 Scrum Guide are instrumental in making the distinctions.
Scrum and Product Management
The Product Manager role never appeared in any of the Scrum guides, which were published over a period of 10 years.
None of the Scrum guides contain information on how Scrum views or defines product management or the product manager role.
None of the Scrum guides explain if Scrum is associated with product management or how Scrum roles interface with the product manager role.
The 2017 Scrum guide has a single mention of Product Management in a promissory statement:
"Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment."
One Scrum interpretation of this statement is that the single mentioning of product management in the Scrum guides is sufficient to make a case and means that Scrum and product management are associated.
However, the aforementioned statement is gone in the new 2020 Scrum Guide, published November 2020.
A generic and broader promise replaces it:
"Scrum makes visible the relative efficacy of current management, environment, and work techniques so that improvements can be made".
Subsequently, the terms Product Manager and Product Management are nowhere to be found in the 2020 Scrum Guide.
By the same token and with reverse logic, a legitimate interpretation should now be that the absence of any reference to product management in a Scrum Guide means that Scrum and product management are not associated.
Another quoted statement from all Scrum guides is that "The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team."
Based on this statement, another Scrum interpretation was put forward, which assumed the product manager also maximizes value, and therefore, the product owner and product manager roles are similar.
The notion of maximizing value as a goal comes from the Scrum guides, not from the product management domain.
None of the four different schools of thought in product management consider maximizing or optimizing value as the product manager's and product management's stated objective.
None of the Scrum guides explain how Scrum views or defines value, what product management is, nor how value is tied to the product manager role or product management.
Value, Relative Value, and specifically Resultant Value are the outcome of efficiently solving market problems. They are by-products, not objectives.
The value concept, value formula, relative value, resultant value, and their application in product management and product marketing are detailed in the “Value-marketing Model” chapter, page 63, in the PMTK Book: Second Edition.
The Quarterback is responsible for maximizing game points by prioritizing play options for each Down.
In American football, the Quarterback is responsible for maximizing the number of game points resulting from the effort of the Players Team. Maximizing game points is made through prioritizing play options for each Down.
The Quarterback role is similar to Scrum's Product Owner role which maximizes product gains, resulting from the work of the Development Team, by prioritizing the work and product features for each Sprint.
Another Scrum interpretation argues that the Product Owner role requires product management skills. Therefore, both roles are similar if the Product Manager and Product Owner require product management skills to do their job.
However, within the Scrum community itself, there is no consensus on what product management is, let alone deciding on the required product management skillset.
Another Scrum interpretation holds the Product Owner role as the true and only Owner of the product, an encompassing and aggregate role with the most responsibility. Therefore, the Scrum Product Owner role replaces the Product Manager as the product's real and sole owner. This reasoning is based on linguistically parsing the word Owner.
Some Scrum interpretations, based on similar-sounding titles, claim that the product manager and product owner are related because both are "product people".
In conclusion, all the Scrum interpretations that attempt to associate Product Management with Scrum, and Scrum Product Owner role with the Product Manager role show the same common traits.
All the Scrum interpretations that try to connect Scrum to product management are superficial, rely on parsing words only from the Scrum Guide, and disregard product management theory.
All interpretations that connect Scrum to product management are being promoted exclusively by Agile/Scrum people, not by product managers.
2020 Scrum Guide
The Scrum Guide self-proclaims Scrum as a Framework.
The various Scrum Guides provide many details on roles, processes, deliverables, procedures, interactions, rules, values, etc.
Accordingly, counter-arguments were made that Scrum is too prescriptive to be regarded as a framework, but rather is actually a software development method.
Hypothetically, if Scrum were considered a method, Scrum would be deemed an impractical broken method given its incompleteness and unclearness. This possibility has harmful brand implications and has to be reconciled.
In the background, the Agile commercialization movement seeks to expand its market by attaching "Agile" to anything. Agile marketing, Agile procurement, Agile business, Agile recruiting, Agile human resources, Agile accounting, Agile anything… Scrum's authors want the same for Scrum.
In response, the 2020 Scrum Guide is claimed to be simplified, generalized, and less prescriptive.
This seems to be a conscious effort by Scrum's authors to bring Scrum closer to being regarded as an actual framework, not a method, and simultaneously broaden Scrum's applicability and potential market reach beyond software development.
Subsequently, all references to Information Technology (IT) and software development elements were removed. Many concepts and terms, including Development Team and Product Management, are now gone from the 2020 Scrum Guide. There are additional nuances.
The 2020 Scrum Guide contains further changes about accountability, product goals, sprint goals, one team, lean, and optimization.
About Lean Software Development, the term Lean did not appear in any of the previous Scrum Guides. The 2020 Scrum Guide was updated with a statement that "Scrum is founded on empiricism and lean thinking".
It is possible that this statement was included in the 2020 Scrum Guide as a me-too move to match Scaled Agile Framework (SAFe), which for some time has claimed to support Lean/Agile principles.
The term Development Team was removed and replaced with Developers in the 2020 Scrum Guide. This instantly brought on a Scrum interpretation that Developers are not only computer programmers, but also anyone else related to the product, such as people from accounting, marketing, legal, etc.
So anyone now deemed as belonging to Scrum's Developers category needs to know Scrum and be considered a potential training and certification candidate. This interpretation is a bit of a stretch. The economic motivation is obvious.
The release of the 2020 Scrum Guide was met with mixed feelings by Scrum proponents and practitioners.
There were excitement and praise. There was also bewilderment, disappointment, and confusion.
There were also those eager to rush to analyze, interpret, and explain with great confidence the recent changes made to the 2020 Scrum Guide.
There is early talk of initiatives to create independent splinter variants of Scrum, which will be based on "traditional" Scrum but incompatible with Scrum as it is currently outlined in the 2020 Scrum Guide.
The 2020 Scrum Guide is only 13 pages in length. Six pages shorter and 3,000 words less than the previous 2017 Scrum Guide.
Consequently, some argue that with even less information in the 2020 Scrum Guide, the Scrum body of knowledge is now even more unclear and incomplete. Others say the Scrum Guide has been streamlined, and the conciseness is for the better.
All this is unrelated to product management, a bystander among other bystanders to the struggles and regular upheaval in software development.
Strategic Product Management
At the very core of the Blackblot PMTK Methodology™, a market-driven product management methodology, are two foundation rules which govern the entire methodology:
- PMTK Rule #1 — Product management comprises product planning and product marketing.
- PMTK Rule #2 —Product management resides solely in the problem space.
In PMTK, the Product Manager is a highly strategic role in the problem space, responsible for managing the market problem that the product solves.
The Product Manager seeks to gain market expertise and is responsible for making far-reaching decisions that shape product planning and product marketing activities.
In PMTK, the market problem (what needs to be solved) is owned by product management. What to build as a solution and how to build it is owned by product development.
The problem and solution spaces designate the separation between product management and product development. An efficient communication and collaboration interface between the two domains is implemented without encroachment or overlap.
PMTK Rule #2 voids the Product Manager from assuming any roles and activities in the solution space, in product development.
Conversely, PMTK Rule #2 voids the Scrum Product Owner from assuming any roles and activities in the problem space.
The PMTK methodology establishes that roles have responsibilities only in one space.
Accordingly, the Product Manager cannot be related to or replaced by the Scrum Product Owner or any other software development method role in the solution space.
The Product Owner role is an anomaly reserved for Scrum. The attempt to pull product management from the problem space into the solution space, into the product development domain, is a unique situation reserved for Scrum.
The logic and rationales behind the Blackblot PMTK Methodology™ and its foundation rules are explained in the What is Product Management? video and the Definition of Product Management — Blackblot PMTK Book Chapter.
The Blackblot PMTK Book: Second Edition is the authoritative guide to market-driven product management.
Scrum's Future
Scrum is being increasingly challenged by other scaling and Agile software development methods.
Scrum is enduring much critique and discussions of its limitations.
Depending on the reports and sources, over 70% of Scrum implementations fail. Scrum proponents claim these failures are because of "Bad Scrum" or "Zombie Scrum", a euphemism for a failed Scrum implementation due to not following or understanding or applying Scrum correctly.
Reading the Scrum Guide gives the impression that opinion and belief are all that is needed to make a case. Cogent rationales, logical arguments, and thoughtful explanations are wholly missing from the entire Scrum Guide.
All of Scrum's high-level rhetoric, general advice, and promises quickly exhaust themselves. Product development requires definitive answers, the kind that is not found in the Scrum Guide.
Answers provided through the myriad of Scrum interpretations can lead to trial and error experimentation in search of a solid product development process. Companies cannot afford that.
Scrum's vagueness is exploited by the more detailed and voluminous Agile software development methods, particularly the scaling type, who position themselves as lacking the need for endless interpretations. The Scaling Agile methods are increasingly challenging Scrum's hegemony.
This could explain the growing popularity of SAFe (Scaled Agile Framework) and DAD (Disciplined Agile Delivery) methods, which are highly prescriptive. Both are a vast collection of Agile practices with roots in the veteran Rational Unified Process (RUP).
But too many people and companies are already heavily invested in Scrum. There are strong financial interests, and Scrum's depletion of product management competencies at many software companies prevents putting this matter to rest.
Scrum is an [intentionally?] unclear and incomplete software development method that lacks foundation rules and is modeled after American Football.
But what Scrum is, does, or lacks, does not matter anymore. Scrum is entrenched in many people's minds and the companies' development workflow.
So Scrum is not going away, but its future lies in the balance.
Summary
Published in 2014, the Origins of the Product Manager vs. Product Owner Dilemma article was the start of Blackblot's information campaign to disassociate product management from Scrum.
Multiple posts, articles, lectures, social media discussions, and invited talks at conferences on this subject would follow.
Email messages were sent to Scrum organizations and advocates, seeking to decouple any notion of product management from Scrum.
The original thought was that a better understanding of strategic and market-driven product management's methodological foundations would promote an understanding among Scrum proponents that the Product Manager and the Scrum Product Owner roles have nothing in common. This thought was proven wrong.
The information campaign has only successfully proved that logic and education are ineffective when people follow religious fervor and economic interests.
The time has come to rebuild the identity of strategic product management that existed before Scrum, but this cannot be achieved by perpetuating a misdirected information campaign that is finished, as far as this author is concerned.
The time has come to look forward to an agenda that promotes clarity in all aspects of product management among product managers, not among Scrum proponents.
Blackblot's information campaign has shifted to help product managers regain their professional identity and focus through principles and rationales, not opinions or beliefs.