I came across a post by Damian Synadinos, dating from August 2017, entitled Thinking about Beliefs. He explores the idea of belief systems; how they come to be, how people interpret them, how adopters implement them, various things that can go right or wrong when people apply them, and what can happen when we question our belief systems.
After presenting a general model of belief systems, Damian goes on to illustrate his ideas by describing how he set out to question his beliefs regarding software testing; that is, his belief system around his work. He discovered that some of his previously-held beliefs about software testing seemed sound while others had room for improvement, once he began to question them systematically.
Examining Scrum talk and action
Based on the title of this piece, I suppose you’ve guessed I will also apply Damian’s model to a professional area. There’s been a lot of discussion about Scrum in recent years, and quite a lot of it seems to relate to differences in interpretation and/or experiences with it. In some cases, people appear to approach Scrum as a belief system rather than “merely” as a tool or framework. It occurred to me Damian’s model could be a way to make sense of the kinds of arguments that occur about Scrum.
I’m not analyzing Scrum as such; I’m interested in people’s assumptions or beliefs about Scrum, and how those ideas influence their general opinions regarding the usefulness of Scrum as well as the details of their various implementations of Scrum, which vary rather considerably.
I wondered, as well, why it is that some people seem to be determined to label everything they like as “Scrum,” even if some of those things are not actually part of the Scrum framework. When they apply the Scrum principle to “inspect and adapt” (as they should do), they sometimes end up modifying their work practices to such an extent that they’re no longer applying Scrum. Yet, they insist on calling what they’re doing “Scrum,” or possibly “Scrum-and”. For some reason, they can’t let go of the word, “Scrum.” I get the impression of “religious” faith when I read or hear statements along those lines. So, then, perhaps by examining that behavior in terms of a belief system, I could gain a sense of how it happens and what people may actually be thinking about when they speak in that way.
As a consultant and coach, a model that helps me understand how people think about work-related frameworks and methods can be very helpful. If I don’t understand where people are “coming from,” how can I advise them in a way they can accept?
The model
Damian describes his model in the form of textual bullet points. For me, that makes it a little challenging to hold in my head as I’m reading. I found the subject interesting enough that I wanted to explore it further, and I thought a graphical representation would help me understand it a little better. Here is what I came up with (using Flying Logic Pro). The diagram follows the description from the “abstraction” section of Damian’s post.
Where an element represents a concept he explicitly describes in his post, the element is labeled “Synadinos” so you can tie it back to the original post. To help myself grasp the information, I added elements labeled “External” and “Internal,” as well as a few edge annotations.
It might be good to state some assumptions at the outset. First, the things labeled “External” are assumed to have objective existence irrespective of any human’s awareness of them. I understand there are other schools of thought about the nature of reality and the mind. For purposes of this exploration, I wanted to focus on other matters besides that level of philosophy. So, objective reality is a “given” in the diagram, and a distinction is made between it and subjective understanding. Elements that depict subjective understanding are labeled “Internal.” In cases when I felt the relationship between two elements might not be clear, I added edge annotations (yellow rectangles containing text, located on the connecting lines between elements).
Let’s walk the diagram as a way to review Damian’s model. At the top we have “World,” existing objectively with or without our approval. The people Damian calls the “Originators” have a worldview that is a product of their experiences, observations, and reasoning about the world insofar as they perceive it. Part of that worldview includes ideas about how to do something. For the limited purposes of this post, the “something” is software delivery at the team level.
After processing some of their experiences, observations, and thoughts concerning the domain of software delivery, the Originators arrive at a set of Sensible Ideas. It seems to me this is an important point: The Originators do not have magical powers to understand what is objectively true or universally “best.” They have ideas that are sensible to them, given their worldview, within a defined context (software delivery, in this case). To that extent, their ideas are no more “sensible” than anyone else’s. What makes their ideas compelling is that they have relatively broader and deeper experience in the problem domain than most other people. In the case of Scrum, that is true of Jeff Sutherland and Ken Schwaber. That’s the reason people have found it worthwhile to consider their ideas.
From these sensible ideas, the originators compile a list of Core Concepts. In the case of Scrum, these are documented in the Scrum Guide. One of my assumptions at the outset was that Jeff and Ken created Scrum, and therefore they are the only people who have the right to declare what is or is not part of Scrum. This assumption may be a reason why I question those who insist their local “improvements” ought to be considered part of Scrum. I don’t think the “-and” part of “Scrum-and” is legitimately part of the Scrum framework. However, I see nothing wrong with modifying the way we work in a particular local context, if doing so helps us deliver better. The “religious” part comes in when people won’t let go of the word Scrum even when they’ve diverged far from the defined framework.
But I digress. Back to the diagram.
There’s a group of elements for the Adopters of the belief system, showing how they comprehend reality via their Experience, Reason, and Observation. It looks just like the one for the Originators. The notation [n] means there are many Adopters. Each Adopter has a unique understanding of the world and a unique interpretation of the Core Concepts.
An Adopter’s understanding of the Core Concepts is shaped by four main factors:
- information about the actual Core Concepts (e.g., the Scrum Guide, things they learned in their CSM course, etc.)
- their own Sensible Ideas about the problem domain (software delivery at the team level), informed by their own Reason, Observation, and Experience
- their understanding about what is or isn’t possible or permitted in their work environment (subjective interpretation of Systemic Constraints)
- and, in some cases, an artificially high regard for the Originators (or the sacred texts), which can approach religious devotion.
Adopters then craft an Implementation of the Core Concepts, guided by their understanding. An additional factor comes into play as Adopters move from the conceptual to the practical level: Other belief systems that influence the choices available to them. For example, one might imagine that if a Scrum team fails to deliver all the planned User Stories for a Sprint, the penalty could be summary execution. A Mafia boss might consider that a reasonable implementation detail, as it would send a message to other Scrum teams in his territory. Indeed, many managers in corporations seem frustrated by the limits placed on them by societal norms, professional ethics, and law. However, most people would reject an implementation of Scrum that included murder as a standard practice, for reasons completely unrelated to software delivery as such. Those reasons stem from other belief systems that are part of the Adopter’s understanding of the world, such as secular humanism, respect for law, or religious faith.
At this point, we’re close to the bottom of the diagram. We have an Implementation of the Core Concepts. The Implementation consists of Ceremonies, by which Damian means all the rules, practices, standards, events, and so forth that are defined in the Implementation.
But there is more to the practice than just putting the Implementation into play. Some actors in the organization may have their own motivations, and want to use the Implementation to advance their personal agendas. Damian calls these “False Prophets,” a blanket term that includes people who are intentionally subverting the Implementation as well as those who may be well-intentioned but not so well-informed. They pollute the Ceremonies with their Agendas, adding another degree of variation to the Core Concepts.
The Implementation of the Core Concepts is applied to real work via the Ceremonies, and Outcomes result. For some stakeholders, the Outcomes are positive and for others they are negative or neutral. Each processing the Outcomes through their own mental filters, the Adopters and the False Prophets adjust their thinking about the Core Concepts based on the impact the Outcomes have on them. Thus is the loop closed.
One final wrinkle, mentioned in the edge annotation coming out of “Interpretation [n]” in the diagram, is that most Adopters pay no attention to the ongoing evolution of the Core Concepts over time. They stick to what they originally learned forever. This is characteristic of Scrum practitioners in the field. I’ve mentioned the Scrum Guide. It changes. The majority of people who apply some “flavor” of Scrum in their work never pay any attention to those changes. Their understanding of Scrum remains static.
For purposes of understanding the variability in Scrum practice on the ground, it’s useful to keep this in mind as it adds a temporal dimension to Scrum variants. Adopter #1 learns Scrum in 2006, Adopter #2 in 2013, Adopter #3 in 2018. Already there are three versions of the Core Concepts, even before we consider individual, subjective interpretations or feedback from experiences in applying Scrum. The number of variations explodes from there.
No two Adopters have the same mental model of the world. No two Adopters are working under exactly the same conditions or constraints. Even the Originators don’t have a completely objective and flawless concept of how to deliver software effectively, however hard to accept that may be for those who “believe in” Scrum. Scrum is a sand castle built atop a sand castle built atop another sand castle, and the tide rolls in and out, in and out. Thousands of possible “flavors” of Scrum are in use, and every one of them is “sensible” from a certain point of view.
Freedom from religion
As a practical matter, Scrum is less a framework than it is a belief system. It has followers and it has detractors. The idea of latching onto a framework and elevating it to the level of a belief system is puzzling to me. And yet, it appears to be a common case.
Here’s a recent statement from a well-respected software developer who has applied (and taught) Scrum and other good methods of software delivery for many years: “If a team can and will do Scrum, and they do it mindfully, they will benefit.” I like him, so I’m not mentioning his name, as I’m about to say something negative about the statement.
Notice the phrasing: It’s absolute. It’s uncoditional. As such, it’s a statement of belief. I’ve seen situations where Scrum was not a fit; where teams who did it mindfully did not benefit. Their organizational constraints were not those prevelant in the 1980s, which Scrum addresses effectively. Their delivery performance and their team dynamics were already beyond Scrum. That concept is inaccessible to true believers. They can’t conceive of anything “beyond” Scrum. Scrum is The Answer. Period.
In my view, Scrum is a framework that can be helpful under certain conditions. Those conditions are not rare, but neither are they universal. I don’t believe in Scrum. I like to imagine that I understand Scrum, and the conditions under which it can be helpful.
I see Scrum as a starting point from which teams can continue to improve and grow, outgrowing each of the Scrum events one by one until they aren’t necessary anymore. The goal in implementing Scrum is to improve to the point that Scrum can be discarded. A true believer will never set the goal of discarding Scrum. They see it as a Forever Thing.
As a consultant and coach, I encounter the full range of possible opinions about Scrum, from the steadfast true believer to the determined critic whose single negative experience with something labeled “Scrum” has tainted their understanding. I have to do my best to understand how they came to think the way they do. However that happened, it was based on Sensible Ideas derived from their Experience, Observation, and Reason.
The entry point for guiding a change in their perspective may be the flow from Outcomes back into the Adopter’s worldview. Then some of them may, however reluctantly, however timorously, relax their grip on the word, “Scrum,” and begin to think about improvement more broadly.