The book Introduction to Agile Methods by Sondra Ashmore and Kristin Runyan has the goal to provide an introduction to the wide landscape of Agile software development approaches. A very ambitious goal in my mind. From the start, you quickly see that the content has a strong “textbook” flavor and this review might have a certain bias as I have left university several decades ago and have already more than 10 years of familiarity with Agile software development.
The book is well-structured and provides a lot of valuable material about a wide range of Agile approaches, dealing even with methods that have a more limited following like Feature Driven Development or Crystal. The book is well written, even if I found it sometimes a little “dry” as it lacked the more “from the trenches” reports provided my other Agile authors that work as consultants. There is however in each chapter an interview with a recognized Agile expert who shares a personal perspective on the topic that has just been discussed.
The further reading sections are also well done. It is however difficult to make all the different Agile approaches coexist in the same structure as the authors decided to structure their book around software development phases. I had sometimes the feeling of jumping from one method to the other without many explanations or that the content about each method was too much scattered around the book. I also had the impression that the book was lacking nuances when comparing the ugly old Waterfall way and the new bright Agile.
If you are trying to find a book that will give you a general perspective on Agile software development, then Introduction to Agile Methods might be a good choice for the broad sources of its content. If you are already a seasoned software development professional, I would suggest associating it to more focused books like Essential Scrum, Succeeding with Agile or Agile Project Management.
Reference: “Introduction to Agile Methods”, Sondra Ashmore and Kristin Runyan, Addison-Wesley
Quotes
Central to this culture shift is the idea that the team succeeds or fails together. Within Agile, it is impossible for a tester to succeed but the developer to fail, or for the product owner to succeed but the Scrum master to fail. Either the team, the whole team, delivered working software at the end of the iteration, or they did not. If the iteration did not produce working software, it is up to the team to diagnose the problems and work to correct them, previously described as continuous improvement.
The lack of commitment can reveal itself in a number of ways – failing to complete the work is the most obvious and detrimental – but there are other manifestations as well. Not adhering to the meeting cadence within Agile by grooming, planning, tracking, and demonstrating, all described in Chapter 8, can lead to suboptimized work. It might be easy to become lazy about the daily stand-up meetings and write them off as unnecessary, but that is not in the best interest of the work, the team, or the Agile transformation. Being disciplined about participation and active engagement drives success.
We should always test our user stories to make sure they are delivering business value, and if they are not, they should be either removed from the backlog or deprioritized to ensure that higher-value features are worked on first.