What Scrum is (and isn't)
Throughout my professional journey, I've encountered instances where individuals claim something is 'Scrum', when in reality, it isn't and there's no mention of it in any of the Scrum guides (and for good reason too!)
It's common to associate a practice or technique with a specific framework or language, leading to the misconception that if that associated practice is flawed, then the framework or language must be flawed as well.
I couldn't count the amount of times someone has said to me that they dislike story points and velocity, or that because they can't change work within the sprint, well that Scrum is to blame. See the hasty generalisation fallacy for how this logic is flawed.
In this blog post, we're going to be debunking some common misconceptions about Scrum and why they shouldn't stop you from using it! But before we get that, let's first have a quick introduction into what is Scrum.
"Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.". It is characterised by its iterative and incremental nature, promoting collaboration, adaptability, and continuous improvement. The framework consists of defined accountabilities, events, and artifacts, as outlined in the Scrum Guides.
So, let's get into it, what are the common misconceptions about Scrum? Here they are:
Story Points and Scrum: Contrary to popular belief, Story Points did not originate from Scrum but rather from XP (eXtreme Programming), credited to Ron Jefferies. For more details on their origin and original purpose, refer to this article.
User Stories and Scrum: Similarly, User Stories have their roots in XP. For a deeper dive into the history of User Stories, explore Wikipedia.
Velocity and Scrum: Once again, Velocity is not exclusive to Scrum; Can you take a guess where it emerged from?... Ding ding ding, we have a winner! It emerged from XP.
Scrum does not allow changes in a Sprint: While the goal is to minimise changes during a sprint to maintain stability, Scrum acknowledges that changes can occur. The Scrum Team, with the Product Owner's guidance, has the flexibility to adjust the scope if necessary.
You have to complete all items in a Sprint: The objective is to deliver a potentially releasable increment by the end of the sprint, but it's recognised that unforeseen challenges or changing priorities may impact the ability to finish all planned work. The emphasis is on delivering the highest priority and most valuable items first, usually the things that relate to the Sprint Goal, focusing on quality and value rather than rigid adherence to a predetermined checklist.
While these practices align well with Scrum and are widely adopted in conjunction, you don't have to use them, and disliking Scrum solely based on these artifacts is akin to disliking water because you don't enjoy swimming...
You might be asking, well if it's not about Story Points and metrics and all these other gubbins, what is Scrum actually about?
Well, I'm glad you asked! Let's delve a bit into the essence of Scrum.
Firstly, it's important to understand the underlying Scrum values:
Openness - The Scrum team and its stakeholders agree to be open about all the work and the challenges with performing the work.
Respect - Scrum team members respect each other to be capable, independent people.
Courage - The Scrum team members have courage to do the right thing and work on tough problems.
Commitment - People personally commit to achieving the goals of the Scrum team
Focus - Everyone focuses on the work of the Sprint and the goals of the Scrum team.
It's not uncommon to witness teams claiming to follow Scrum, only to discover that they aren't embracing these core values. Team members may be reluctant to express themselves, fail to respect each other's ideas, or lack the necessary focus and commitment. Attempting to implement Scrum without upholding these values sets the stage for disaster.
Next, we have the team accountabilities:
Scrum Master: They are the facilitator ensuring adherence to Scrum, removing impediments, and promoting continuous improvement.
Product Owner: They represent the stakeholder interests, define and prioritise the product backlog, and communicate the product vision.
Development Team: They are cross-functional and self-organising professionals, who deliver a potentially shippable product increment at the end of each sprint.
Together they make up the Scrum Team, a collaborative and self-organising team, responsible for delivering product increments in sprints.
Next, let's briefly touch on the key events:
The Sprint: A timeboxed event housing all other events.
Sprint Planning: Discussion on the Sprint Goal and the necessary steps to achieve it.
Daily Scrum: Evaluation of progress towards the Sprint Goal.
Sprint Review: An opportunity to assess the product increment and adapt based on stakeholder feedback and the Scrum Team's insights.
Sprint Retrospective: An opportunity for introspection regarding the team and process.
The artifacts in Scrum, include:
Product Backlog: A dynamic list of prioritised features, enhancements, and fixes, representing the work to be done on the product.
Sprint Backlog: A subset of the Product Backlog, detailing the work to be done in the current Sprint.
Increment: The sum of all the completed Product Backlog items at the end of a Sprint, representing a potentially shippable product.
All of these combined together make up the core of Scrum. However, without the guiding values in place, these events and artifacts can become routine exercises, falling into a trap where improvement is stunted.
As well as this, it's imperative to remember the three pillars that Scrum lies upon.
Transparency: The process and work is visible to all who are doing and receiving the work.
Inspection: Continuous inspection of the work, people and processes.
Adaptation: The ability to continuously improve based on the inspection, and pivot where necessary.
Each of the values, events and artefacts are crafted to foster the thriving of these three pillars within the Scrum framework.
For those currently in a Scrum team, ask yourself:
What steps are you taking to enhance yourselves?
What steps are you taking to enhance your product?
What steps are you taking to enhance your process?
Are you ensuring the adherence to Scrum values?
If your answer falls short, it's time to reconsider your practices. Without embracing these core values, pillars and principles, you will probably be missing out on the full benefits that Scrum can offer.
Lastly, it's important to remember, suggested methods and approaches such as story points, velocity, and reducing changes to scope in the sprint serve as a way to hold the team accountable for what they have committed to. One of the things I learned in my Scrum training was that one of the main goals of a Scrum Master was to make a team self-organising and to deliver continuous value. I also learned that the tools and techniques that you use should serve the team, not hinder them. What each team needs will be different based on their maturity, the type of work they are doing and what their personalities are like.
So, the next time you catch yourself thinking, 'Scrum is terrible,' and you're contemplating abandoning it altogether, take a moment to reflect. Ask yourself whether it's truly Scrum that you dislike (and if so, that's valid!), or is it the interpretations and representations of Scrum that people are sharing with you?