My review

Ah, the infamous Scrum Guide. Whether you love it or hate it, it shapes much of today’s business world, especially in software development. While other fields like marketing, legal, and HR haven’t fully embraced it yet, the trend is clearly moving in that direction.

I picked up this expanded version of the Scrum Guide as part of my role as Scrum Master at Alloprof. I expected a strict rulebook on how to “do Scrum,” but was surprised to find how open-ended the guide actually is. As the authors point out, it is intentionally incomplete. Each team is meant to fill in the blanks for themselves. No two teams are the same, and no implementation of Scrum will be identical.

The guide does a good job of outlining every role and their accountabilities:

Scrum Team
- Product Owner
- Scrum Master
- Developers
Stakeholders

One thing I learned that caught me off guard: usually only developers participate in the daily scrum. For as long as I’ve been involved in Scrum, the Scrum Master was always present at these meetings. I assumed that was standard. This made me rethink my approach—maybe I should step back and let developers take more ownership, for example by having them share their screen of the current status board instead of me doing it.

I also discovered that much of the Scrum framework is rooted in a 1986 article called The New New Development Game. I’ve already picked up this article and plan to review it soon.

If you’re not involved in a Scrum framework, I wouldn’t recommend reading this. Even if you are, it’s very high-level and you might not come away with much that’s actionable. Still, you’d be remiss to claim you’ve never read the guide. For better or worse, it’s the bible of many modern business practices. It doesn’t really make sense to give it a rating—you probably know better than anyone if it’s worth your time.

As for me, as a Scrum Master, I’m glad I read it. The basics matter. You can’t be good at anything without them.

Félix rating:
🤷🏻‍♂️

⭐ Star Quotes

(p. 6) Managers, if they are part of the landscape, do not tell the Scrum Team what to do or decide which Scrum Team member needs to be taken aside to fix issues, directly or indirectly. If managers exist it’s generally better if they demonstrate leadership.
(p. 7) ⭐ People are not resources.
(p. 8) Without Adaptation, Transparency and Inspection are meaningless.
(p. 8) ⭐ As Sprints are short, any failures should be small and quick, and risk is identified and managed through fast and open feedback. Perhaps, the only real failure is the lack of learning.
(p. 9) Act with clarity on what needs to be done, why, and by whom.
(p. 10) People consume products (including services), not projects.
(p. 11) Discovery can help avoid building the wrong thing, but it can be overdone, and, in the end, the result feedback matters the most.
(p. 11) Leadership is the ability to influence, guide, and inspire a group of people to achieve a common goal while avoiding demotivation. [Emphasis mine]
(p. 12) A Scrum adoption has direction but not a predefined destination.
(p. 14) Inspection and Adaptation require a climate that anticipates and tolerates mistakes. It is essential to Focus criticism on ideas rather than individuals.
(p. 14) ⭐ For a successful Scrum adoption, it’s crucial to have regular intentional interactions between stakeholders (including but not limited to customers and users) and the Scrum Team.
(p. 19) The Scrum Master [, among other things,] ensures the Scrum Team has a suitable definition of output done.
(p. 20) Stop putting items in progress ; start finishing items.
(p. 23) ⭐ A smaller Product Backlog often provides more Transparency.
(p. 28) [In the Daily Scrum,] usually, only the product developers participate.
(p. 28) It’s always important to consider Stakeholders and what they value, including inanimate, non-human stakeholders such as the law.

(Read 122) Scrum Guide Expansion Pack

My review

Félix rating:🤷🏻‍♂️

⭐ Star Quotes

Félix rating:
🤷🏻‍♂️