From the course: Agile Software Development

The scrum pillars (TIA)

From the course: Agile Software Development

Start my 1-month free trial Buy for my team

The scrum pillars (TIA)

“

- Scrum teams plan their work around what they know based on evidence and their experience at that specific point in time, and they continue to adjust their plan as they learn new facts. Scrum is based on three key styles of execution. Think of these as the three pillars of Scrum. Transparency, inspection, and adaptation, or TIA. These three pillars support each other. Any aspect of Scrum can only be inspected if it is visible, so transparency at every stage is crucial. You can only inspect something if it is transparent, and you can only adapt something that you can inspect. Transparency is achieved by making every aspect of the work, such as artifacts, processes, products, or issues, just to name a few, visible to those that could be impacted. Scrum evens our design to inspect every aspect of the product and processes to build it. Inspection is followed by adaptation. Scrum teams adapt their work and approach to fix deviation from their desired goal or to continuously improve the product and plan estimates. To illustrate the importance of transparency, I'll share a real world example. I once visited a company that had successfully adopted Scrum. Their office had a large hallway with their walls covered with charts, documents, and a few TV monitors that displayed a summarized view of the state of their project. They displayed information about work, such as Sprint status, bill status, defect count, statistics by work item count, and much more. These dashboards are called information radiators. You don't need a status meeting to know the state of your team's work, you just need to walk into their war room and you will know everything in minutes. This is a great way to maintain transparency. One of the ways Scrum maintains artifact transparency is by how done is defined. All Scrum artifacts are considered to be either done or not done, and the definition of done is understood by the Scrum team and external stakeholders. Some Scrum teams may define done completely differently than other teams working on similar projects. What is important is that all members of the team and all stakeholders have a clear definition of what done means before starting a Sprint. Agile Organizations and Scrum teams continue to define done more stringently as a part of their commitment to continuous improvement. This approach enhances transparency, because all the stakeholders understand what to expect from the artifacts and know where the team stands. The Scrum team finds it easier to estimate their work, because there is no ambiguity about the state of Scrum artifacts.

Contents