Scaling the PO team

Second session was planned to be another session with Alistair Cockburn however, he choose to ignore the official session title and instead he conducted an interactive activity demonstrating the power of iterative development and effectiveness of an adaptive process.

after that Ive joined a session focusing on the role of the PO in a scrum process and how to scale this position without damaging the entire process.

The role of the PO in a scrum team is to represent the client. the PO is responsible of maximizing the ROI, i.e. he’s the one responsible for generating $$$. Specifically the PO is in charge of grooming the product backlog, which includes among other, writing user stories, prioritizing them and keeping track on what is getting build. The important thing to remember is that this is an active role, stories are not invented from thin air, they are discovered by talking with users, customers and sometime even the developers. A good PO will actively manage the backlog, he will keep priorities straight, refine stories as new knowledge is gained, remove less important stories and add new ones.

The key point of being a PO which is sometimes missed is that the PO should consider himself as part of the team. When a PO works in disconnection from the team, things will usually not go smoothly optimal. For example while in the Scrum “rule book” the PO approves stories during the demo at the end of the sprint, effective PO’s do not wait for it. they actively review and approve progress during the sprint work. after all why wait?

Scaling the PO

But sometime one person is not enough to effectively cover all the responsibilities of the PO role. and the big question is how to scale that role. Like anything else there is not a single answer on how to correctly scale the PO role, each method has its own strengths and its own risks. the key for success like anything else in life is to always manage the risks and be on the lookout when things are not going as they should.

One way of scaling the Po is to divide the by area of responsibility. i.e. one person (or more will work closely with the customer) and one (or more) will work closely with the team. Another option is to split the work more naturally according to the product technical components. but no matter how the work is split its crucial to first achieve good communications channels between the people functioning as PO’s. Normally a PO team will much higher level of cooperation than other teams to succeed.

another tip for scaling the PO role is to adhere to agile values, i.e. always inspect how the team of PO function and to improve. It is also possible to use a modified scrum process in order to manage the work inside the PO’s team.

When not to Scale

but the most important tip of this session was when to chose not to scale. Sometime organizations are scaling the PO not because they actually need to, but because there's an underlying dysfunction which was not recognized. for example I've seen a PO which spent so much time in customer relations, that he didn’t have time to help the development team. naturally the team complained, and suggested to add more personal to the PO. Only after sitting with the PO and raising the team issues, did we realize that the PO did have time but he didn’t fully understands what was required of him.

So before scaling, take a good look, maybe scaling i not the answer. maybe just maybe there’s a better alternative.

Posted in: Events,Scrum,Team System