The Dark Side of the Scrum Guide

and the road to PSMIII.

In my journey of radical openness in the online Scrum community to aid my study towards PSMIII, I’ve been overwhelmed by the discovery about how much I still don’t yet understand about the Scrum Guide.

I’ll start with a minor disclaimer in the hope to avoid a potential shit-storm and a flame-war from my fellow Scrum passionates: If you read it all-the-way through to the bottom, I’ll award you a special imaginary badge of respect.

Or.. feel free to scan and cherrypick whatever you can in the precious time and attention span you have.

I’ll be careful not to reveal anything about the assessment itself. So I tried not to include #spoilers, #cheating.

In this series, I wish to ramble about my frustrations and epiphanies during the PSM journey. I want to do this in the hope you will help me better my understanding and in return, I hope it helps you better yours.

My passion for Scrum is expressed through the evangelisation of it. It would not be fair to not be open about the concerns I had, lost, regained, and resolved.

I’ve been approaching Scrum Shu-Ha-Ri style, and most of it so far has involved me telling myself to shut-up and just-do-it. I understood that it wasn’t up to me to challenge any of it before I learned to actually master it.

I call myself a Scrum Master, and PSMIII may testify that I hold a distinguished level of Scrum Mastery, but that is not to say I master Scrum!

Seasoned Scrum Masters will agree that those who think they mastered it, likely haven’t.

The Hairy Shoe!

If I may so bold to summarise Shu-Ha-Ri:

“Shu, means to keep, protect, keep or maintain. It implies loyalty or persistence; the student should be working to copy the techniques without modifying or questioning them. The student simply inspects and applies.”

“Ha, means to detach and break free from these traditions. The student reflects on the meaning and purpose of everything learned and thus come to a deeper understanding of the art than pure repetitive practice can allow.

“Ri, means to go beyond or transcend. The student has become a practitioner and must think originally original thoughts about the art and test them against the reality of everyday life. The art truly becomes the practitioner’s own and to some extent his or her own creation. The student adapts.

I’ll start with an ‘epiphany’ that took me way too long to get. It still makes me feel silly.

It’s a guide!

Yeah duh, it’s called ‘the Scrum Guide’. I really did not consider the importance of the term ‘guide’ (shame on me).

You can’t do Scrum by-the-book. None of it is required and none of it should be enforced. But yeah, if they choose not to follow the instructions of the guide, yes, they are bound to get lost.

— Edit: Thanks Tanner Wortham for pointing out that the Scrum Guide does say on its cover: ‘The Rules of the Game’!

As a Scrum Master you don’t enforce the rules, you work to better everyone’s understanding of them.

There is no single universal way of practicing Scrum. Everyone practicing Scrum has created their own Scrum Bubble shaped by how they’ve followed the guide.

The guide is there to provide transparency. Once there is a shared understanding of it, the complexity in communication is reduced, and consequently, there will be less conflict and waste.

The Terminology Terror

As you can tell by my writing, I am not native English. At first Scrum’s terminology sounded a lot like Star Trek’s technobabble to me. I love technobabble. However, introducing all this new terminology into my vocabulary resulted in numerous conversations during which no-one understood what the hell I was talking about. Sometimes I didn’t even understand what the hell I was actually talking about.

I threw around words like ‘Technical Debt’, ‘Architecture Spikes’, ‘Increment’, ‘Empiricism’, ‘Self-organisation’, ‘Value’, ‘Velocity’, ‘Impediments’, etc.., thinking I knew what it meant. Boy… I had no idea what I was talking about.

How could I have possible been so stupid to assume that my conversational partners shared the same understanding of the terminology I used?

In my journey to better my understanding of Scrum, I’ve learned that transparency means I have to work on developing a shared understanding of all this technobabble. I learned the Scrum Guide is meant to guide me in this.

As a non-English native speaker, properly understanding the terminology was by far be the most challenging part. As a bonus to learning Scrum, I improved my English.

What follows next will be tough and chewy to work through. But hey, if you are following me in my tracks towards PSMIII it might be worth your time.

Here are some of the nuances I tripped over:

Framework, Methodology, Process, Techniques. I really had to study the differences, and I wish a lot more people practicing Scrum would.

Event, Meeting Scrum events aren’t meetings; oh wait no, they are, are they? Ah, people meet, but instead of sitting passively, inattentively around a table in a meeting room, it involves active hands-on collaboration in the workspace. Okay, but why does the Scrum Guide refer to the Sprint Planning as “Sprint Planning meeting”?! Why isn’t it simply calling it the Sprint Planning event? This baffles and slightly annoys me still.

Development I don’t think Scrum’s interpretation of the term ‘development’ is in line with the general non-Scrum audience’s interpretation of it. Scrum just refers to it as ‘complex work’ and may well include design, architecture, analysis, marketing and heck, even sales. If I talk to my colleagues and mention the term ‘development’, they think I talk about programming.

Done, “Done”, Ready, Shippable, Releasable Is there a difference between “Done” and “potentially releasable”? Is there a difference between “Shippable” and “Releasable”? Right, now I understand why it is so important to have a common ‘Definition of Done’!

Self-organizing This doesn’t equal self-management! So here’s a good one for you: Can a self-organizing team choose what it doesn’t want to self-organize?

Facilitate, Serve Should a Scrum Master serve a Development Team in areas where the Development Team could facilitate themselves? What if you switch ‘serve’ and ‘facilitate’, does that change the answer? My mind still freezes and switches to a blue screen.

Visible, Open, Transparent, Accessible This all meant the same and nothing to me; boy was I wrong. Something that is visible might not be transparent. That which is transparent might not be open. That which is open, may not be accessible to all.

Titles vs Roles and Multi-disciplinary vs Cross-functional. Could someone with a certain title have multiple roles? Is Scrum Master a title, role, or both? If Scrum recognizes no other titles for Development Team members, can other titles be recognized for Product Owner and Scrum Master? Hrrrnnggg. What happens when a Scrum Master contributes to ‘development’?

When is a Sprint Backlog created?

Aaah, don’t let these questions fool you! they are trick questions. This is perhaps the most tricky and chewy part. Enter at your own peril.

These are some quotes from the Scrum Guide (SG):

• “The Sprint Backlog is a forecast by the Development Team” — SG.
• “The Sprint Backlog is a plan” — SG.
• “The Sprint Backlog emerges during the Sprint” — SG.

Read carefully: ‘the’ sprint, not ‘a’ sprint; does this imply the Sprint Backlog should refer to its own ‘current’ Sprint, or can it already emerge for upcoming Sprints? Obviously, I thought the Sprint Backlog emerged during the current active Sprint, right….right?! But after passing PSMIII I am more unsure about this than ever.

• “This emergence occurs as the Development team works through the plan” — SG.
• “The work to be performed in the Sprint is planned at the Sprint Planning” — SG.

Can ‘working through the plan’ implies ‘working on work to be performed in the plan’? Bzioooing!

I’m sure I’ve lost you by now, as I have lost myself many times over. But if you made it this far than wow, a good sign you’ve got the right ‘level of nerd’ to Scrum seriously.

During the Sprint Planning “The Development Team works to forecast the functionality that will be developed during the Sprint”

So the Sprint Backlog may, or may not emerge during the Sprint Planning, depending on if there is work being performed on the Sprint plan.

When does the Sprint Planning take place?

Wow, it took me years to understand that this is actually not an easy question to answer at all.

Wait… I actually realized the problem isn’t about answering the question… the question itself is problematic.

Ok here we go down the rabbit hole again:

• “A new Sprint starts immediately after the conclusion of the previous Sprint” — SG

Sure, basic stuff. Now consider this in the section ‘Sprint Planning’ in the Scrum Guide:

“The Sprint Planning answers the following: What can be delivered in the Increment resulting from the upcoming Sprint” — SG

The Guide continues to refer to ‘the’ Sprint, until, in section “Topic Two” of the Sprint Planning:

“The Product Backlog items selected for this Sprint, plus a plan for delivering them is called the Sprint Backlog— SG

Note that ‘this’ is used, not ‘the’ nor ‘upcoming’!

The guide continues to refer to ‘the’ Sprint again.

Look, now I feel like I am on some ‘Da Vinci Code’ quest here. Does this imply “Part One” takes place before the end of a Sprint and Part Two takes place after the start of the new one?

Note how I used the words ‘before and after’, not ‘at’. Nothing in the Guide prevents “Topic Two” from being addressed days into the Sprint. Or perhaps Sprint Planning can be seen to be ‘continuous’ during the Sprint as long as no more time is spent on Sprint Planning than its time-box.

A little voice inside my head tells me: “Nyland! stop implying things! Just work with the team on how best to organize Sprint Planning.”

… help.

Fortunately, Scrum.org’s Glossary reveals the answer.

Sprint Planning: time-boxed event of 8 hours, or less, to start a Sprint. — Scrum Glossary

Inconsistent and outdated sources

There are numerous books and sources you will be referred to, to help you prepare for the assessments. Just know that they will be inconsistent at times and often contain outdated material. Realize that the Scrum Guide has received a fair number of updates and there is an overwhelming number of experts and reads that still preach and teach outdated stuff.

You have to go through the process of re-evaluating everything you learn from sources other than the guide, with the guide itself!

Ignorance is bliss

So, the greatest Scrum suffering I now experience is, that with all this knowledge I realize the enormity of the challenge of helping others towards developing a similar understanding.

I now have to be extremely careful in using Scrum’s terminology, as I know for sure that others will have different interpretations of it; and that the journey to creating true transparency (which involves getting everyone on the same page), will be even longer and difficult than getting myself on the same page with the Scrum Guide.

Product Ownership

I really do understand and recognize the tremendous powers of having a single person assigned as a Product Owner.

Naturally, this shouldn’t be a committee, because that would increase complexity and thus chaos; all this and more would result in a devaluation of the product.

Consider the downsides that when the Scrum Team, collectively being the (product) value creators, is not collectively the owner of the (product) value created. Give me a chance (please) and open-mindedly consider this for a second.

If only a single person of that team is considered to be the single ‘owner’ of the (product) value created, and it is explicitly expressed that product ownership includes responsibility for maximizing the value of the product; what effect could this have on the overall sense of collective ownership, and thus commitment?

Now after deep-diving into this subject: stating that the Product Owner is responsible for maximizing value, doesn’t imply the rest of the team isn’t. But I believe that not explicitly mentioning that the whole team is, results in the wrong assumptions to be applied by the far majority of Scrum practitioners.

There are just too many toxic Scrum implementations in which the Development team ends up serving the Product Owner instead of the product, or the users of the product. This shouldn’t be ignored.

This really does have a terrible effect on safety within organizations as well as on the reputation of Scrum. It is so clear that the number of bad, toxic Scrum implementations are far greater than healthy ones.

I understand why the Scrum guide embeds some ambiguity. It is a great means to promote its assessment practices and push its training, but for the love of Scrum, please be more transparent in the wording used in the guide to make it clear that the whole team is the owner and responsible for the value created, and that the Product Owner serves the team, not the other way around, or that they collectively serve each-other.

Setting expectations

Commitment, Forecasts, Projections, Estimates, Expected Work Remaining, Forward-looking decision making, Empiricism.

Use whatever language you will, and technically correct though you may be, not even rephrasing ‘commitment’ to ‘forecast’ will stop any of the above-mentioned terms from setting expectations and thus being treated as time-boxes and deadlines, putting unhealthy pressure on teams.

I greatly appreciate that the Scrum Guide mentions that

• In complex environments, what will happen is unknown.

I just dislike it being mentioned halfway through the guide. This should be its opening statement. It even deserves its own opening page.

I’ve already gone on way too long, yet I am not even close to reaching the bottom of my ‘PSM epiphany/frustration’ well.

Feel free to reach out, share your thoughts, throw your tomatoes, or help me improve my understanding of Scrum.

Thank you. Here is the special imaginary badge of respect I promised:

[Imagine your ‘special badge of respect’ here]

Nyland out.

Continue to episode 1 on the Road to PSM III: