You are here

Do you like what you are reading? Do you want to receive more content like this, in your inbox?
I send out articles just like this to my newsletter about once per week. Subscribe now:
* indicates required
Do you like what you are reading? Do you know people who might be interested too?

Share This Page:

The Pillars of Scrum

Never miss one of my articles: Readers of my newsletter get my articles before anyone else. Subscribe here!

I have seen some implementations of agile software development and heard about several others that faced major difficulties. Difficulties that shouldn't exist in an agile project - Or that was what I thought. Then I re-read the Scrum guide, and the "three pillars" caught my particular attention.

Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.


By looking at agile implementations - and stories about agile implementations - through the lens of thos three pillars, I could understand the reasons for some of the difficulties. Today I want to show you how you can use the three pillars to understand your challenges. But first I want to quickly explain them.


Everybody who participates in creating an outcome must be able to obtain all the information she needs. There must be a shared understanding about what goals we want to reach and how we know that we have reached them.

All stakeholders (users, customers, testers, managers, operations, ...) should be able to find out what is happening in development. We invite them to our meetings (planning, daily stand-ups, review) so they know what we are doing. We create some standards (definition of ready, definition of done, policies) so we know how to work together. We share statistics about our process (lead time, velocity, throughput, ...) so everybody can plan what to do next.

On the other hand, the development team has to be able to find out things about the business too. We need direct access to customers and users to get fast feedback. We need to be able to find out the business reasons for features so we can suggest better or cheaper alternatives. We often need to know details about schedules, contracts and the funding of the project. We need to be able to see the bigger picture - How our software fits into the grand scheme of things and where we are going.

Transparency is only possible when there is trust. Without trust, nobody would share all the data they have. And, without trust, nobody would let everybody else do their work - We all would want to solve all the problems that are exposed by the available data ourselves. For example, when velocity goes down, all the other stakeholders must trust the team that they can solve this themselves. Without trust, every other stakeholder would probably try to intervene.


You need to frequently inspect what you are building, so you can react when something starts to go wrong. The scrum guide tells us we should "...inspect Scrum artifacts and progress toward a Sprint Goal...". You also need to constantly inspect if your "best practices" are still working. Times change, and yesterday's "best practice" might be today's road block.

This means, basically, that we have to track the features we have promised (or forcasted) to build during a sprint. We do this, for example, by tracking "done" user stories and tasks, where "done" means "implemented, tested and deployed to a production-like environment".

We also have to inspect the quality of the artifacts we produce. We know that we cannot trade quality for speed [1], so we have to ensure high quality to sustain our pace. We should use a combination of techniques to ensure high quality: Test-automation on different levels, test driven development, pair programming, code inspections, and so on. [2]

We also have to ensure that we are building what our users really need. This means that we have to constantly inspect if our understanding of their need is still accurate. And we have to inspect whether our software or product still allows them to reach their goals in an efficient and effective manner.

Then we have to inspect our process itself: Are we still working efficiently and effectively? Are we still delivering the most value for the smallest amount of money? What should we improve next?

Inspection requires trust, because when there is no trust, people would not allow us to see the whole truth. They would try to hide some facts and try to blame other stakeholders or departments for shortcomings.


Adaption means that we change what does not work or what could work better. It means that we constantly run small experiments, keep what is working and change when we fail. We use the results from our inspections to decide which experiment to run next.

Adaption requires trust. We will only be allowed to run experiments when there is mutual trust. We will only be allowed to fail when there is mutual trust. And we will only admit our failures when there is mutual trust.

The Foundation

Trust is the foundation on which the three pillars are built. You need mutual trust, or you'll have a hard time when you try to establish transparency, inspection and adaption.

How To Use The Pillars

You can use the pillars to assess your current situation. Maybe you see some difficulties you shouldn't have in an agile environment. Maybe you don't see any difficulties, but that does not mean that you don't have them: You might just have developed some blind spots [3].

When you assess your situation, first ask yourself: Is the foundation of the three pillars intact? Do we have mutual trust among all stakeholders? If you don't have the trust you need, your pillars stand on shaky grounds and you should work on that first. But you can still use the pillars to further assess your situation.

Look at each pillar and ask yourself: How strong is this pillar in our company? How strong is it in our team? What problems might arise if this pillar is not strong enough?

You can also do this in a retrospective with your team - or even with all stakeholders of your current project. Then you ensure that there is a shared understanding of what you need to successfully remove your difficulties.


Often problems and difficulties with agile software development are caused by a lack of trust, transparency, inspection or adaption. When you understand which of your problems are caused by those factors, you can start to change.

Take some time to analyze your current situation with regard to the three pillars (inspect) and then start a small experiment to change for the better (adapt). Tell everybody what you are about to change (be transparent) and trust them to trust you.

What problems are caused by those factors in your team? How can I help you to mitigate them? Please tell me!

[1] See, for Example "Code Complete, second edition" by Steve McConnel, page 474: Software with fewer defects is developed faster and cheaper.

[2] I am currently writing a series of posts about simple design, which also touches those topics. Read more here: Simple Design

[3] Find out more about blind spots and what you can do about them in my free online course Improve your Agile Practices.

My name is David Tanzer and I have been working as an independent software consultant since 2006. I help my clients to develop software right and to develop the right software by providing training, coaching and consultanting for teams and individuals.

Learn more...