by Antony Melvin – Architecture & Planning Practice Lead
In developing an Agile Scrum framework for a Professional Services Organisation (PSO), one of the key challenges is the role of the Product Owner (PO). In a traditional scrum setup, the PO will work as one of the three amigos. They will prioritise the work backlog and own ceremonies like the sprint review.
If a company has an Embedded Services Organisation (ESO) – an in-house team – or a Product team, the role of PO tends to work in a more traditional sense. I’ll leave the nuances for a different time, but for a PSO the PO role is trickier to define.
At this point, I’ll offer the disclaimer that I’m a Scrum Alliance-certified Product Owner.
How does it work?
A PSO basically operates by selling its expertise to client companies, either by embedding consultants or delivering projects. In this type of relationship, the client company logically should identify someone to act as the PO. The PO is invested in choosing the priority of the work backlog and ensuring that the right things are worked. They ensure this is done in the right order. If the company wants the project to change tack the client PO should make and justify that decision.
Whilst it is logical for the client to offer up a PO, it’s more common for a client to offer a Project Manager (PM).
Projects are bought for an amount of money, to be delivered over a certain period, to deliver a defined scope. This is textbook PM territory. Especially if a client company isn’t wedded to Agile practices.
It would take the word count of a thick book to properly explore the challenges this offers to a PSO working in Agile. The main one I’d like to explore in this blog is how to proxy the PO role so that PMs have the tools they need for their internal stakeholders. They also need to maintain a bridge into the project itself.
So, I’m going to be a bit simplistic here for brevities sake.
PMs tend to see a Project Proposal or a Statement of Work – even one at the start of an Agile project – as a long ‘To Do’ list that needs ticks rather than a backlog that needs curating. PMs have tools like Risk registers, RAID logs, status reports and so on. Those from the PRINCE 2 route, will know all about the importance of managing stage boundaries. They will also know the documentation required for changing course. In overly simplistic terms, PMs tend to work on a project by identifying and clarifying what is going to plan – and what isn’t going to plan. There is a PRINCE 2 agile pathway but the way a Scrum Agile project zigzags around rarely suits a PMs toolset.
Even if a PM is in place with good agile experience, it is still challenging for a PM to be a proxy PO. If a project delivers A, B & C over 3 months – but a month into the project this becomes delivering A & D over 4 months, there are tricky hurdles to clear. If there was a PO in place, they would then own these changes and sell them back to the stakeholders. They act as a proxy stakeholder.
But a PM rarely has that authority.
A client PM is often allocated to a project without instruction that they can change the project scope, budget, or timelines. And, dropping some commentary into a weekly status report is not going to be enough.
A client PM needs an airgap.
The PM needs someone to own any changes and delivers a change request each time there is a significant project change. The PM can then comfortably report back each change order and the impact this has on deliverables and timelines. Including wrapper documentation to justify the delta. This gives the client stakeholders the right information to make decisions. It also avoids the PM being on the hook for the implications.
One way to create this airgap would be to introduce a PO to work with the PM in the client organisation. Or pay the PSO for this additional member of the team. Unfortunately, the additional cost involved may make the project less tenable and undermine the client PM. A client may ask why should they employ a PM and a PO with overlapping responsibilities for a single project?
The way synvert TCM (formerly Crimson Macaw) squared this circle, without additional client cost was by elevating the Scrum Master (SM) role into a Scrum Master Plus. This Plus role helps the project team in all the ways that a Scrum Master should. It also helps the client PM with regular check-ins and gives them a series of PM artefacts like weekly status reports, RAID logs and change requests.
Conclusion
This enhanced role at synvert TCM is called a Delivery Lead. It means that our Scrum Masters work directly with client PMs to deliver projects. It generates the benefits of an Agile delivery process as well as supporting the client PM. Importantly it does this without requiring the cost of an explicit PO.
Want to know more about how we use Agile Scrum principles at synvert TCM? Read our other blogs here.
