Thoughts on "Essential Scrum" by Kenneth S. Rubin
Late last week I finished reading "Essential Scrum: A Practical Guide to the Most Popular Agile Process" by Kenneth S. Rubin. I really enjoyed reading this book. The author's writing style makes it an enjoyable read and it's full of thought provoking discussion on Scrum.
I started my professional career in the software development industry in the late 1990s. My recollection is waterfall and "big design up front" were generally the methods of choice for the development process back then. I can recall frequent use of large and highly detailed Gantt charts spanning months.
Later, in the early-to-mid 2000s, I owned a small business making audio software for Windows. This was truly a small business as I was the sole owner and sole employee. With this company, I had some initial success making basic-to-intermediate level audio recording, editing and mixing software products.
Live and learn. Sometimes learning firsthand, through challenging experiences, is the best way to learn. Shortly after that experience, I happened to start learning about Agile. I've found myself generally agreeing with Agile principles and have continually attempted to embrace them.
While reading "Essential Scrum", I found myself largely agreeing with the author and appreciating his insights. I also found myself frequently reflecting on past professional Agile (and non-Agile) experiences. This book did a good job of not only defining the roles and practices in Scrum, but also explained its potential effectiveness.
- Chapter 7 (Estimation and Velocity) - Particularly the thoughts on estimating relative effort versus a fixed number of hours.
- Chapter 8 (Technical Debt) - The author's depiction and effects of technical debt are spot on.
- Chapter 10 (ScrumMaster) - As someone who has professional experience in this role, I really appreciated this chapter.
- Chapter 11 (Development Team) - Discussion on the importance of cross-functionally diverse and long lived dev teams.
- Chapter 14 (Scrum Planning Principles) - Really agreed with the analogy of up-front planning in this chapter.
One thing I still wrestle with a bit, concerning Agile and Scrum, are longer term customer estimates. How do you expect the customer to accept an unknown delivery date for a fully functional product?
I suppose it's possible that there are software projects in the industry where delivering partial or phased functionality is acceptable, but personally, thinking of past projects I've worked on, that really hasn't been the case.
I was hoping Chapter 18, titled "Release Planning (Longer-Term Planning)", would address this, but I can't say I found definitive answers or strategies. This chapter seemed to mostly acknowledge and accept the high degree of uncertainty in software development and long-term estimation. A quote from Chapter 18: "We can fix both the date and the budget, but the scope must be flexible".
Very soon I'll be starting on "Agile Estimating and Planning" by Mike Cohn. I'm hoping I'll get some additional insight into long-term planning strategies from it.
For the most part, I find myself largely agreeing with the ideas put forth in "Essential Scrum", but at times find myself pondering theory versus real-world scenarios.
One example is the idea of "working at a sustainable pace" (Chapter 11). I fully agree that you need to avoid burnout, especially at the team level. It's unhealthy, no fun and can lead to other problems, with high costs, in the long run.
However, when I contemplate the development process behind truly revolutionary products in the industry (e.g. Facebook, the iPhone, Google's search engine, Compaq Portable, etc), I'm not sure leaders of these efforts would site "sustainable pace" as a top reason for success. For better or worse, I think the term "sacrifice" would come up much more frequently.
I'd love to be proven wrong on this. And I of course acknowledge the definition of "sustainable pace" for one team can be very different from another. There are various levels of performance in any industry.
Contemplating these possible real-world versus theoretical differences are not meant to be any sort of heavy criticism of this book or the Agile processes, more just passing thoughts I had here and there while digesting the information in this book.
Bottom line, in my opinion, "Essential Scrum" does a really good job at explaining the Scrum process and it's effectiveness. I found it to be an enjoyable, informative and enlightening read.