A deeper understanding of…
Empiricism: Transparency
Road to PSM III — Episode 2
[revised for 2020 Scrum Guide update]
What a word: “Empiricism”. I knew little about what this word meant before I went down Scrum’s rabbit hole.
I learned that I wasn’t the only one. In fact, almost no one I work(ed) with knew what it meant. When I ask students and colleagues what they think it means, I usually get responses like expansion, building an empire, hierarchy, command and control. But that’s far off the mark.
Empiricism has nothing to do with the term empire. Empiricism stems from the Latin empiricus (from Greek empeirikos), which can translate to experienced and skilled. It doesn’t relate to imperium, which comes from imperre, meaning to command.
Empiricism is the act of making decisions based on what is actually experienced.
Scrum is built on the three pillars of Empiricism. If these aren’t upheld the whole framework is unsupported and thus unstable.
Empiricism is about finding better ways through doing. You can also find empiricism at the heart of Agile. After all, the first line of the Agile Manifesto reads: “We are uncovering better ways of developing
software by doing it and helping others do it.”
Scrum is the empirical approach to process control. It facilitates emergent processes, methods, patterns, and practices.
This chewy stuff is to be taken seriously.
Transparency
Yo dog, let me create some transparency over the term transparency.
Developing Transparency in Scrum is a journey:
“Transparency doesn’t occur overnight, but is a path.” — The Scrum Guide 2017
The journey generally starts by developing a shared understanding. Like: “Do we both have the same understanding of what Done means?”. Naturally, this shared understanding also applies to understanding Scrum’s roles, events, rules, and artifacts.
Consider the difference between looking at things to get a better and shared understanding of work and performing inspection, which is about comparing the current state with the desired state; This provokes change to move closer to the desired state.
For empiricism to work, all Scrum artifacts must be transparent. Without transparency, inspections will be misleading and that would result in poorer decisions and less creativity. This increases risk and diminishes the value. A lack of transparency may also breed mistrust.
Developers might contribute to decreased transparency by not being open about the work and challenges (hidden work). A Product Owner might decrease transparency by poorly managing the Product Backlog, such as making it inaccessible to team members, or by not having it clearly ordered.
Decisions to optimize value and control risk are made based on the perceived state of the artifacts. Every event in Scrum can improve transparency over artifacts. Transparency can be improved throughout the Sprint.
The Sprint Planning improves transparency as the Product Backlog with its Product Goal provides the Scrum Team with an understanding of how to add value to stakeholders. The Scrum Team defines a Sprint Goal and their Sprint Backlog emerges.
The Daily Scrum provides transparency as developers inspect the progress toward the Sprint Goal and provide visibility over the work needed to achieve it in the Sprint Backlog.
The Sprint Review provides transparency over the latest increment indicating progress toward the Product Goal. New learnings are captured and feedback is elicited as the Product Backlog is updated to reflect them.
The Sprint Retrospective can be used as an opportunity for the Scrum Team to plan on how to improve transparency on the artifacts.
The commitments on the artifacts in Scrum exist to increase transparency:
- The Definition of Done for the Increment.
- The Sprint Goal for the Sprint Backlog.
- The Product Goal for the Product Backlog.
Additional practices that can improve transparency are refinement and ordering of the Product Backlog, and decomposition of Product Backlog items, which happens when needed throughout the Sprint.
Inspecting the Product Backlog item against the Definition of Done also improves transparency on the progress of Product Backlog items to the envisioned Increment. Inspection of the increment provides transparency on the progress you are making toward the Product Goal.
Developers can increase transparency on the Sprint Backlog by being open about the work and the challenges.
The artifacts are made transparent by ensuring they represent a real-time, highly visible picture of the work and that there is a shared understanding of what they reflect.
“In complex environments, what will happen is unknown.”
The Scrum Guide should have opened with that statement. It continues with “Only what has already happened may be used for forward-looking decision making”.
In Scrum, processes are accepted as being imperfectly defined. And let’s be clear about this: stop inspecting backlogs, burn-downs, plans, dashboards, and trend graphs, if you aren’t first inspecting the actual state of the increment against your envisioned Product Goal. Hence it is important that the Increment is an actual, done, working thing that can be experienced and inspected. So no… not a concept of that thing, like designs, wireframes, sketches, architecture drawings, database models, technical specification documents, and whatnot. These are not considered working increments. You can’t cheat your way back into Waterfall by considering the Increment to be one of those. Sure, some of these may be needed to come to a working Increment (but probably not as much as some might think).
Overproduction and excessive by-production is the most harmful source of waste. Don’t fall into the trap of sharing Big Design’s Up Front (BDUF), requirement docs, and architecture specs. These instantly set expectations that are nearly always impossible to meet, let alone exceed. They say little or nothing about feasibility, level of quality, and speed of development, and need for maintenance of the actual product.
Remember, with Scrum, this holistic picture emerges and changes throughout the product lifecycle.
Sure a designer or architect may draft these artifacts as exercises to get a more holistic picture, yet should be careful about sharing these outside the team as they often set unrealistic expectations.
The working product is the primary measure of progress.
Great visual design only says something about the quality of the vision and the talent of the visual designer. You can’t tell how good and fast the team is at delivering that which is needed in the end: a working product. It doesn’t tell anything about the quality produced or the stability of the finished product. It tells little to nothing about the function or behavior. You get a whole lot of nothing that sets a whole lot of expectations.
I know a great childhood story about just that…
The Emperor’s Clothes
Perhaps such a complicated, confusing, and abstract term like empiricism can best be told through a childhood story; and maybe I can be cheeky in creating a connection to the word ‘Emperor’ too.
Remember The Emperor’s Clothes by Hans Christian Andersen?
Try to apply this narrative to your organization:
This story is about a vain emperor who really likes to show his worth by displaying only the finest attire. The Emperor continues to demand even better quality until the weavers are at a loss on how to achieve this. Nothing can be produced that is good enough yet his demands only go up. This is until some devious men show up and explain they use only the finest fabric available — so fine even, that it is only presentable to those who are wise or pure and are fit to hold their title or position.
“If I wore them, I would be able to discover which men in my empire are unfit for their posts. And I could tell the wise men from the fools,” the Emperor thought.
Thus the Emperor gave the order…
“I’d like to know how those weavers are getting on with the cloth,” the Emperor thought, but he felt slightly uncomfortable when he remembered that those who were unfit for their position would not be able to see the fabric. It couldn’t have been that he doubted himself, yet he thought he’d rather send someone else to see how things were going.
And so the Emperor sends in his best and most trusted minister.
“Heaven help me,” he thought as his eyes flew wide open, “I can’t see anything at all”. But he did not say so. “Can it be that I’m a fool? […] Am I unfit to be the minister? It would never do to let on that I can’t see the cloth.”
Just to be sure, the Emperor sent other emissaries. All were tremendously positive about the quality and the colors of the fabrics used in the production. The word soon spread through the town.
When the Emperor receives his new attire, a charade is put up to dress him in this invisible attire.
“What’s this?” thought the Emperor. “I can’t see anything. This is terrible! Am I a fool? Am I unfit to be the Emperor? What a thing to happen to me of all people!” — “Oh! It’s very pretty,” he said. “It has my highest approval.”
And so it came to be that the Emperor was spectacularly paraded naked through town, and the men and women in the audience, confused at first, looked around and heard the shouts, “Oh, how fine are the Emperor’s new clothes! Don’t they fit him to perfection?”
And so the crowd cheered, and the Emperor thought,
“What an amazing success!”
But then an innocent little child said…
“But he isn’t wearing anything at all!”
The Emperor, ashamed though noble as he was, continued his walk even more resolved than before.
“This procession has got to go on.” he thought.
Now I love this story and find it bizarrely fitting to the modern corporate landscape. It also touches on both transparency and visibility. Everyone is so focussed on what should be, that everyone is ashamed and afraid to inspect and call out what actually is. Even the Emperor failed to inspect the progress being made, fearing what he’d see until confronted at the very last moment when expectations are set… and the show must go.
Now consider the Emperor to be the CEO, the clothes to be the product, the minister as the Product Owner, and the weavers to be the Development team. The audience as stakeholders, and the little innocent boy is the end user.
“But this Increment doesn’t do anything at all!”
The little boy shouted out during the Sprint Review. Presenting a PowerPoint isn’t a demonstration of a working product.
Observe what is
Thus transparency requires all aspects to be commonly observed and understood with open honesty.
Decisions and expectations are (or should be) based on the perceived state of the Increment and related artifacts (that say something about the potential to-be state of the increment).
When these observations aren’t complete or correct, or if there are different understandings about the perceived state, decisions will be flawed, progress will not be predictable, the risk is not controlled, conflict will occur and value goes down the drain.
When you are not looking at the boo’s, poor decisions will be made and they’ll come back to haunt the team.
What if all the bad stuff is obvious but not called out? What if it is, but ignored? The military calls this S.N.A.F.U. or Situation Normal All Fucked Up.
Now, having read all this, please think for a minute about the value of the Daily Scrum and the Sprint Review in relation to transparency. If someone is late, or absent during one of these sessions… or what if a team member isn’t completely open about progress made, or impediments encountered? how does this impact transparency? What if the team doesn’t collectively collaborate daily on the Product Backlog, or Sprint Backlog… what risk does this introduce?
Another result of poor transparency is Technical Debt. Technical Debt is the result of those poor choices made. Technical Debt is scary stuff.
The primary culprit I have witnessed/observed/experienced is that estimations set expectations and are thus treated like deadlines. This happens when developers are encouraged to make something appear done within a given timeframe, rather than taking the time actually to make it right. “We’ll fix/improve it later” is a mantra that kills products.
Definitions of Done create transparency over the Product Increment. I’ll cover this more in the next episode on Inspection.
The Scrum Master and Transparency
“The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency […]. This work usually involves learning, convincing, and change.” — The Scrum Guide 2017
So how can you, as Scrum master, best contribute to this fundamental pillar of Scrum?
Well, for example, a Scrum Master can
- Coach the Product Owner in clearly communicating the Product Goal.
- Coach the Scrum Team in living the Scrum Values.
- Teach the Scrum Team and Stakeholders about the Scrum Framework.
- Facilitate Scrum events which provide opportunities to create transparency about the current state of affairs, enabling inspections toward goals.
- Make sure the events start on time, everyone is present, and that they are truly eventful and not ceremonial conclave.
- Be open about mistakes.
- Provoke untold stories.
A Scrum Master can also listen actively and ask powerful questions such as:
- “Let’s take a look at this together?”
- “Do you want to work on this together?”
- “Is this right?”
- “What do you think about this?”
- “Do you think the same?”
- “What’s the first next step?”
- “What can you do now?”
- “How would you go about this?”
- “How can we make this even better?”
- “Did we miss anything?”
- “Is this how it should be?”
- “How are you?”
There is much more the Scrum Master can and should do and we’ll cover this later when we address the role of the Scrum Master in its very own episode.
“ The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t.”
Continuing this series, I will cover each accountability, event, and artifact to illustrate how those relate to transparency. But first, I will cover the next two pillars. Inspection and Adaptation.
Continue to episode three:
The Road to PSM III is being updated to the 2020 edition of the Scrum Guide and new standards for PSM III assessment.
Join the Road 2 Mastery
