Why an Intermediate CSPO (Product Owner) course?

In this post I want to talk about why the Intermediate CSPO is important and how it is different.

First, our finding is that the Team is important. Any focus too much on one role, or one role in isolation, is potentially leading people astray.  In a Team, every role plays with every other role. (Yes, we might do some work in isolation, but always for the use or benefit of the Team. So, the isolation is only temporary, and not very meaningful.)

So, I like all Product Owners to start with the CSM (Certified ScrumMaster) course, and ideally to take this with the rest of the Team.

Then to play Scrum for some time.  So, the PO starts to have real questions from the real world.

Second, I think for almost all teams, the biggest impediment is that the PO is not good enough.

This is not because we don’t ask good people to play the PO role. Usually we do.  Sometimes excellent people.  It is because no one is a trained and experienced (eg, acting for 5 years) Product Owner.  For the first 10,000 hours, very good people appear weak because they lack training and coaching and experience.

So, I find that the best thing is to take POs with a CSM and some experience, or no CSM and a fair amount of experience, and send them to an Intermediate CSPO course.

The course actually covers many of the same topics; but from the point of view of a more experienced person.

For example, we review basics.  In this course, the review checks for real world understanding. And it is used to correct the mistakes that beginners in any sport always, always make.  The bad habits, we might say.  The Scrum-But that they have started to do.

Third, we try to build the aspiring Product Owners into stronger Product Owners.  I have just suggested my key point-of-view: having the aspiring PO become the Tom Brady (the Quarterback of the New England Patriots) of Product Owners is a journey that takes years.  So, when we say aspiring, we do not mean that they come to the course with no accomplishments, but rather whatever they have done, they aspire to be better.

We discuss many other topics as well.

Here are some key ideas that others often do not:

* minimizing work in progress
* maximizing learning
* ordering the product backlog to optimize BV delivered over some period of time
* focusing on the gold, platinum and diamonds, and ignoring the silver, copper and dirt (Pareto)
* sizzling steak and killing babies (the psychology of an earlier release)
* a brief intro to the BV Engineering framework (approach)
* no Technical Debt (it is a PO issue too!) (Well, zero is a very low number, but that’s the direction.)

« « An Intro to BV Engineering: the paper || Business Value Engineering framework » »