Book Review: Beyond Agile

When the authors describe the purpose of Beyond Agile, they write “one of the constant criticisms of all management styles and fads is that they seldom come with real in-the-field case studies”. There are many books that deal with how organizations should adopt of Agile, Scrum or Kanban and explain what you should do to improve your software development project, but this book is different because it focuses on how continuous improvement should be associated to project management.

Beyond Agile has a short introduction that presents continuous improvement and includes a very interesting discussion about the importance of principles. The main content is however the real world stories of ten organizations that walked the path of continuous improvement, with or without success. They are grouped in three sections that present the transition toward a flow-based environment, illustrate some specifics hurdle and analyze some flow-based systems in operation.

All these stories provide insightful information about the issues faced when trying to implement continuous improvement practices. What I liked however the best in this book is its message that there are no tools or rules that can be blindly applied in every situation. It is a book that I recommend to every people involved in software development projects who believe that improvement will not happen if you are not able to think about it in your specific context.

Reference: Beyond Agile – Tales of Continuous Improvement, Maritza van den Heuvel, Joanne Ho & Jim Benson, Modus Cooperandi Press

Quotes

For software teams working to find a process that worked in their context, Kanban served as a call to action, and at the same time a signal about the state of the system. Agile techniques of the 1990s and 2000s did an excellent job of placing software teams in a position of being able to do this self-exploration at all. Prior to the coining of the term “Agile”, a number of the teams were at best managed in engineering-style planning exercises and at worst dealing with day-to-day whims of those that controlled their backlogs. Agile changed this context. XP and later Scrum packaged pre-existing but previously unconnected concepts like batching, better communications, faster delivery cycles, and some avenues for introspection.

Teams found themselves arbitrarily splitting work that was naturally larger than one week into multiple stories. Often, one or both of the smaller stories did not actually deliver business value in isolation. They were writing stories to fit the sprint, rather than writing the stories to achieve business value.

The Product Owner role is often poorly defined and leads to the downfall of many Agile projects. A large factor in Product Owner missteps is a large, undifferentiated backlog and stakeholder management. The Product Owner ends up being responsible for the whims of the customer, the demands of the team, and the backlog itself.