The three pillars of scrum

Most practitioners associate the tenets of the agile manifesto as guiding principles in executing their scrum agendas. In this article, With the premise of Scrum optimized on empirical process control, I wanted to spend some time looking into the three pillars of Scrum theory: transparency, inspection and adaption and provide some annotation on what they really mean, and why these pillars should be the foundations of your practice.


Scrum is a framework, and frameworks work when you create a mutual set of transparent standards that are understood and accepted. From cadence in communications to understanding user acceptance criteria and definition of done advocated for during planning, transparency is key to expectations within the Scrum team and associated stakeholders.


As opposed to the waterfall sequential process of gathering requirements, building, testing, and publishing, Scrum prides itself on a circular iterative process. You build in iterations, inspect, adjust, and build again. Throughout the sprint, it is encouraged that scrum members validate the work they are doing with the product owner, facilitating incremental inspection towards ensuring trajectory to definition of done. Inspection allows for accounting for the unexpected conditions that may either prevent definition of done, or reduce the level of its overall success, however it is also important that the inspection mechanism isn’t overused at the expense of productivity and velocity, ultimately disrupting work. This of course sounds very familiar to engineers who employ test-driven programming, asserting a test suite of use cases accounting for known variances that map with the definition of done.


The fundamental superpower of Scrum is in its ability to encourage pivoting, shifting gears and direction based on feedback. Following on from inspection, adaptation allows you to learn and change what isn’t working, rather than commit to the project based on steadfast requirements gathered at a singular point in time. But not just the idea is open to change, but the process itself. As a framework, Scrum allows you to augment and adjust to your needs, and this pillar gives you the mandate to adjust communications, cadence, sprint length, inspection checkpoints accordingly.

Embracing the Agile manifesto

Something as a practicing program manager I tend to always use as tenets when guiding teams, is relying on the spiritual bible of contemporary project management, and that’s the Agile Manifesto. Products of the Agile Alliance, the premise of the Manifesto is to simplify the practice of project management through a lightweight framework to build software expeditiously with bias for customer validation over processes and documentation and red tape.

The two drivers behind the manifesto are iterative and incremental development, over pre-medicated and over planning, and creating higher quality software in shorter time, or more concisely, build more with less.

The Agile Manifesto

I see the Manifesto as guiding principles, tenets as I mentioned earlier on, rather than rigid and enforced rules, advocation for the spirit rather than the letter of the law. So does the Agile Manifesto entail?

Individuals and Interactions over Processes and Tools

To me this infers bias towards the human element over procedures. Engaging customers, stakeholders, other team-members. It is not to say that processes and tools aren’t important, but the scales should favor people over process.

Working Software over Comprehensive Documentation

Following the spirit of being lightweight, don’t focus on heavy documentation, over-planning but build early, build fast, and iterate fast. It is therefore emphasized that working software that meets user acceptance criteria, even incrementally, over detailed documentation.

Customer Collaboration over Contract Negotiation

The Agile mindset is one that is flexible, and embracing requirements that can change. Pivoting is something that has to be accepted. This is not to say that contracts aren’t also important, but getting the right requirements from customers is favorable to rigid contracts.

Responding to Change over Following a Plan

Change is inevitable, the only constant is change, and that’s why heavy documentation is doomed to failure, because of the nature of change. Instead build components in a decoupled and nimble manner that fosters change, and work in an environment that allows you to react to changes based on new understandings.

The Agile Manifesto does not suggest that we do one over the other; rather, it advocates that while all of the mentioned items are important, some are valued more than the others.

PMI-ACP Project Management Institute Agile Certified Practitioner Exam Study Guide J. Ashley Hunt