Some of its concepts, definitions, and perspectives have changed to keep it up to date. Additionally, the methodology has responded to adaptations that scrum teams all over the world have made, according to their culture, processes, environments, clients, dynamics, and necessities. 

I have been reading about latest Scrum Guide Updates for the last two months to understand what its impact would be for my current project, but I knew I would never accomplish its implementation if I didn’t write about it. I like things simple, especially when it comes to concepts, definitions, and meanings. I strongly believe that writing about something in your own words is the easiest and clearest way to learn something new. However, the references I have found about Agile and its changes are way too complex, long, and ultimately, not understandable. 

I realized that only after writing a simple, easy-reading review about latest Scrum Guide Updates would I truly be able to own that new knowledge. So this is my attempt to describe succinctly what these changes to the Agile methodology mean and the reasons they were made. 

Understanding the why

Every process — and change — has a reason to exist, and it makes it a lot easier to understand something when you know its background and origins.

We live in an ever-growing and complex world. The Agile methodology is often adjusted to the needs of the individuals applying it. Scrum is adapted according to each team's requirements. This applies to non-software teams as well, which were the root of Scrum foundations in the first place. 

Teams might be limited by hard-coded prescriptions about how to use Scrum, its artifacts, and ceremonies. With that in mind, alterations are made to make it simpler and less prescriptive, opening the methodology to meet team's necessities and ensure it is applicable to all kinds of companies.

Understanding the what

Within all of the updates that have occurred over the years, there are seven that caught my attention the most.Those are the ones I want to share in this article. Let’s start with the three I consider to be people-focused:

1. Accountabilities

Because Scrum’s intention was never to establish or describe job positions and titles, the methodology has changed the way we see roles, defining them as accountabilities one or more people within a team should own. The Scrum 2020 Updates state, “The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.” 

Though, you can still call them “roles”, you should be aware that they are a set of accountabilities used to implement Scrum correctly. As mentioned in the updates, there are 3 accountabilities:

Product Owner (PO)

A Product Owner (PO) is responsible for developing and explicitly communicating the already prioritized Product Goal to the team, making sure it is transparent, visible, and well understood across the team.

Developers

Developers are people in the team who are committed to creating the Increment each Sprint. They are also tasked with developing and adapting the plan to comply with the Sprint Goal while holding each other accountable for it.

Scrum Master (SM)

A Scrum Master (SM) is accountable for establishing Scrum as it has been defined by ensuring everyone understands concepts and practices — across the team and the whole organization. Also, SMs are accountable for the team's effectiveness in fostering an environment for improving its practices. Ultimately SMs are inspirational leaders who serve the team and organization.

2. Self-managed Teams

Another people-focused alteration to Scrum was the shift to self-managed teams.

To highlight this change, let’s consider a question. What’s the difference between self-organized and self-managed teams?

A self-organized team is capable of determining how to accomplish something, while a self-managed team goes further, defining what they want to accomplish, how they want to accomplish it and when they hope to accomplish it.

This gives even more responsibility to the team, making them accountable for the sprint commitment. So, the Scrum Master becomes a support resource for the self-managed team and their relationship with the Scrum Goal.

3. Leader who serves

The next people-focused modification is a subtle but meaningful change. Now, the SM serves the team, the organization, and the PO to ensure that:

• Scrum is established as defined in the Scrum Guide.
• The Scrum Team is effective throughout the project. 

Let’s take a look at how a SM serves each of the following groups:

• The team: The SM helps the team focus on creating valuable increments, removing impediments that block their progress, and ensuring that Events take place positively, are productive, and follow a defined timebox.
• The PO: The SM helps the PO find tools and ideas for an effective Product Goal definition, and the Product Backlog maintenance, ensure the team understands the Increment and facilitate stakeholder interaction and collaboration.
• The Organization: In addition to being accountable for the Scrum Team, SMs are ambassadors for organizational change. They are the bridges, dealing with management at the same time they facilitate the team. As a result, SMs are “true leaders who serve”.

Other Changes

All of these changes are focused on how people interact within the Agile Methodology. They provide an overview of the individual team member accountabilities within the Scrum team, provide guidance on shared goals, and clarify that all individuals on the team are striving to deliver a high-value increment to clients.

The 4 remaining changes are focused on Events and Artifacts, I will be describing them within my next article.