Is Scrum as a process heavy and dependent on too many factors?

Maciej Jarosz

·

Follow

15 min read

·

Jan 3, 2023

--

Listen

Share

Short introduction — there are countless articles on the Internet about why the Scrum process called framework “fails”.

I will decompose the whole process into its components and further break down those components into their composite parts.

Within this article, I will focus on the literal meaning of any particular part of the Scrum Guide 2020 November accessed here — https://scrumguides.org/scrum-guide.html

Win/fail criteria

There are no objective criteria that would unambiguously state whether the Scrum process is working properly or not.

Scrum cannot win/fail on its own as it is a process that is a particular combination of components consisting of composite elements and when not enough of those composite elements work then the whole process may be either suboptimal or not working at all.

By extension, once the components of a process and composite elements of components are identified and measured against their own respective criteria of success/failure, KPIs, and other metrics then it becomes clear that Scrum as a process is very heavy in weight, hard to monitor properly, easy to jump to false positive/negative conclusions and is dependent on many external components over which Scrum components have no control nor agency.

The breakdown into components and composite elements

For the sake of clarity, here is the description of Scrum process components:

• values
• roles
• artifacts
• events
• extremities & interfaces with other entities in the broader context of the company

What follows is a further breakdown of those components into their respective composite elements with a commentary:

Values

• Values per se are abstract nouns that describe a particular behavior or an attitude of a person and there are no objective criteria to judge whether a person is for example courageous or acting without a second thought.
• By inversion, it is possible to map extremities and create an ordinal scale with subjective criteria to assess whether a person shows some traits from that scale, as we can subjectively say that a person XYZ is courageous according to our criteria but we cannot state how many quantifiable points of “courage” such a person has.
• Pairs of nouns with their inversions (antonyms) are as follows. I have marked an antonym with “?” where there was no clear antonym IMO:
  - commitment <> indifference,
  - focus <> chaos?,
  - openness <> closeness,
  - respect <> disrespect,
  - courage <> cowardice?
• Thus assuming that every Scrum process participant needs to have at least one of those positive “values” and none of the negative ones it may be clear to assume that it may be quite hard to have for example 40 people with at least one of those positive “values” while at the same time having none of the negative “values”.

Roles

• Three roles — Developers, Product Owner, Scrum Master
• While the description of the Developer role is the shortest one it is by no means a clear description with having additional four points that such people would need to follow to make this Role component with composite part of developers working at an optimal level.
• Product Owner — the description of the role is quite long with many conditions that if falsified can lead to a suboptimal work of this particular composite element of the Roles component in the Scrum process.
• As a curiosity there may be a logical loophole with the “may do the above work or may delegate the responsibility to others” without mentioning what kind of “others” entities it is referring to. Can any of the accountabilities be delegated to e.g. Scrum Masters which will be in contradiction to Scrum Masters accountabilities with the “The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide” passage? How to break this loop without manually overriding how the component or composite element works?
• Scrum Master — as with Product Owners the role is heavy in description and full of conditions that once falsified can lead to a suboptimal working of this particular composite element of the component of the process.
• The roles of Product Owners and Scrum Masters are vaguely defined, interpretable, and not logically coherent. Given that one would like to map those conditions on a flowchart and map interactions then at least some of those would be in contradiction to each other with no criteria on how to escape the loop as with the above example of delegation vs accountability for establishing Scrum as defined in the Scrum Guide which states that one party can delegate the work to the other party but at the same time the other party is accountable to do things that may be in contradiction to that delegated work. Of course, people would need to have a conversation about how to solve such contradictions, yet it should be clearly stated in the Scrum Guide who has the authority to solve such contradictions.
• Of course, there are also other composite elements that can be identified such as — skills with the potential breakdown into skill categories, knowledge with the potential breakdown into knowledge categories, practices and practices categories, support processes, etc. as the list can be as long as one wants to create.

Artifacts

• Product Backlog — the description of the product backlog seems clear. Where things start to get interesting is the product goal sub-composite element of the product backlog.
• According to the Scrum Guide, there may be only 1 product goal at any given time, and any change needs to remove the previous one to introduce a new one. Product management & development may not be so linear in many cases (which the PMTK methodology by Gabriel Steinhardt describes in detail) and changing goals too often will ultimately lead to chaos and confusion. Also by extension of the Scrum Master role definition it is Scrum Master who is accountable for establishing that there is only 1 product goal at any given time. Thus taking into consideration the above opinion on product management & development the Scrum Master role is put into an unstable place where one is accountable for things that may not make sense in any given context or be plainly proven bad practices.
• Sprint Backlog — the description contains 3 sub-composite parts to this composite part — Product goal, some product backlog items, and some kind of a plan on how to deliver those product backlog items during a sprint with the plan needing to be “highly visible, real-time picture” plus “updated throughout the Sprint as more is learned”. That is quite a lot of additional conditions to take into account, and when one of those additional conditions is falsified it may lead to a suboptimal work of the component of the process which in turn may result in a suboptimal work of the process itself.
• Another curiosity is the Sprint Goal — described as a singular objective for the sprint and also a commitment by developers, its scope also can be changed at any time as a combined effort of Developers and Product owner roles.
• Increment — description of the increment is clear with two additional conditions — one is that an increment may be delivered to stakeholders/customers before the end of the sprint and the second one is that it needs to conform to the Definition of Done.
• The definition of Done is where things get tricky. While the description is clear the implications are not so clear. It is assumed that someone creates the definition of done, a logic gate check of sorts, at an organization level while if there is none then the whole Scrum Team creates one as fits the product that they are working on. Multiple teams may have various definitions yet when they work on a single product they must have a uniform definition of done unless provided by a company as a standard. In my opinion, it is a problem of a one size fits all idea versus the real-world intricacies of managing and producing a product in at least some domains.

Events

• Sprint — the description is in my opinion coherent and clear. Let’s take a look at some elements of the description. “In complex environments, what will happen is unknown” this can be outright falsified in reference to TRIZ trends of system evolution. “Only what has already happened may be used for forward-looking decision making.” — this is a nice and useful reference to data-driven decision-making. “A Sprint could be canceled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.” — this one is interesting as I have never seen a sprint canceled. Plus it may be possible that the Product Owner wants to cancel the sprint yet for some reason it is overwritten then as a logical cause & effect of the following of the Scrum Guide the Scrum Master would need to somehow make that cancellation happen and if that is falsified then this particular component is working sub-optimally which affects the working of the whole process. What is also interesting is the “Each Sprint may be considered a short project.” part — my guess is that Scrum marketing was not powerful enough to push the project-less Scrum, which may be a marketing axiom to have some space in the project management market or it may be due to many various other reasons, that are beyond the scope of this article.
• Planning — the event is a described in complex and nuanced way with 4 conditions that can be falsified.
  1. “The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal.” — if this can be falsified then the Scrum Master is accountable for it. In what way a Scrum Master accomplished that? It is not described so we can assume — magic. Something happens because so.
  2. “Why is this Sprint valuable?” — can be falsified if not enough data is present.
  3. “What can be Done this Sprint?” + “Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.” — why does this even is added here IF anything can be changed as per the Sprint goal description? On the one hand, we see that Developers need to create a plan yet that plan can be changed every time because of reasons, and on the other hand if anything can be changed then there is no logical way to prevent taking too many work items per any given amount of time and then removing those that are not finished within any given amount of time. This is nonsense.
  4. “How will the chosen work get done?” — “How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.” — it seems that no one can actually tell the Developers how to turn work items into increments while at the same time “The Scrum Master is accountable for the Scrum Team’s effectiveness.”? So in case the Scrum Master person actually knows better then such a person is in a place where s/he needs to willingly put a blind eye to a potential bad practice. This may or may not be nonsense, as it depends on what the customer needs from the Scrum Master within the context of the Scrum Guide.
• Daily Scrum —
  “The Daily Scrum is a 15-minute event for the Developers of the Scrum Team.” — yet without someone other than a Developer facilitating the event, there is no way of knowing about the efficiency of the event.
  Also “The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.”
  Plus “The Daily Scrum is a 15-minute event for the Developers of the Scrum Team.”
  Is a redundancy as there is no clear demarcation of when the Developers should end the daily scrum and continue the conversation beyond the boundaries as if the daily scrum is for Developers and the Developers often meet throughout the day for more detailed discussion the question is formulated — why even bother with this 15-minute event? Why not 15:30, 16:28, 8:21, or 43:21 if needed? There are no answers in the Scrum Guide.
• Review — while the description of the event is fair and clear, the forced timebox is just arbitrary. Why a max of 4h per 1 month Sprint and “usually shorter” for shorter sprints? What does it mean — usually shorter? Who decides on that and who has the final say in case of disagreements? Scrum Master? If so, then why and on what basis? Other roles? If so, then why and on what basis? What are the objective criteria for decision-making?
• Retrospective — while the retrospective event, in general, is useful, what is the reason behind the arbitrary 3h timebox for a one-month Sprint? Who decides how long the event should take? Who is responsible for the outcomes and on what basis? There are no answers in the Scrum Guide.

Extremities & interfaces with other entities in the broader context of the company

• For the sake of simplicity, I will name just a few of the possible extremities and interfaces that may be in place within the context of Scrum teamwork.
• Management of various levels — management by default has some kind of power, influence, and agency. While there is a claim that “For Product Owners to succeed, the entire organization must respect their decisions.” it can be falsified by just one Product Owner's decision being overridden by anyone who has the means to do so. If the Product Owner’s decision is overridden then that particular Scrum Process Role component’s composite part is working sub-optimally. Who is there to override the override? Scrum Master? If so, then on what basis? Who empowers the Scrum Master to override other people’s decisions? Who is responsible for falsifying the whole Scrum Process, its components, and composite parts of the components?
• 3rd party entities — such entities may not work as per any set rules within the company. They need not provide any estimations nor in reality, do they not need to comply at all in anything if the contract is written in such a way. Who has the authority and responsibility over 3rd party entities? If it is someone outside of the Scrum process then why and on what basis? If it is someone within the Scrum process then why and on what basis? Those questions remain unanswered.
• Human Resouces and all related activities — who has the authority over hiring/firing, pay raises, and other HR-related activities such as performance reviews? Why that particular role, why so, and on what basis? Why not other roles, why so, on a why basis? Who is subservient to whom? Who has the final say? Why so, and on what basis? How does it impact the so-called Scrum “Values”? There are no answers.
• Stakeholders/customers — let’s not forget the sponsor who pays for the whole work being done. What if anything changes with the payment process or with requirements or anything at all? We have the suboptimally working process or no process at all as with no financing there is no scrum.
• Scrum as described in the Scrum Guide is a vague description of how the Scrum process works within the context of one team. How to scale it? Which framework is fitting in any given context? Why not other frameworks? Once again, no answers.

Summary

Thus it is possible to model the process as a tree.

Scrum Process consists of Components that consist of composite parts.

Scrum Process:
Values — Commitment, Focus, Openness, Respect, and Courage
Roles — Developers, Scrum Master, Product Owner, skills, knowledge, etc.
Artifacts — Product Backlog + Product Goal; Sprint Backlog + Sprint Goal; Increment + Definition of Done
Events — Sprint, Planning, Daily Scrum, Review, Retrospective
Extremities & Interfaces — management of various kinds, customers/stakeholders, HR, 3rd party entities, technology, money/budgeting, scaling issues, technical practices, process-related practices, etc. as the list goes on.

If the whole process consists of 5 components and based on my example those components host at least 30 composite elements then it becomes clear that if the whole process is required to work optimally then none of those composite elements can operate sub-optimally.

That is quite a heavyweight overhead to bear when pondering on the implementation of something that is marketed with the following axioms:
- “Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.”
- “Scrum is simple.” — hahaha, the joke’s on whom, actually?

Conclusion

I have identified the following conclusions:

• Scrum as a process is very heavy in weight and depends on many factors that it has no control over whatsoever. While it may seem simple at first look and that is the way it is marketed, the sheer amount of composite elements make it overly complex which is a bit contradictory to the marketing claim of “Scrum is founded on empiricism and lean thinking.”. Thus by applying a basic level of systems thinking akin to “how milk is made” I have identified at least 30 composite parts that need to somehow work optimally in order to make the whole process work at an optimal level.
• If “Lean thinking reduces waste and focuses on the essentials.” then I’d like to see definitive or at least logically correct and non-contradictory answers that present the one truthful interpretation of basically everything that is included in the Scrum Guide. My conclusion is that in order to pose as a Lean-ish process named framework the authors (whoever actually wrote it I don’t know, maybe shadow writers) trimmed the Scrum Guide to a point of it being self-contradictory or at least problematic at some points which is a logical cause and effect of shrinking the page- or word-count. One just simply needs to use more hypernyms.
• Extraordinary claims require extraordinary evidence + the burden of proof (kind of) lies not on the practitioner but on the party that claims something. “Other sources provide patterns, processes, and insights that complement the Scrum framework.” — it’s just moving the burden of proof… somewhere, go and find it you, you doubter I guess? Which is a very cheap dodge tactic in any kind of argument.
• the old claim was that Scrum is easy to learn, and difficult to master. Somehow, for some reason, it got removed. My conclusion is that Scrum as described in the 2020 November Guide is not quite difficult, it’s purely impossible to master and non-manageable as described.
• I claim that by modifying and especially simplifying the process as presented one may obtain results, yet it requires a very careful process design and the implementation of sound process control in place. In other words — a methodological approach.
• The whole Scrum movement brought many positive practices & trends yet at the same time by getting more popular it also got diluted into some hazy-waters type of opinion-based argumentation, anecdotal evidence, and subjective criteria being pushed as objective ones, implemented without knowing how they work (like the Story Points concept).
• The immutability clause is a joke. Ok, technically speaking it’s not a joke, it’s just a dogma. Dogmas have this funny tendency to handwave any argumentation because of the presupposition that the dogma is a true positive because… because it’s stated as being true, I guess.
• It’s not a surprise that there are so many articles on Scrum “this or thats”. Given that the process is dependent on so many factors it’s a simple multiplication game where one can take just 1 concept of the Scrum process and write endless opinions on the topic e.g. — top (number) characteristics of a great XYZ; why XYZ fails; XYZ, you’re doing it wrong because… opinions; how to do an efficient XYZ or how to XYZ efficiently; and so on, so forth.
• Hence it’s a never-ending spam of opinions, mostly bereft of any critical thinking or any kind of logical cause & effect analysis. What’s the value in what-ifs and could-have-beens?
  None in my opinion. It’s only an opinion, preferably presented in an easily digestible and conforming way, so as to never tickle that wrong tone. An echo chamber in other words.

In case of any doubt, I have compiled a list of common arguments of any XYZ-ism or dogma or movement proponents.

XYZ is true because:
- you just don’t get it right — work more, gain more experience and you’ll understand
- it’s not a good translation
- there is an article somewhere that proves it, go and find it (“Other sources provide patterns, processes, and insights that complement the Scrum framework.” What sources? What criteria to have when looking for those sources? Which are correct and which are not?)
- it’s a false contradiction or it’s only a contradiction on the first look — dig deeper and you’ll understand
- one of those claims is a metaphor
- theoretically, it’s possible to harmonize it, but you see, the problem is that you’re a dirty “command & control power-hungry waterfallist” that has been indoctrinated to hate XYZ
- I don’t know how, I don’t ask how, but it works for me so I don’t need to dig deeper
- everyone does so!
- it has been decided that way by someone and this is how the things go
- a figure of power here said so so disagree at your own risk

How many of those have you heard or seen in a written form?

Thank you for reading dear Reader. I welcome a constructive discussion.