Scrum Pillars

You don't learn by thinking You learn by doing and observing. Knowledge is information; learning is action.

Learning is being able to do something that you couldn't do before. Incorporating information is not learning; it is simply knowing more. You learn by doing, and by doing, you can learn to do more, more effectively.

You must learn which is the correct product to generate in people the behaviors you want to promote.

This type of learning cannot be achieved in the academic field; you will achieve it in the practical area by observing, analyzing implementation, and discovering the use people give to the products you build.

You learn by observing and adapting. Observing and adapting. Observing and adapting.

Transparency, Inspection, and Adaptation

Scrum is a framework that allows you to control the process empirically, relying on observation to induce adaptation. Its pillars are transparency, inspection, and adaptation.

Imagine those old and colossal steam locomotives that powered their wheels using arms that ran through their entire length on each side.

If Scrum were one of those steam engines, each stroke would be a learning period that we call Sprint.

Scrum Sprints, like steam locomotive strokes, come one after the other, slowly but surely. Each Sprint will help you learn and improve.

Steam locomotives have two sets of wheels and arms, each going on one track. One set of wheels and an arm to the right goes on the right track, and one group on the left goes on the left track. In Scrum, these two tracks are the product and process paths.

In short, there are two tracks, and when Scrum advances, Sprint after Sprint, they will go looking for improvements in the product path and improvements in the process path. We will call the first path product evolution, and the second path we will call continuous process improvement.

Within a Scrum Sprint, there are several events. Each of these events is related, in one way or another, to one of the three pillars, transparency-inspection-adaptation, and one of these two paths: product evolution or continuous process improvement.


Being transparent means deliberately making information visible.

Important decisions made in Scrum are directly tied to the information you have. To reduce risk in decision-making, information must be visible and within reach of everyone involved. You will achieve transparency by making agile scrum artifacts visible and guaranteeing that everyone, team, and stakeholders, can access them.

Transparency goes both ways, not just from the Scrum team to those outside the team, but also from the stakeholders towards the Scrum team.

Trust also increases transparency. Feeling that you are creating an environment where there is trust, where people do not need to be wary of others, where everyone respects each other, encourages them to openly tell what they observe and say what they think. That is also transparency.


Both product evolution and improvements in the creation process should be inspected frequently. Product evolution will bring you closer or further away from the desired objective. You will discover deviations along the way since you are in a complex context where it is difficult to make predictions (that is why you use Scrum). Therefore, you must inspect if the assumptions on which you have based your decisions are still adequate or not. You can do this once the product has evolved, not before.

In Scrum, we call the evolution of the product, Product Increment. There is an artifact in Scrum that we call Sprint Review and is the event towards the end of each Sprint that has the objective of inspecting that Product Increment.

Continuous improvement of the product creation process will make you more or less efficient in your work, Sprint after Sprint. This improvement should also be inspected to ensure that the assumptions you have based on your decisions to change the way you work were correct. Every Sprint culminates by examining the changes to the process and its efficiency. This happens in an event we call Retrospective.

As you can infer, these product increment inspections, in the Sprint Review, and process inspection to become more efficient must happen within a context of complete transparency in the Retrospective. Otherwise, you are likely to end up inspecting a reality that is not true and thus making the wrong decisions moving forward.


If you find that the product is deviating significantly from the goal or the product development process is going beyond tolerable limits, you will need to make adaptation decisions. This adaptation should occur as soon as possible to avoid further deviations.

In the Retrospective event, you will make decisions to adapt the process, and this implies making decisions to change the way the team is working.

As soon as a new Sprint begins, you will make decisions to adapt to the product. Scrum has an event dedicated to this; we call it Sprint Planning.

As you can see, Scrum encourages change in both the process and the product. Scrum is deliberately designed to usher emergent practices in learning and adaptation and motivate successive scope changes to the product.