Agile is a journey, not a destination. Scrum teams may lose their way, but the Scrum values act as a compass, and the pillars help us course-correct.
Scrum values and pillars work together to create a culture of continuous improvement. Focus, openness, respect, courage, and commitment help drive collaboration, while transparency, inspection, and adaptation enable teams to gather and analyze data for ongoing improvement.
Scrum values are the fundamental beliefs that guide the lightweight framework: focus, openness, respect, courage, and commitment. These values are the bedrock of successful implementation and are essential to creating a collaborative environment.
“Successful use of Scrum depends on people becoming more proficient in living five values.”
- Scrum Guide
The three pillars of transparency, inspection, and adaptation are key to the empirical process that allows us to customize the framework to meet the needs of our specific product or organization.
Transparency means everyone knows what’s happening within the Scrum Team, the Product Backlog, and the Sprint Backlog. Inspection means that we regularly evaluate our work and process to identify areas for improvement. Adaptation means we’re willing to change based on what we learn.
I like to think of the Scrum values as a compass that points us in the general direction we need to go. Between the values and pillars, we have principles and practices. Principles function as a map to give us more specific guidance. Practices are like turn-by-turn instructions; someone can follow them if unfamiliar with the overall destination. Lastly, the pillars are like the recalculating feature of a GPS (only less annoying), allowing us to adapt our practices.
There is a dangerous yet prevalent misconception that the Scrum values and pillars are optional, and teams can ignore them if they don’t align with the team’s goals or culture. This is an unfortunate misunderstanding that is the root cause of most complaints against this particular agile approach. You can trace most struggles and criticisms back to either the lack of values, which undermines the culture needed to be successful, or the lack of empiricism, which undermine the ability to customize the framework to fit the needs of the Scrum Team.
I sometimes have difficulty explaining why the Scrum values are so important. At first blush, the values may appear touchy-feely, leading some to avoid or dismiss them. Others who are more emotionally aware might find the values too obvious to warrant attention.
Unfortunately, both attitudes are misguided. Those who dismiss them are likely to encounter difficulties, while those who take them for granted miss out on opportunities for growth and improvement. In reality, the values are crucial to the success of Scrum teams.
Scrum Teams must adhere to these values to maintain a culture of transparency, inspection, and adaptation. You’re more susceptible to encountering obstacles that will hinder your success.
You also risk being unable to build or maintain the collaborative culture and trust that will allow your team to thrive and accomplish their Sprint Goals. Teams that approach work as individual contributors instead of collaborators toward a shared goal create dysfunctions detrimental to overall success.
Don’t just take my word regarding their importance. The 2016 update to the Scrum Guide explicitly calls out the importance of the Scrum values. In fact, they are so crucial that scrum.org has even created an entire poster dedicated to them. If the founders considered them essential, then they deserve our attention too.
Neglecting collaboration puts team goals at risk and can lead to dysfunction. Teams that focus on individual contributions rather than working together towards a shared objective will struggle to build and maintain the culture of collaboration necessary to achieve Sprint Goals.
I can’t tell you how many times I’ve started back on Keto to be lured back into the grasp of big sugar when my mother-in-law brings banana Moon Pies into the house. You’ll slide back into bad habits if you don’t set the proper foundation.
I go into excruciating detail on the 5 Scrum Values elsewhere, but a brief refresher is warranted for this article. If this doesn’t satisfy your curiosity, you can check out frequently asked questions.
Lately, I’ve started considering the similarities between Scrum and canoe teams. There are so many correlations, and it’s a great way to explain the Scrum values in a way that incorporates some examples, is easier to follow, and isn’t as dull as what you’ve likely read a dozen times before.
Focus involves knowing what is important and having the determination to concentrate on it, even in the face of distractions or obstacles.
A canoe team that lacks focus might paddle in opposite directions, go off course, or get lost.
A Scrum Team that lacks focus will lose sight of the Sprint Goal, work on low-priority tasks, or forget about continuous improvement.
Openness is a willingness to share information and ideas.
A canoe team that lacks openness might be unable to provide critical feedback to a team member about their performance. This lack of openness leads to the stagnation of progress for the team.
A Scrum Team that lacks openness has reduced transparency and trust, which leads to weaker decisions, decreased collaboration on the team, and reduced skill-building on the Development Team. If left unchecked, this can develop into super chicken behavior, where individuals withhold information or assistance to maximize their success.
“Scrum is like your mother-in-law, it points out ALL your flaws.”
- Ken Schwaber
I want to point out another common misconception about the Scrum framework. Many people tout this as a silver bullet that will solve all your project management woes and guarantee success. The truth is, there is no magic solution. Rather than fix all of your problems, this framework, co-developed by Ken Schwaber and Jeff Sutherland, is more likely to highlight your flaws. Continuous improvement hinges on a willingness to embrace change, which is what openness is all about.
Respect involves treating others with dignity and trusting them to be capable, independent people.
A canoe team that lacks respect might manifest as one team member trying to control every aspect of the paddling leading to resentment and lack of autonomy among the other team members. The lack of autonomy can lead to a loss of efficiency, as the micromanager struggles to keep up with their duties and those of others.
A Scrum Team that lacks respect will struggle to collaborate. If left unchecked, this can lead to a dysfunctional behavior I refer to as the superhero complex, where individuals become convinced they are the only ones that can do the work and therefore take it all on themselves, cheating their teammates out of an opportunity to grow and learn new skills, thus further reducing the effectiveness of the entire team.
Courage is about taking risks and tackling challenging problems.
A canoe team that lacks courage might be unable to take on challenging rapids or speak up if something is wrong. God forbid someone passes out as the team rapidly approaches a waterfall. Worse yet would be the sudden inability to speak up when you’re the only one that sees an approaching iceberg.
A lack of courage on a Scrum Team can lead to similar issues. Most commonly, it will lead to teams avoiding impediments instead of resolving them. It can also lead to an avoidance of conflict that would have led to better decisions, avoiding difficult conversations that might help other team members improve, a lack of negotiation with the Product Owner resulting in an overcommitment during Sprint Planning, and being too afraid to innovate due to a fear of failure.
Commitment in Scrum is about being devoted to the success of the team, the Scrum framework, and continuous improvement.
A canoe team lacking commitment might not show up on time to a race or not pull their weight during an event. The lack of commitment can then spread to other team members, which creates an overall air of disengagement. The next thing you know, the team is gliding across the lake instead of knifing through the water to the finishing line.
A Scrum Team that lacks commitment will rarely complete their Sprint Goals, show up to Sprint events late or not at all, and do just enough work to avoid being fired. It should go without saying, but commitment is essential to achieve the benefits of Scrum.
The three pillars of Scrum are transparency, inspection, and adaptation. These pillars enable empiricism, which leads to continuous improvement. Removing any of these pillars renders the others useless, and without them, Scrum teams will stagnate.
I think that perhaps I have an addiction to metaphors, but I’m willing to take the risk of sounding like a lunatic because mapping concepts to other concepts helps me to make sure that I understand what I’m talking about. If it helps me, surely it helps others.
I’ve already said that the three pillars themselves are like the re-routing feature on a GPS that allows us to change our turn-by-turn directions based on new information, but I want to go down one more level to a related analogy.
Let’s compare the three pillars to a vehicle’s windshield, mirrors, and steering wheel.
Transparency is like the windows in a car, allowing you to see the road ahead and any potential obstacles. It provides the ability for you to inspect your surroundings.
Transparency helps build trust in Scrum teams. It removes obfuscation when we track work in the open (whether using information radiators or just electronic tracking tools that everyone can access). I don’t have to worry that everyone is hiding something from me because I can check the status of a Product Backlog Item at any time. The visibility into the work of the Development Team also helps build trust because you can see what is on everyone’s plate. You know why Harry hasn’t been able to give your pet project attention when you can see that he’s been working on higher-priority items. You no longer worry that he’s ignoring you because he doesn’t like you.
There are several ways we apply transparency in our daily work. The Daily Scrum event makes the Development Team’s work visible to anyone attending. We inspect the Sprint Goals and progress in the open during the Sprint Review. The Product Owner ranks the Product Backlog and makes it available for anyone to review.
Inspection is like the mirrors on a vehicle, allowing you to see what’s happening behind you and to your sides. They provide visibility into what’s happening with your surroundings, allowing for early detection of potential problems or roadblocks.
Inspection enables your Scrum Team to identify risks early on. It also allows continuous improvement as we will not know what to improve without inspection. Inspection also helps to build a sense of shared ownership. You know your work is visible to anyone at any time, and it’s just more motivation or peer pressure to do quality work.
During the Sprint Reviews, the team typically demos completed Product Backlog Items to get feedback on how we might further improve the functionality. In the Daily Scrum, we inspect the Sprint Backlog to evaluate our next steps toward completing the Sprint Goal. In the Sprint Retrospective, we inspect the outcome of our Sprint and discuss what improvements we can make. Our definition of Done usually includes several items related to quality which we’ll inspect for each User Story before we call it Done. These are all examples of inspection in our day-to-day work.
Adaptation is like the steering wheel, providing the ability to adjust course and navigate around obstacles as needed. It enables you to respond quickly to information obtained from inspecting your surroundings.
Adaptation allows the team to pivot and adjust its plan as needed. Adaptation is also how we implement continuous improvement. If we’re not changing, we’re not improving.
“We have come to value […] Responding to change over following a plan.”
- Agile Manifesto
We apply adaptation in various ways, such as re-prioritizing the Sprint Backlog based on new information, experimenting with new approaches to improve our processes, and implementing improvements identified in the Sprint Retrospective. For example, if we receive additional feedback from stakeholders or customers, we may adjust our Sprint goals or priorities to better meet their needs. Similarly, if we encounter unexpected challenges during a Sprint, we may experiment with different approaches or tools to find a better solution. Adaptation enables us to continuously improve and deliver value to our customers.
The Tripod of Scrum (aka Scrum pillars: transparency, inspection, and adaption) enables empiricism by providing a framework for gathering and analyzing data based on real-life experiences. Like a tripod, the framework falls over if any of the three pillars is missing or ineffectual.
Inspection without transparency is flawed. If it’s a super foggy morning when you’re trying to determine if switching lanes is safe, it doesn’t matter that you are trying to inspect your surroundings; the fog has obfuscated them. If you change lanes without being able to tell the road is clear, disaster awaits. Transparency is a prerequisite to inspection.
Adaptation can be risky if not done correctly. Without inspection, we risk losing visibility into our progress, incurring technical debt, and wasting valuable resources. If we make changes without input or a way to measure our success, it can be challenging to determine what is working and what isn’t. For example, if we change our process but don’t monitor its impact, we may not realize until much later that it’s causing delays or quality issues. To avoid these risks, it’s essential to regularly inspect our work and processes, gather feedback, and use data to guide our adaptations. By doing so, we can ensure that our adaptations are effective, efficient, and aligned with our goals.
Without adaptation, inspection and, therefore, transparency becomes waste. If I have no intention of changing my diet or getting more exercise, weighing myself daily is futile and demotivating.
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and helping the Scrum Team and organization to understand Scrum theory and practice. Trust is built when all embody the values.
As a Scrum Master, I do my best to encourage and promote these values within the Scrum Team. I work to establish psychological safety to enable courage and experimentation. I kick off each Scrum event with a centering phrase that reminds the Scrum Team why we’re here and reinforces the activities and mindsets that align with the Scrum values. If I feel the team is misaligned, I might run a retrospective focused solely on the Scrum values.
As a Scrum Master, it’s also my responsibility to uphold the Scrum pillars. I promote transparency by facilitating events that foster open communication. I also encourage inspection by asking powerful questions that encourage the Scrum Team to analyze and evaluate their processes and identify areas for improvement. I help ensure that adaptation occurs by reminding the team to include the most impactful improvements from the Sprint Retrospective on their Sprint Backlog during Sprint Planning.
The Scrum values and pillars are like the trusty compass and GPS that prevents you from getting lost. Without them, you’re blindly driving around, hoping you end up in the right place. So, keep those values and pillars close at hand, and enjoy the journey!