Agile Forest

This one is for Mhano. Book 2 of 11 for the PMI Agile PM certification syllabus – Agile Project Management with Scrum by Ken Schwarber, 2004.

Okay well firstly it is obviously about Scrum and doesn’t cover anything XP or ‘A’gile related. Given that it is getting a bit on in age I thought there would be more that I would disagree on but surprisingly little has changed over time.

If you want to know Scrum it is a good start, but really there isn’t a lot of depth to this book with a majority of the book focused on case studies. Ken admits that that is his focus at the start and he leaves the first chapter and first appendix as the process and general rules of Scrum. He wanted the rest of the book to be more about the ‘feel’ of Scrum but really it reads like a number of notable failure modes or Scrum Master correction tips. Whilst some of this information is useful it really is the tip of the iceberg and there is not enough coverage of other information to recommend this for anything past a novice level of information.

Comparing it to the two day Certified Scrum Master (CSM) course, it is probably the same coverage.

Ken openly discusses in the first chapter that Scrum is an empirical process control, meaning software development is hard and consequently the only process we can rely on is visibility, inspection and adaption and then goes on to explain how Scrum fulfills this. It is a valid value proposition and well explained.

The book then goes through the key Scrum roles and a number of other Scrum terms as you proceed through the case studies. As always my main beef is not directly related to this book, but at Scrum itself. I loathe the term Product Owner. I feel it is a poor reflection of a commercial world outside of small software development houses. Rarely do you have someone who is the Project Sponsor, Business Owner and Business Representative in this one role. Merging all three is confusing and not a reflection of standard governance and delegated levels of authority.

Similarly I hate the term Scrum Master, but I also hate what it has done to jumble up the meaning of Agile Coach. They are different, but similar and I don’t know if it is doing us justice having this role. More importantly I fear that the role of Scrum Master is counter-intuitive to the generation of a self empowered managing team.

Nattering on, I also hate the term ‘Product’, specifically when associated with the backlog. This primarily is because it limits the application of Scrum to anything to do with ‘Products’. You can apply Agile and Scrum through so many things other than software development and so the term product for me just doesn’t sit right. Call it a work backlog and be done with it.

Maybe I slept in the CSM class but I can’t remember the strong enforcement of scrums having to be 30 calendar days. I’ve always just used standard lengths of iterations to what suits the circumstances. 30 days seems a little prescriptive. Burn down charts have also advanced away from what is described in the book with Burn Downs generally representing hours and points being burnt inside of the iteration and the release burn done going upwards against scope.

Similar to my major gripe with the CSM course there is no coverage of the art of generating the backlog in the first place, it magically assumes a fairly burped one out. This is an art. It is not simple and for it never to be covered anywhere is just sad. There is a very small reference to doing this in one day…. yeah. I am dubious of the quality of a one day created backlog for a greenfields project. There is definitely something in Feature Driven Development’s domain modelling that is missing in this picture.

The rules at the back are a little outdated but for the most part have their heart in the right place.