How strongly do I recommend The Elements of Scrum?
6 / 10
Review of The Elements of Scrum
Who is this book good for? People who want an introduction to the background, goals, meetings, and deliverables of agile software development.
Who should NOT read this book? People who take things very literally and want to view agile as a strict methodology. You need to take everything in agile and this book with a grain of salt. As they say on the internet, your mileage may vary.
My main gripe with The Elements of Scrum is that the authors ignore the human element. For instance, they recommend four hour planning sessions for each week of development. That sounds like a nightmare that totally drains the team’s energy. In another example, they recommend never using velocity as a performance metric… then immediately use it as a performance metric themselves.
My secondary issue with this book is the framing of Product Owner as representing The Business. In practice, you need to exercise caution with who represents the business because we actually all do and if engineers are not included, you’re creating an opportunity for technical debt to grow to unmanageable levels.
Top Ideas in This Book
- All agile methodologies share an iterative approach
- Agile teams typically require 6 sprints to become proficient with new processes
- Making work visible helps teams increase predictability of delivery
- Agile teams struggle when they do not share the same definition of done
- With estimations, humans are bad at absolute sizing but good with relative sizing
All agile methodologies share an iterative approach
Agile methodologies have much in common, but most importantly they encourage us to take an iterative approach to software development.
At this point it should feel obvious that waterfall doesn’t work, but here we are still seeing waterfall projects in the real world.
Agile teams typically require 6 sprints to become proficient with new processes
The authors recommend starting with one week sprints to shorten the feedback loops and get more repetitions in faster. But you still need to exercise some patience and coach people through the transition.
Making work visible helps teams increase predictability of delivery
Executives want predictability and making work visible through kanban boards helps shine light on the work. This book doesn’t go into depth about kanban boards, so for that you should read Making Work Visible.
Agile teams struggle when they do not share the same definition of done
As a manager, hearing the word “done” is a red flag. I rarely see “done” used maliciously, but I often see it used to convey that the work is farther along than it actually is – usually in response to social pressure around delivery.
When you hear the word “done” you need to dig further and define the actual state of the code. Ex: in production, testable, etc.
With estimations, humans are bad at absolute sizing but good with relative sizing
This book covers various methods of estimation, mostly group estimation. But the big takeaway is to use relative sizing instead of absolute sizing. Intuitively the idea resonates with me that humans can predict relative cost but not absolute cost.
You may also enjoy
Fantastic description of using kanban boards to improve software delivery