Based on empirical process control, the three pillars of Scrum are transparency, inspection, and adaptation. The nature of software development is complex and hard to predict, especially when it comes to the inputs and timelines(estimates and release dates). However, the outputs(Features/Stories/Product Backlog Items) are well defined.
One way of thinking about an empirical process would to think about a heater trying to maintain a desirable temperature of a room. It’s hard for a heater to determine exactly how much heat or exactly how long to generate heat to hit a specific temperature. So, instead, when needed, the heater just makes sure that it is injecting air that is warmer than the room temperature, and it simply keeps inputting that heated air until it senses that the current temperature is the desired temperature. At this point, it turns off for a while, until that temperature needs raising again. The key to the whole process is that the heater knows exactly what the current and desired temperatures are, and it keeps inspecting and adapting (turn heat on, turn heat off) its inputs until it reaches the desired temperature. The reason the heater is able to operate in this manner is that it has a transparent view into the current temperature. If you remove that transparent view, the heater does not know how to adjust itself to meet the desired temperature. In fact, that heater would probably never be able to keep a room hovering near the desired temperature.
So, in the same way the heater needs a transparent view into the current and desired room temperatures, the different Scrum roles and stakeholders need a transparent view into the software development process. Said another way, transparency allows the Scrum Team and its stakeholders to inspect and adapt the software that is delivered by the Scrum Team. This cyclical process is commonly referred to as a “feedback loop.”
Scrum bakes in numerous feedback loops. Let’s modify that just a bit. Let’s say that Scrum bakes in numerous “collaboration loops.” Each Scrum collaboration loop has a primary audience that is responsible for optimizing the given process. For instance, the Sprint Review’s primary audience is the external stakeholders. The external stakeholders give feedback and collaborate on the new software so that the Scrum Team may “tweak” or “improve” their ability to deliver Product Backlog Items. Another example is the Sprint Backlog and Sprint Burndown, whose primary audience is the development team. The development team members give feedback and collaborate with each other to help optimize work efficiency. There are several other “collaboration loops” in Scrum as well.
Bringing it back home a bit, the best transparency leads to the best collaboration loops. Investigating a bit further, we realize that the best transparency often requires some minimal data collection. Think of a football team. They’re so focused on playing the game to the best of their abilities that it’s often hard for them to remember everything they did on the field so that they can improve. A simple piece of data collection, a video recording of the game, increases transparency exponentially, and allows the team to learn from their experiences and improve. In Scrum, maximizing transparency often involves some simple data collection. So long as that data collection and presentation is being used according to the Scrum Guide, the Scrum Team and those new to Scrum should not fear it.
In conclusion, transparency is an absolutely essential pillar of Scrum, and that pillar works hand in hand with the other two pillars of Scrum, inspection and adaptation.