Mapping Scrum to the 12 Agile Principles

And why I found Principle 6 to be the most challenging

If you take a Scrum workshop, one of the first things you are exposed to is the Agile Manifesto, where the 4 values and 12 principles of Agile are covered. There’s usually a fun activity and discussion around which of the 12 principles is most difficult or easiest to implement in your organization. Afterward, the discussion moves to how Scrum is one of the most popular ways to implement Agile and that Scrum embraces both the values and principles of Agile.

What I haven’t seen is an activity or an example at the end of the workshop where Scrum is actually mapped back to the 12 Agile principles. If Scrum is a framework that implements Agile, then all of the 12 Principles of Agile should hold up against Scrum. The following is my attempt to see if Scrum does actually map to the 12 Agile principles.

Agile Principles:

Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Through the use of Sprints in Scrum that are “continuous” and are fixed length events of one month or less, Scrum aligns with this principle.
• Since an Increment is born the moment a Product Backlog item meets the Definition of Done, the framework promotes continuous delivery in helping to ensure that software can be reliably released at any time.

Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

• Not only is Scrum designed to welcome changing requirements but Scrum also helps to create new requirements through the use of the Sprint Review event. The Sprint Review provides an environment for customer feedback and it “harnesses change for the customer’s competitive advantage” by encouraging customer and stakeholder collaboration with the Scrum Team.

Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• The 3rd Principle is similar to the 1st Principle and is essentially a clarification for what “early and continuous” means. The Agile Manifesto states that delivery should be from a couple of weeks to a couple of months, whereas the Scrum Guide is a little more restrictive to one month or less for a Sprint.

Principle 4: Business people and developers must work together daily throughout the project.

• The goal of this principle is to reduce the gap between what business people want and what developers think they want. By interacting with stakeholders, customers, and each other on a frequent basis, the Scrum Team more clearly understands the intent behind requirements.
• The Scrum Guide states that the Scrum Master serves the organization by helping to remove barriers between stakeholders and Scrum Teams
• During Sprint Review “The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.” and “During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment.”

Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

• Scrum Teams “…are also self-managing, meaning they internally decide who does what, when, and how.”

Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• Face-to-face conversation implies direct communication that can be executed in different ways, whether in-person or through video chat. Also, communication can occur in many different ways and every form has a good reason for existing. Though email can be an effective way to communicate in certain circumstances, I do not feel that it fits the face-to-face criteria.
• The Scrum Guide encourages “face-to-face” conversations among the developers via the Daily Scrum, and it states that this event is held at the same time and place every working day of the Sprint. Also, the Scrum Guide states that the Scrum Master helps to remove barriers between Stakeholders and the Scrum Team. Additionally, there is the Sprint Review where the Stakeholders and Scrum Team come together.

Principle 7: Working software is the primary measure of progress.

• Each Sprint, the Scrum Team turns a selection of the work into an Increment. “An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.”

Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

• “Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.”
• “The Scrum Team is responsible for all product-related activities…and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.”

Principle 9: Continuous attention to technical excellence and good design enhances agility.

• This is accomplished through the Sprint Retrospective where the purpose is to plan ways to increase quality and effectiveness. In addition, the Scrum Value of Focus works well here to align with “continuous attention”.
• The Scrum Guide aligns with “technical excellence” by stating that the Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value for each Sprint.

Principle 10: Simplicity — the art of maximizing the amount of work not done — is essential.

• This is my favorite Agile principle but it feels very counter-intuitive.
• The Events in Scrum are used to “…create regularity and to minimize the need for meetings not defined in Scrum.”
• The Definition of Done in Scrum helps with “maximizing the amount of work not done” by stating that the moment a Product Backlog item meets the Definition of Done, an Increment is born.
• Scrum also aligns to this principle with the help of Product Backlog refinement. By breaking down and further defining the items, it helps to remove work that is not important.

Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.

• The word now is “self-managing” and Scrum Teams are self-managing, meaning they internally decide who does what, when, and how.

Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

• This is accomplished through the Sprint Retrospective. “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.”

This was a fun exercise for me and what I realized was that 11 out of the 12 Principles were really easy to map. It was Principle 6: “…face-to-face conversation” where I found I spent the most time thinking, trying to understand, and map. Several Scrum Teams were already working as distributed teams prior to the recent pandemic but as a result of the pandemic most everyone was forced to work remotely, it made in-person conversations virtually impossible. So the question I was challenging myself with was, “Is face-to-face strictly in-person?” Can there be other forms of face-to-face and where do you draw the line where it is no longer considered face-to-face? To be fair, the Principle only states that face-to-face conversations are the “most efficient and effective method” but it is not stated as a hard rule. I do feel that video chat still meets the spirit of face-to-face; however, the osmotic communication where we acquire knowledge even if we are not an active participant in a particular conversation is lost when we are not in-person. One experiment that comes to mind, is to see what would happen if a Scrum Team that is distributed was to plan a couple of hours each day where they open up a virtual chat while they work. No agenda, just everyone on a virtual chat for a couple of hours while they work. Could feel a bit Big Brotherish so it would require real trust and not just psychological safety.

Interestingly enough, nowhere in the Scrum Guide is the word Agile mentioned.

I am very interested to learn what you think about this topic. My LinkedIn profile is https://www.linkedin.com/in/phooey

GO MAKE A HULLABALOO!!!