Do you have a CRACK PO? (and a book review)

 

(If the title of my article for this week has you confused gentle reader, fret not - I'm just merging two distinct topics into a single post)

In 2003, Barry Boehm and Richard Turner coined the acronym C.R.A.C.K. (Collaborative, Representative, Accountable, Committed, Knowledgeable) to cover key characteristics of an effective Product Owner (PO). Unfortunately, some POs leave us with the perception that they might have been smoking crack!

Having worked with some POs who lack one or more of these attributes, I recently had an epiphany. I have always felt that there is no single delivery role which is the most critical, but my exposure to ineffective product management has convinced me that the PO is the hardest role to successfully fill.

Good agile leads (a.k.a. Scrum Masters) might be worth their weight in gold, but they are out there. If you aren't getting good ones the cause is not likely a lack of supply but rather blockers within your own organization (e.g. toxic culture, poor compensation) which are preventing you from attracting them, and in a pinch, contracting might be the way to go. Development team members are also valuable, but talent across most skill areas is available for the right price and with the right culture in place.

The challenge with the PO role is that not only do you need someone who has deep business process knowledge regarding the product they are supporting, but they also need to have well established relationships with key stakeholders who will influence product direction. While it is difficult to satisfy the first requirement, especially in those organizations where knowledge exists in silos, it is much more difficult to meet the second requirement. Simply parachuting in someone from the outside won't work regardless of how knowledgeable they might be about the domain.

So if you are lucky enough to have an effective PO, retain them at all costs.

On a different note, Eric Uyttewaal, asked whether I would be interested in reviewing his latest book - Forecasting Programs - Best Practices for Scheduling Real-World Programs.

I don't normally write reviews on my blog, but I have deep respect for Eric's knowledge of MS Project and his ability to make it able to stand on its head. Eric has written multiple books on effectively using the tool and given the dearth of guidance on using scheduling tools like MS Project to manage programs, I felt this was a worthwhile exception.

I was pleasantly surprised to see that the book goes beyond MS Project to providing general scheduling guidance for managing programs. While the examples and step-by-step procedures do focus on MS Project, they can be adapted for use with other scheduling tools.

Eric has done a good job of covering the analysis which a program scheduler might go through in deciding how to organizing their schedule, and I especially liked his Project Ideal and Constraint Matrix (PIC-Matrix) which can help a scheduler in deciding which scheduling approach to use given the primary expected benefit and primary constraint for a given program.

While there is guidance for scheduling projects following an adaptive lifecycle, Eric has taken a very narrow view of agile delivery. Sprint-based delivery might be the most commonly followed approach but it is not the only one. His compromise to find a happy scheduling medium by defining the content of a full backlog in detail so that work items can be assigned to all sprints and estimating all backlog items is not suitable for projects where requirements are expected to evolve dynamically. His approach to converting story points to effort hours is also concerning as there usually isn't a linear relationship between the two.

Eric's company develops and sells a number of add-on products to MS Project. While a certain amount of self-promotion is to be expected, I did find that the number of references to these products was more than I would have liked. In fairness, Eric does reference other third-party tools but generally positions his tools favorably relative to these competing products

I felt the book's greatest strength is the number of options which Eric has provided for scheduling programs which makes this book useful regardless of the maturity level of the practitioner.