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 the adoption of Agile, Scrum or Kanban and explain what you should do to improve your software development project, but this book is different.
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, 228 pages, IBSN 978-0989081214
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.
In creating a Thematic Release System, Fundamo was able to give the Product Owner something to fall back on. Items that did not conform to the release theme could easily be scheduled for a later release.