A deeper understanding on…

Empiricism: Transparency

Road to PSM III — Episode 2

What a word: “Empiricism”. To tell you the truth, 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, pretty much no one I work(ed) with knew what it meant. I did run into someone who’d payed attention in philosophy class. When I ask students and colleagues what they ‘think’ it means, I usually get responses like: ‘expansion’, ‘like building an empire’, ‘hierarchy’, ‘command and control’.

Source: Rome II Total War

Empiricism has nothing to do with the term ‘empire’. Empiricism stems from the latin ‘empricus’ (from Greek ‘empeirikos’) which can translate to ‘experienced’ and ‘skilled’. It doesn’t relate to ‘imperium’, 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. Scrum is the incremental approach to ‘process control’. Take note: ‘transparency, inspection and adaptation’ is not a process, but could hold the framework in which processes can be controlled within. Follow me? It is meant, according to the guide, to ‘optimise predictability’ and ‘control risk’.

This chewy stuff is to be taken seriously.


Yo dog, Let me create some transparency over the term ‘transparency’.

The most important statement in the Scrum Guide is casually mentioned in the section ‘Monitoring Progress Towards Goals’ :

“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”.

“forward looking decision making”

The section ‘Monitoring Sprint Progress’ explains how to monitor progress and that this is done by inspecting the Product Increment.

So let’s be clear about this: stop inspecting ‘artifacts’ such as backlogs, burn-downs, plans and trend graphs, if you aren’t first inspecting the progress made on the product itself (the Increment). 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 what not. 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 these may be used to come to a working Increment, but don’t allow these to set expectations.

In complex, changing environments (such as software development), please 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 and exceed. They say little or nothing about feasibility, level of quality and speed of delivery of the actual product.

Remember, with Scrum this holistic picture emerges and changes throughout, just like the product.

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.

The working product is the primary measure of progress.

A 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 organisation:

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 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 colours of the fabrics used in the production. The word soon spread through town.

When the Emperor receives his new attire, a charade is put up in order to ‘dress up’ the Emperor.

“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 ‘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 might see, until confronted 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 are stakeholders and the little innocent boy is the actual user.

“But this Increment doesn’t do anything at all!”

The little boy shouted out during the Sprint Review.

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, risk is not controlled, conflict occurs 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. Developers are ‘motivated’ to make something appear done within a given timeframe, rather than taking the time to actually make it right.

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

So how can you, as Scrum master best contribute to this fundamental pillar of Scrum?

  • Facilitate frequent, direct, interpersonal interactions. Remove ‘proxies’ if you can.
“ The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t.” — The Scrum Guide.
  • Make the Scrum Event worthwhile.
  • Pull people together instantly when possible (rather than ‘plan/schedule’ meetings or write emails). Make sure people walk up to each other or pick up the phone when they can. Avoid members writing spaghetti e-mails and communication through all sorts of digital administrative tools.
‘Spaghetti e-mail threads’
  • Make sure the events start on time, everyone is present and they are hands-on collaborating.
  • Facilitate frequent interactions between the development team and Product Owner and motivate members to be completely respectfully open and honest.
  • Inspect the Increment and the Backlogs frequently together with the team.
  • Continuously align and improve the Definitions of Done and practises that verify they are met (TDD, ATDD, CI).
  • Be open about mistakes, set the right example.
  • Enable the team so they are continuously reviewing input, both qualitative and quantitive, from actual users.
  • Workout the differences between ‘expectations’ and ‘results’.
  • Listen closely and inspect the effectiveness on communication.
Tip: keep a ‘captain’s log’; this will be the mirror you will hold up to them.

See if you can detect any ‘patterns’ like:

  • Johnny is always getting coffee when the Daily Scrum is about to start.
  • Jane is always looking at the floor when she talks.
  • Ron appears to be avoiding Tim.
  • Eric really hates phone calls and will let the phone ring without answering.
  • Anne doesn’t like to call for help. She’ll take a lot of time to figure something out herself, even when a team member could have helped her out.

Ask questions all the time, even the obvious ones:

  • “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 you/I/she/he/we miss anything?”
  • “Is this how it should be?”
  • “How are you doing?”
  • [add your own]

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.

Continuing this series, I will cover each role, 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:

I hope you enjoyed this article and that it helps you in your quest. Please share your techniques in dealing with the above. Please correct me if I have misstepped. Just drop them in the comments below, highlight the statements you found to be helpful, share them, or drop some notes below. Oh right, and don’t forget to clap! 👏 it truly means a lot to me if you do.

Join us on Slack!

We’ve, just now, created a Serious Scrum channel on Slack. You’re all invited. Feel free to reach out and connect with us on Slack to share your thoughts. If you are interested in publishing in Serious Scrum you can connect with us there to make it happen.

Thank you for taking your time to read seriously.

A Special thank you to Bill Bolte for volunteering to review this article!