The Three Pillars of Scrum and Why You Should Understand Them

What is empiricism in Scrum?

The core of Scrum is an empirical process. Based on the Scrum Guide, “Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.”

So you draw conclusions only from experience, facts, and evidence. You never stop learning from your actions—or your mistakes—and your progress is based strictly on observations of reality instead of abstract plans or personal opinions. Empiricism also invites you to innovate and experiment with different ways to develop your product.

However, Scrum theory is easy to figure out but difficult to master. For your team to really benefit from implementing Scrum, you should completely change your way of thinking about product development and self-organization. How can you meet this challenge? By familiarizing yourself with the concept of the three pillars of Scrum in practice.

What are the three pillars of Scrum? What is the role of the three Scrum pillars in practice?

The three pillars of empiricism at the base of the Scrum framework are:

transparency,
inspection,
adaptation.

They’re what makes Scrum successful. Without them, you’ll risk wasting your time and going around in circles, making no progress. Let’s look at them more closely.

1. Transparency

According to the Scrum Guide, “The emergent process and work must be visible to those performing the work as well as those receiving the work.” It means that every part of the process should be clear as day for everybody on the Scrum Team.

Transparency allows each team member to track and understand what’s really going on in each sprint—what the plan is, what the progress is, and what the planned input and outcome are.

What does transparency mean in the Scrum environment?

Daily meetings, when the team needs to synchronize their work and efforts, are a perfect opportunity to practice transparency. But really, you should do it all the time. Immediately discussing any concerns you might have allows you to quickly find a better solution together with your team.

Without transparency, the solution may never come to your mind and your progress may be slower. That is why openly voicing your concerns, discussing challenges, and admitting you need help are crucial in Scrum.

Moreover, check if everybody feels comfortable asking questions, expressing their thoughts, and sharing the current state of their work. Make sure to encourage people to exchange information and ideas freely without the fear of being judged. Create an environment that recognizes experimenting, and make failing and learning a natural part of the process.

In addition, inform all stakeholders, even clients, on the actual state of the product and don’t keep any negative information from them. Remember to share facts, not opinions, and nourish the trust between you and the stakeholders.

However, you should be mindful of “bad” transparency, which is merely reporting and sharing what everyone’s doing. You want to focus your efforts on the outcome and the value for the user, and you won’t be able to take any actions based on a simple report.

You should also keep in check your designated tasks; if only two out of three are connected with the sprint goal, tackle those two. Make sure you’re focusing on what’s most important and discuss everything. Remember, you don’t want to just keep track of status updates. You’ll want to check whether you’re going in the right direction to meet the goal and provide value to the user.

What can you do for your team to improve transparency in Scrum?

First, introduce the Scrum roles if you haven’t done so already and make the Scrum Master the one accountable for taking care of the transparency. Second, use a universal language that will be easy to understand for everybody on the team. Don’t be too technical, no matter the industry.

Additionally, you can also use burndown or burnup charts and a whiteboard to visually present your progress towards the sprint goal to keep your team aligned, informed, and motivated.

2. Inspection

“The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems,” the Scrum Guide explains.

Inspection is done by everyone involved in the project, though it should be supported by the Scrum Master, collaborating with the team in all aspects of the process. Together, they diagnose any unplanned deviations from the sprint plan and create opportunities to review them. Every Scrum event should be used for inspection.

What do you inspect in practice?

Apart from the product itself, you can also inspect all the other aspects of the Scrum framework, from processes to people. You can then ask some more or less specific questions, like:

Does the Scrum Team have all the skills necessary to do their work?
Is the team delivering a Done Increment in each sprint and providing new value to the product?
Are they implementing any potential improvements?

During sprint planning, you should inspect what you already have planned and what you would like to move to the next sprint, then build your sprint around that. Go through a part of the process and check if what you’re doing is transparent, clear, and understandable to the entire team.

However, you shouldn’t just measure how quickly your team works and how productive it is. Yes, numbers can help, but it should start with the context and understanding of the situation—only then should you look at the numbers. If you focus only on them, you won’t be transparent, and inspection without transparency will be misleading and wasteful. What’s more, strict calculations and pushing hard won’t motivate your team at all.

What can you do to inspect better?

Well, first and foremost, follow the rules by the book. They are there for a reason. Then go deeper and use context. Try not only to fix the problem but to inspect the cause of it, too. You may invite the stakeholders and users to the sprint review and check if the product is usable.

At the daily meetings, you can inspect and review the whole strategy. Check if you haven’t overdone anything and suggest an easier way to do something next time. Choose smaller aspects of the process to inspect more often, so you’re able to test some ideas out and see how they work from the very beginning. Finally, you can inspect Scrum itself on the sprint retrospective—whether it’s working for you or not.

Here’s something to think about: sometimes, too much of a good thing is too much. Don’t tell your team every single detail of their work. Ask yourself, how much information does the team need to be the most effective? What do they need to know to get creative? What should you tell them? Inspect wisely.

3. Adaptation

“If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted,” the Scrum Guide notes.

Remove what needs to be removed after a thorough inspection and adapt to the new situation and circumstances. Learn from your actions and mistakes.

What are some good ways to adapt?

It may surprise you, but you shouldn’t always do everything the same way. Try something new every now and then.

However, always include a moment for another inspection within your adaptation to check if you’re doing the right thing. You can ask for some feedback at the sprint review.

You might be wondering, when is a suitable moment to experiment? The answer is: all the time. However, be sure to try out only one new thing at a time to prevent chaos. That way, it will be also possible to verify if this particular idea is working. Have everything neatly organized and segregated. Think small.

What is “bad” adaptation and how to avoid it?

Adaptation influences your work most directly. This third pillar is also one of many things distinguishing Scrum from the “waterfall” style of product development, where everything is rigidly planned way ahead and the whole process conducted strictly according to the rules.

In Scrum, if you don’t change what isn’t working for your team and product, or what could simply work better and faster, you’re not adapting—and if you’re not experimenting, you’re not progressing. “Bad” adaptation is not being flexible at all, or, on the contrary, being much too flexible.

Every refinement should be based on empiricism and the progress made only with the observations of reality, deep analysis, and drawing conclusions from your team’s individual and group experiences. You should put aside any personal opinions and abstract ideas, even those sounding great, and align tests with your events and artifacts.

Moreover, your adaptation depends on being creative, too. Sometimes, unusual conclusions will be drawn from your inspection—that’s when creative thinking comes into play, and it will often take a lot of invention to develop the best product.

And what does it mean to be “too flexible” in Scrum? At times, to avoid stagnation the team will experiment too much, too randomly, and not exactly the right way. They may even take only some parts of the Scrum methodology and try to make them work. It’s risky and we don’t recommend doing that. You should implement every guideline to avoid chaos and confusion.

Do you really need to follow all three Scrum pillars?

In short: yes, you do. There’s quite a lot to digest here, but focus on transparency first. It’s the most important one of the three Scrum pillars. If the problem you’re experiencing isn’t clear, you will continue to further deviate away from your goal and probably inspect and adapt the wrong way, too.

Sometimes, you can actually focus only on adapting—simply experimenting with some ideas and brainstorming new ways to develop the product. Then again, it will be necessary to carefully inspect and ask why you’re even trying something new. Maybe your team is bored with the current situation and needs a breath of fresh air?

As you can see, all three pillars are inseparable and strictly connected. You can’t have one without the others.

Who is responsible for taking care of the three pillars of Scrum?

Simply put, everyone. Your whole Scrum Team should organize itself around the three pillars of Scrum, understand and remember them at all times. What’s more, you should also meticulously analyze how the team takes care of transparency, inspects and adapts, and draw some conclusions for future improvements. Your Scrum Master should educate and coach you on how to do it best.

Summary: Why should you use all three Scrum pillars?

Using all three pillars will allow you to find adequate solutions to your problems, be more effective, come up with new ideas, experiment more creatively, and eventually build faster. Without transparency, inspection, and adaptation, you can’t successfully implement the principles of Scrum into your business.

So make room for open discussion, then check if everything meets your expectations, then adapt by experimenting a little bit here and there. Afterwards, since the process is cyclical, you can just start it all over again.

Final thoughts on the three pillars of Scrum

Thank you for reading our article on implementing the three Scrum pillars in your team. We hope it’ll help you achieve better business results.

At STX Next, we have many experienced Scrum Masters who are passionate about their work and would love to share their Scrum expertise with you to help you not only with the three Scrum pillars but also any issues you may have.

If you enjoyed this guide, we have other useful resources on Scrum and Agile you might be interested in, such as:

We’ve helped many other companies worldwide boost their productivity with our Scrum specialists—you can check them out here.

If you’re building a product and need support with team composition, drop us a line and we’ll gladly expand your team with the best Scrum Masters in the industry.