Context of a Scrum Product Owner

The USS Constitution, launched in 1797, is possibly the oldest wooden ship still afloat. Over two hundred years of repairs, retrofits, and refurbishing has left only an estimated ten to fifteen percent of the original timber in place. I’ve read articles asking the interesting question of when the original ship becomes the pile of timber sitting on the ground and the remaining ship becomes something new. The same question might be asked of the human body, wherein most cells are replaced at various rates, but some brain and nervous system cells, and potentially some others in the heart, are never replaced. We would never suggest that a human isn’t that same person through his or her life, would we?

I was pondering this recently when considering the skills required of a Scrum Product Owner. The techniques and roles of Agile in general and Scrum in particular come with many very specific descriptions and definitions, but how important are those compared to the skills needed to carry out the same functions the way things were done or are done in the absence of Agile or Scrum techniques? That is, someone has to go talk to the customers, figure out what they need, work with the developers (and/or be a developer) to get the requirements implemented, get feedback and adapt to changing conditions, and provide a range of additional management support. When these activities are recast in a Scrum framework, how many of the skills carry over and how many are new? This is analogous to asking how much of the ship is the refurbished thing floating in the harbor and how much of the ship is the pile of timber sitting in the yard? Does the Scrum framework knowledge constitute ninety percent of the job, fifty percent, twenty percent, five percent, or possibly as little as one percent?

Let me ask the question this way. Would you rather work with an individual who knows all the Scrum buzzwords and can answer all the trivia questions but doesn’t have much experience working with customers, analyzing systems, and delivering code and support or would you rather work with someone who has quite a lot of experience working with customers, analyzing systems, and delivering code and support and needs to review the Scrum Product Owner’s handbook from time to time to ensure he or she is following every procedure and considering every option that body of knowledge provides? Moreover, do you believe that any conscientious practitioner would review the framework materials at intervals anyway, instead of relying solely on memory, and do you believe that most practitioners and teams follow every rule by the book to begin with?

Agile and Scrum are terrific tools that I endorse as much as anyone, but by themselves they are only so much of putting a working system together to meet a customer’s needs.  The bulk of the work is still about being able to break the problem down and build up a good solution.  That part never really changes.

Just something to think about.

This entry was posted in Tools and methods and tagged , , , . Bookmark the permalink.

Leave a Reply