Scrum is in fashion and it is impossible to deny the influence it has on all management and teamwork models. This "model" is the protagonist of a transformation on a global scale. If the pandemic accelerated organizational transformation, then Scrum is the fuel that powers hundreds of thousands of remote and virtual teams globally.
But what is Scrum and why is it so famous?
In the management context, Scrum was created in the early 90s. However, it took almost two decades for the first version of the Official Guide to be published, which is, as we geeks would say, the canonical model of today.
The parents of Scrum are Jeff Sutherland and Ken Schwaber. And its vision has evolved over the years. That's why for many it is difficult to define what Scrum is, a method? a model? a process? or a methodology?
Scrum methodology or process?
Scrum is a framework - frameworkAnd what does it mean to be a framework? Let's go with an example of what a framework is. One of the examples I like.
Imagine you're a LEGO® fan and you've bought a box of LEGO® tokens. But you decide not to follow the instructions but to create your own model. Creative mode, as Minecraft players would say.
When you are in creative mode with your tokens, you may have a preference for a few tokens that always serve as the basis for your models. These fundamental tokens, which are the basis for more complex models, you could call them: work framework o framework.
Scrum: a base set
Scrum is a set of "ground rules" that includes:
- Events - a set of activities that some "innovators of the word" call ceremonies or rituals.
- Artifacts - tools and instruments such as the Backlog Product Backlog and the Iteration Backlog, or the Definition of Completeness - the definition of done
- Roles - where the famous Scrum Master and Product Owner are described.
This base set is fertile ground for incorporating new practices or scaling the model. And therein lies the success of Scrum and why it is so famous. Scrum is simple, straightforward and lightweight. That is its biggest advantage - and its biggest weakness.
If your team structures well what it builds on top of Scrum, it will be successful. If your team doesn't structure well how to extend the framework, it will surely suffer many problems that will make you think about abandoning the path.
What are Sprints?
Before we talk about Scrum events, it's good to talk about the concept of sprint. And, although Scrum is not a prescriptive process, it does propose a management model based on sprints.
Sprints are short, fixed duration periods of time - no more than 4 weeks. These cycles are known as iterations in other management models. In many cases, people interchange the terms interchangeably.
Sprints should always last the same length. Over the years, the recommendation for the duration of Sprints has become shorter and shorter. Not so long ago, cycles of 2 to 8 weeks were recommended. Today, the recommendation is that a sprint should last 1 to 4 weeks.
If you are doing Scrum, your sprints should always be the same length. That is, you shouldn't have one-week sprints and 4-week sprints and 2-week sprints.
Scrum Cycle
The model defines a repeating sequence of events sprint a sprint. This cycle includes:
- Planningwhich seeks to answer the questions:
- What is the goal of this Sprint?
- How do we hope to achieve this goal?
- Daily monitoringwhose goal is to keep the team in sync and answer questions:
- What have we achieved?
- What are we focused on now?
- What problems do we have or what risks do we anticipate as a team?
- Closing at product level. Seeks to respond:
- What have we completed during the Sprint?
- Does what we have completed solve the need or objective?
- A process level closure. Answer the questions:
- What did we do well as a team?
- What should or can we improve?
- What actions will we take to improve or correct bad habits as a team?
Product Backlog Refinement
The refinement of the backlog is an activity that has been gaining ground over the years. Backlog refinement used to be known as grooming.
However, and I think stubbornly, this activity - which is often mentioned with the term scrum, does not appear as an official event of the framework.
I am openly against not making it explicit as an event.
Scrum Example: Cycle Events as an Agenda
As I said before, the Scrum cycle repeats every sprint. So, if the duration of your iterations is one week, this cycle of events repeats every week. If your iterations are two weeks long, you could have a schedule similar to this - it's an example, not to copy and paste with all your teams and projects. I'm sure it will help you get an idea of what's going on.
Scrum Types
Although there is only one canonical scrum, there are definitely several versions or visions of the framework. Of course, the most accepted and respected is the Scrum Guide.
But here I present you with much of the available literature - each with its own version adjusted to Scrum - which is a bit what I do with this article. Add a bit of context and experience, trying not to break the basic rules - the pillars and values.
Official Guide: canonical model
I have already talked about the Scrum Guide. Here are its features:
- It is maintained and updated by the "parents" of Scrum.
- It was originally conceived for software development.
- It is the most popular and widely accepted version.
- It is also the most ambiguous and least restrictive version. This can lead inexperienced teams without proper accompaniment to lose their way.
Scrum Body of Knowledge: the most hated one
If the Official Guide has the broadest and most flexible vision, the SBOK is the complete opposite. The company behind this (monstrous) document wanted to emulate PMI's PMBOK. It was very successful a few years ago and its certifications were very common. Today, with the arrival of other even more questionable and less strict players, it has lost a lot of ground. While I don't like their approach, I admit that in the effort to structure all the work there is value and some interesting solutions to the challenges of adopting the methodology.
Scrum in Scaled Agile Framework (SAFe)
SAFe is an agility framework at scale. Their proposal attempts to address the fact that the framework does not make choices about efforts or organizational structures of another magnitude - 50, 70 or 150 people.
Although SAFe does not describe the framework, it is clear that it makes clear modifications to the canonical model.
Scrum @Scale
Another attempt - somewhat simplistic for my taste - to promote Scrum at the organizational level. One of its biggest criticisms is that it builds on what the scale-free model tried to discredit. It's inevitable, scale requires structure and some bureaucracy.
Other versions: certifications without conceptual input
I can assure you that there are 1000 versions of the framework. Almost all of them associated with a "certification" in one of the roles. But I can confidently assure that behind this effort there is more intention to make money with courses and certifications, than to really contribute to the profession or the exercise itself of the teams that adopt Scrum.
Scrum Artifacts
The Scrum framework has very few artifacts. This makes it difficult to "land". And, without the knowledge and experience, it can lead to team frustration in not knowing how to get the most out of them.
Here you will find a list of "official" artifacts and other artifacts that are used on top of the "base set" and are very popular.
Backlog
The backlog is a prioritized list of requirements. Unlike other decomposition structures, the backlog is designed to support movement and dynamism in requirements. It is easy to manage changes, new requirements and even different levels of detail.
There are two types of backlog:
- Product backlog. A business value oriented version.
- Sprint backlog. A kind of child of the product backlog that, although business-oriented, almost always contains much more detail and even elements oriented to product development or maintenance - known as enablers or tasks and subtasks.
Increase
Incrementalism is a simple concept, very difficult to put into practice. Incrementalism is a "decisive step" or a "concrete victory" in the direction of meeting the product target.
So, if we talk about software, it is a version of the product that is developed or "evolved" within the sprint and that adds a clear and testable portion of value - let's not forget the scrum pillars.
But what's an increment if my team doesn't develop software? Well, there's the rub. How to structure a high-level, early-win oriented roadmap. Not easy.
Definition of Completed - Definition of Done
This is a kind of checklist that the development team agrees with the Product Owner. The purpose of this checklist is similar to when you take your car to the dealer - or official workshop. Before you can pick up your car, they will surely give you a checklist that should have all the steps marked as completed. That way they know it's ready for you to "sign off".
Definition of Ready to Work - Definition of Ready
This is a popular artifact, but unofficial.
If there is a list to validate whether a job has been completed. It is also possible to define a list to validate that a product backlog item is ready to be evaluated by the team in the planning of a sprint.
User Stories - User Stories
User stories They are NOT a scrum artifact. Moreover, there is NO obligation to use this type of tool as a backlog element - although many insist that if you don't use user stories you are not agile.
Despite popular belief, user stories and scrum do not have the same origin. The US, as they are popularly known, are not a condition for the sine qua non to have a backlog or adopt scrum. That is, you can adopt scrum and NEVER use user stories.
User stories are valuable tools as an artifact when the team is trying to develop new products. User stories focus on the value of what I want to achieve and not the scope of what I want to achieve.
Let's go with an example. Let's start with some context.
Alberto is a dedicated and committed worker. It has been some time since Alberto has taken a vacation. Consequently, he has decided to take a few days to rest with his family.
Scope-oriented requirement scope
We have a context that poses a need. That's fundamental, and I'm going to write a requirement that seeks to solve that need with a specific scope - that is, determining in passing the solution to the need.
Book tickets, all inclusive accommodation and transfers for a full weekend - from Friday to Sunday - in the touristic city of Punta Cana in the Dominican Republic, for Alberto and his family.
At first glance, traveling for a weekend is a requirement that will certainly solve my desire to take a vacation. If you don't know Punta Cana, let's say, it's a place to relax and enjoy the weather, the beaches and a good rum.
However, the execution of that requirement limits the options for resolving the need to one (1), i.e., I can only go to Punta Cana. What happens if flights to Punta Cana are cancelled, or there is no availability at the hotels? We cannot resolve the requirement.
Business value oriented requirement
A user story - more or less well written and with the firm intention of explaining the academic difference, would go something like this:
As a dedicated and committed worker I want to spend a few days away from work and family to rest and recharge the energy I need to do my job well.
This requirement does not specifically say what needs to be done to offer Alberto a few days of respite. That may be bad, if as a team we have no experience at all in offering family respite experiences. That may be good, if as teams we are good at offering family respite alternatives.
Scrum Roles
The framework is a "base set". And under that philosophy, so are the roles within Scrum. That is, there are some roles within the framework, but that doesn't mean that it can't have other roles. Or does it?
Some radicals, ScrumaniacsIf there are no other roles within a Scrum team, they would say that there are no more roles, but let's say they can be specialties. Say, UI/UX specialist or test specialist, or database specialist - I just gave several examples to torture the scrumaniacs.
These base roles are:
Product Owner - Product Owner
In my experience, the Product Owner (PO) is the most important role in the success of scrum in organizations. I'm sure you're wondering, but isn't the Scrum Master - what's the point of your role saying "master" if you're not the most important? And well, these things happen sometimes.
In my opinion, the PO is in charge of the key input to agility, and that is the breakdown structure that enables incremental delivery - or the famous product increments.
Imagine being in charge of the best team of chefs in the world and not knowing what to ask for more than "rice with egg".[1]And I mean it's a dish that we've all eaten at one time or another and it's a part of the Taste Atlas Ranking.. Or ask for recipes that do not meet the tastes of your potential diners. What a waste?
The Product Owner is in charge of maximizing the benefit of the results of the (development) team's work. That is, the Product Owner is the one who defines, prioritizes and validates the requirements - or at least governs those processes. And in this exercise of definition, prioritization and validation, he seeks to maximize the "value stream". That is, the benefits that are received from testing, using or experiencing the result of each iteration.
Scrum Master
The other role is the Scrum Master, who is a sort of facilitator and cheerleader - some more the latter than the former XD - who seeks to empower the team (as a team) and support its members for their growth.
Far from taking direct responsibilities within the team, the Scrum Master is the one who "takes care" of the exercise of the methodology - although, in theory, Scrum is not a method. And he is the one who protects the team from the potential abuses of the PO, and helps to solve the impediments that may arise throughout the exercise of the work - a kind of skater, we would say here in Colombia.
Many see the SM as a savior, or an enlightened being. I admit that it is not easy to be the one who leads change - and helps to transform. But he or she is definitely more of a change agent than an active actor in the productive process.
Is the Scrum Master the new project manager?
In my opinion, not at all. Both roles are different and complementary. You can have PM, SM or SM who are also PM, or PM who are also SM. It depends a lot on the organization and the responsibilities associated with the role.
What should never happen is that the SM and the PO are the same person. So it can be a PM/PO or a PM/SM but never a single PM - I think that was the biggest mistake of what we call traditional management today, trying to get the PM to do both. Score one for the agilists!
Not long ago I wrote an article you might be interested in about the roles of PM and SM: If you are agile, you don't need project managers
Developers - Developers
Well, although Scrum doesn't specifically talk about development, it has failed to find another term for the team of people who actually do the work. That is, if the PO is the one who requests, and the SM is the one who facilitates, the Developers are the ones who do.
This team is multidisciplinary and, hopefully, autonomous. It should not have too many people, but not too few either - let's say they used to say something like 3 to 9, or 5 to 7, or... well you get the idea. If there are too many, they can't coordinate as a team, if there are too few, they can't achieve any results in a short time.
Final Considerations
Well, as you can see, Scrum is not a complex or difficult framework to understand. It is relatively straightforward and is based on a very simple model of team management and role separation. It reminds me a lot of the book Death by Meeting. However, as they put it in the Scrum Guide - the canonical guide to Scrum:
Scrum is free... The framework of Scrum is immutable. While it is possible to implement only parts of Scrum, the result will be is not Scrum. Scrum exists only in its entirety and works well as a container for other techniques, methodologies and practices.
Scrum Guide 2020
Author's comments and notes
