Scrum Book

What Hacker News says

1. kitsune_Aug 2022
   If you want to fix these issues in the context of Scrum I suggest J. Coplien's "A Scrum Book". Or you can just read the patterns here: https://sites.google.com/a/scrumplop.org/published-patterns/... - The book is a slightly reworked reprint of the pattern work done by that group of people.

   It follows the pattern work by Christopher Alexander [1]. The patterns form a cohesive interlinked language that provides context for each pattern.

   Here is what it says about the Daily Scrum: https://sites.google.com/a/scrumplop.org/published-patterns/...

   There some useful patterns that might even make sense outside of Scrum on there. Anyways, framing approaches and solutions in a cohesive pattern language is intriguing in its own right in my opinion.

   [1] https://en.wikipedia.org/wiki/Christopher_Alexander

   Show morethread
2. kitsune_Mar 2021
   If you want to grok Scrum you should read James Coplien's A Scrum Book or his related work on patterns.

   Also, the bean counters have won. In most enterprise companies "Agile" is nothing more than top down micromanagement.

   thread
3. 29athrowawayJun 2020
   Very few people care to read the official Scrum documentation. It is not a long read. Some posts on HN have more words than the Scrum Book.

   As a result of not reading the documentation, not many understand what Scrum is and what they're criticizing. I have been in that situation myself at some point. One day, I found myself so frustrated that I read the Scrum book over and over again until I could complete the certification assessment with passing score, just to understand if Scrum was to blame for the problems I perceived.

   What I learned in the process was that scrum does not recognize the role of a project manager and it does not make distinctions between development team members. The development team is defined as self-organizing and empowered to make decisions to a very reasonable extent.

   The problems described here often start when some the self-organization and autonomy of the development team is taken away. This can take many forms, like adding roles like project managers or by redefining existing roles, such as making the scrum master role absorb responsibilities from the development team.

   Those adjustments are suboptimal and almost inevitably result in an imbalance of power between product and engineering, and that's a really bad idea that will often result in engineering disasters.

   Some companies create engineering holidays such as hackathons, where engineers can take the time to work on neglected aspects of projects. But then, in many companies, product people have started to intervene those events as well, perpetuating engineering frustration.

   Show morethread
4. richlissJun 2020
   99% of teams are doing Scrum wrong most likely.

   Scrum has been ruined by many different groups (large consultancies, certification bodies, the misinformed, bloggers etc.) and there is a movement called the Scrum Pattens movement trying to fix the damage and to make it more explicit. If you want to do Scrum properly read “A Scrum Book”.

   Scrum is not a process it’s process design framework- you start with Scrum as a framework to then, through inspecting and adapting, add what works for that team (and no other team) and discard/replace what doesn’t through experiments and retrospectives.

   Does that sound like it’s liberating for engineers or something that ruins them?

   Note: Kanban is also not a process but a system for continuous improvement. 99% of teams doing that are doing it wrong too most likely.

   Show morethread
5. utternerdFeb 2015
   This was an absolutely fascinating read and has given me a fundamental understanding of human cognition. This helped with other books as well, such as the "Lean Start-up" and "Willpower: Why we do what we do." It even helped me further understand some concepts behind Jeff Sutherland's Scrum book. Highly recommended.
   thread
6. KerrickNov 2025
   > as a starting point

   That's the thing... Agile processes do position themselves as a starting point, and suggest that once the team understands it by living it (but not sooner!) they might adapt it and customize it.

   From The Art of Agile Development, 2nd Edition by James Shore et al. (the most recent eXtreme Programming book, if you will):

   > As a result, although it’s tempting to customize your Agile method from the beginning, it’s best to start with a by-the-book approach. The practices that are the least familiar are the ones that are most tempting to cut, but they’re the ones you need most, if you’re really going to be Agile. They’re the ones that involve the biggest change in philosophy.

   > Mastering the art of Agile development requires real-world experience using a specific, well-defined Agile method. Start with a by-the-book approach. Put it into practice—the whole thing—and spend several months refining your usage and understanding why it works. Then customize. Choose one of the rough edges, make an educated guess about what happens, and repeat.

   From The Scrum Book by Jeff Sutherland et al.:

   > It’s important to understand the rules, and it’s even useful to follow them most of the time. But reading the rulebook of chess won’t make you a great chess player. After learning the rules, the player then learns about common strategies for the game; the player may also learn basic techniques at this level. Next is learning how to combine strategies you learn from others while maybe adding some of your own. Ultimately, one can transcend any formalism and proceed from the cues one receives from one’s center, from one’s instinct. [...]

   > Some day, long from now, you may even outgrow these patterns as you evolve them and define your own. There are no points for doing Scrum, and these patterns are the gate through which a highly driven team passes on the road to the top echelons of performance.

   Show morethread