In 2021, Scrum became the most widely used Agile framework, with 66% of organizations adopting it for their operations. At the same time, the criticism of Scrum has also increased; there is bound to be confusion about exactly what Scrum is. Ron Jeffries also talked about what Scrum is and the critical points surrounding its usage.
This article will delve deep into the fundamentals of Scrum without repeating what is in the Scrum guide. That means we will not discuss the events, accountabilities, or artifacts. In addition, I have already written about Empiricism, so we will not repeat that either. Instead, we will talk about the structural aspects of Scrum and how it relates to our day-to-day work.
By the end of this article, you will know the underlying principles beyond Empiricism that define the foundation of Scrum. Moreover, understanding these principles will help you measure the success of Scrum beyond the events, artifacts, and accountabilities.
Table of Contents
The Origins
In 1986, they published their article “The New New Product Development Game,” drawing analogies from Rugby to describe the new approach needed for successful product development given the changing nature of challenges. Many consider this article as the primary source of inspiration behind Scrum. Specifically, the article describes three characteristics of the new-age product development process;
1. Constant interactions
2. Self-organizing, cross-functional teams
3. Stable from start to finish
Timebox
In 1991, James Martin described timeboxes in his book Rapid Application Development. The concept was based on Parkinson’s Law. With timeboxing, you allocate a specified time for certain activities, and irrespective of the progress, you stop working on that activity once the timebox is over.
The Musical Connection
There is a concept of cadence in music. The chords or notes repeat at regular intervals and signal the end of a musical phrase or piece. The cadence establishes the rhythm and completion of a segment.
The timeboxes help establish the rhythm or cadence of the team.
How Is Scrum Built?
Scrum took the concepts described in “The New New Product Development Game” and the “Rapid Application Development” and created the framework that helps the team arrive at an adaptive solution to a complex problem.
I have already spoken about these two aspects, “adaptive solutions” and “complex problems,” in another article that dives deep into the Scrum Guide, so I will not repeat those here.
However, Scrum provides a framework that allows you to approach the work in an agile manner by utilizing the concepts described in the Agile Manifesto and the resources described above by providing values, guidelines, and practices for the teams to implement.
The concept of timebox maps to the Sprints.
Scrum teams are defined as cross-functional and empowered to achieve the sprint and product goals.
The empowerment is exhibited during the Sprint Planning and continues throughout the entire Sprint. The team chooses what work they will do in the next Sprint and how they will do it. They may take outside support, but no one outside the Scrum team dictates how the team would work.
The constant interactions are achieved through the Daily Scrum.
The cadence is implemented through the Sprint Review and Sprint Retrospective.
Beyond this structure, Scrum leaves everything for the Scrum team to decide.
So What Is Scrum?
All agile frameworks and methodologies can be divided into two distinct categories;
The first category represents the frameworks and methodologies that directly impact the work. XP is a prime example of a methodology that defines the practices that an agile software development team may adopt for their work.
Then there are other frameworks like Scrum that define how agile teams should manage the work process.
From that perspective, Scrum is a project management framework that can facilitate teams to adopt the agile methodology & approach.
Scrum itself doesn’t ensure team agility. Instead, it provides a structure for a Scrum team to adopt an agile approach.
However, it is also easy to use Scrum and still adopt a sequential approach for smaller chunks of the work. In this case, each Sprint works as a project, and the teams can still have phases like requirements analysis, design, development, and testing.
At the same time, the teams can adopt iterative and incremental approaches. You can adopt methodologies like Extreme Programming (XP).
You can also mix Scrum with frameworks like Kanban and introduce the flow approach instead of a cadence-based one.
Criticism of Scrum
1. It is an immutable Framework.
Yes, it is. You can implement Scrum Framework partially (well, you can, but then you can’t call it Scrum). You can’t also alter the rules (e.g., timeboxing for events or the order of events). So yes, it is immutable by definition.
The immutability results from the belief that if you don’t accept or implement a framework, which is loosely defined, then you will miss out on the benefits that the framework brings.
However, the critics point out that not all practices or rules bring similar results for all teams. Therefore, if one component is not working for a team and can still achieve the intended outcomes through other means, a framework should allow them to adopt that.
In practice, you are free to do that. However, the Scrum Guide is clear that, in that case, you can’t claim that you have implemented Scrum.
2. Scrum’s definition focuses on completing the tasks rather than generating value.
This opinion is debatable as to whether it is the way the Scrum Guide defines the events that leads to this criticism or the gaps in the interpretation of what Scrum teams should do while adhering to the Scrum Guide.
First, let’s talk about the Scrum Guide. Sprint is the overarching event, and the Scrum Guide says that Sprint’s output is a potentially shippable product increment. However, beyond the potentially shippable criteria, there is no other benchmark to evaluate the value of that increment. The value is derived only after the increment is shipped (for use to the users). Scrum leaves it to the teams to define the yardstick.
Something similar happens with Sprint Planning. The output of the Sprint Planning is the Sprint Goal and the Sprint Backlog, which has items (Scrum doesn’t define user stories) from the Product Backlog representing the team’s work to achieve the Sprint Goal. However, there is no definition or criteria to evaluate the effectiveness of the Sprint Goal. I have seen teams defining the Sprint Goals in terms of the items to be completed or the velocity to achieve (Scrum also doesn’t define velocity) rather than a value-centric goal.
The issue is more pronounced with Daily Scrum. The Scrum Guide (intentionally) is vague about how a Scrum team should conduct these daily meetings. The objective is for the agile team to inspect the progress towards the Sprint Goal and collectively answer the challenges. However, there are two problems that teams face.
First, if the Sprint Goal is not value-oriented, your progress measurement will also not focus on the value.
Second, the lack of guidance means that how the teams achieve the event’s objective is unclear. The three-question format became popular, and this approach has the lion’s share in the perception that Scrum is focused on tasks rather than value.
Sprint Reviews and Sprint Retrospectives also are vague about how to measure the outcome. However, Scrum is insistent about all the events, following all the rules defined in the Scrum Guide.
The lack of clarity about how to align these events with delivering value leads to criticism. Again, to a great extent, this is the inability of adopters to define the ways to be value-centric optimally. Still, it is also possible for the Scrum Guide to leave behind the temptation to be brief and comment on these aspects.
3. It isn’t easy to scale
Scrum is an individual team model. It does require additional components to work in an environment where you have more than one team working on a single product. The lack of organic scalability is by design.
Mistakes In Scrum Adoption
It is easy to make mistakes with Scrum, as it is vague to provide teams with the flexibility to adopt optimal practices, even within the Scrum framework. However, this vagueness results in incorrection adoption and implementation. Following are a few common mistakes in Scrum.
1. Not following the essence and values of Scrum but just following the practices
2. Focusing too much on the process and ignoring the outcomes
3. Trying to apply Scrum without having a clear vision of what you want to achieve
4. Ignoring the context
5. Improper definition of Sprint Goals
6. Considering Sprint’s goals as a contract
7. Daily Scrum reduced to status meetings
8. Adopting Scrum when a flow-based approach would be more efficient
9. Implementing Scrum-like short waterfall projects
10. Not using retrospectives to improve processes & products and for learning. Additionally, they are not implementing the feedback loops.
11. Product Increments are misunderstood as a way to deliver value
Featured Image: Photo by Scott Blake on Unsplash
