What Are: The 3 Pillars of Scrum?
Have you ever heard someone say that Scrum’s foundation is an empirical process? If so, is it clear from just saying ’empirical process,’ what that means? Yeah, probably not, right?
In a nutshell, consider that true knowledge (not opinion, hypothesis, or assumption) is gained through experience. When we make decisions based on knowledge-from-experience, we are demonstrating empiricism. One of the strongest competitors to Empiricism in the workplace, is Tradition. Many times, we find that there is process in large organizations, only because they’ve “always done it that way.” Current Traditions could actually be based on past Empirical Evidence. However, when that evidence no longer applies to the instance, a past empirical process becomes a current and future tradition.
All Empirical Process Control systems are supported by three pillars: Inspect, Adapt, Transparency
Imagine a factory floor. Let’s zoom in on one station. An assembled part (or parts) arrives. It is that station worker’s responsibility to add more parts to the assembly, or configure the existing parts already on the assembly. Periodically a Quality Control technician will step in and inspect the sub-assembly, before the worker can perform his duties. This happens all over the factory, at every station, and at periodic intervals. The Quality worker is looking for certain trends in high and low quality assembly of the parts, as well as each individual part’s quality. When low Quality scores are detected, decisions are made to take certain action immediately to bring Quality back up to preset standards.
We do this in Scrum as well. We inspect the Scrum Artifacts (Product Backlog, Sprint Backlog, Increment) at intervals that make sense. Inspecting too often creates unnecessary bottlenecks in our flow. Not inspecting often enough causes inefficiencies to run amok in our systems. This could be dangerous to our workers, customers, and revenue.
Upon Inspection, we act. Acting responsibly, we either maintain the current action or take corrective measures. Te corrective measures can be considered Adaption or Adaptation. Adapting quickly to the current state ‘of things’ is crucial in almost all responsible systems. History is littered with many examples of people, companies, and military units that did not adapt even when they had inspected the current environment.
- Kodak did not adapt to digital photography.
- Blockbuster did not adapt to non-physical media video viewing.
- Louis XVI & Marie Antoinette did not adapt their spending habits to accommodate the needs of the French people (thus starting the French Revolution).
In each of these cases, information had been gathered and made available (Inspection), but the appropriate measures to ensure their futures were not taken. Why? Different reasons. Typical reasons point to laziness and ego-centrism. For these particular cases, I can only assume that the last case (Louis XVI & Marie Antoinette) was due to ego-centrism.
In some industries, Transparency can become a dirty word. All too often, it is misconstrued. So either way, people are getting the idea wrong most of the time anyway. Transparency, in relation to Agile environments, refers to our need for clear, concise information. When we need it. In a way everyone can understand it.
In a large part, transparency builds trust, removes barriers, and cuts confusion and information hording. So, in many ways, it speeds up time that is usually lost waiting for responses and clearing up miscommunications.
It might be easier to properly describe Transparency by giving examples…
Example 1: A team posts their Sprint Goal, their previous Sprint Burndown Chart (complete with legend and notes written right on the chart), Release Burnup Chart, a list of all Team Member names, a signed Team Working Agreement, and their Definition of Done on both sides of their team room door. Also, on the outside of the door is a sign: “When the door is closed: Pigs may enter. Chickens must wait.” Everything needed to describe the team, their recent rate of delivery, and even their team’s attitude (or sense of humor) is right there on the door.
Example 2: The team’s Product Owner is invited to a meeting where the Senior Vice President of Very Important Things says the focus of Product Management is going to shift away from their current focus and toward a completely new customer segment with completely different demands. The SVP says this shift will begin next month and be in full swing by the beginning of the next quarter. When the Product Owner returns to the team room after the meeting, they immediately start a conversation with the entire Scrum Team about the imminent focus shift, and how they are collectively going to need to find a way wrap up what they are doing and develop a new Product Backlog.
Example 3: Buffer, a social media management platform company, is completely transparent with all of their employees’ salaries. A Google doc is open to the public so everyone in the world can see the salaries.