Suggested approach in gaining and maintaining consistency amongst Product Owner teams

Suggested approach in gaining and maintaining consistency amongst Product Owner teams

Executive Summary: Problem statement

The objective:

  • To have a uniform approach amongst each product stream by introducing a "Chief Product Owner" (CPO) role

This has the benefit of:

  • Allows seamless move of team members around as each stream should be a familiar environment to each of the dev teams
  • Easier to control from top and communicate to outside stakeholders if all streams look and feel the same, improving understanding, completeness and quality
  • More coordinated releases should improve value to stakeholders, particularly if stakeholders are common across streams

Suggested approach summary:

  • Communication and collaboration are at the heart of agile: Product Owners (POs) and Chief Product Owner (CPO) must be doing this too, both amongst themselves in programme and how the programme is presented to outside stakeholders
  • Focus on ensuring some key “binding” artefacts collaboratively created and maintained: In particular Vision/value, Release plans and Product Charter are all needed and regularly used.

Initial review (no more than two weeks)

  1. Short period to review key artefacts across streams (e.g. user stories and backlog) as well as the agile process across streams (e.g. how things are prioritised, and scrums are run). Some artefacts may be missing (usually the perceived infrequent ones such as vision, and value) but inconsistency between how user stories are documented is also common
  2. Establish if any products streams are more problematic than others and why. Keep this informal as the objective here is to identify pain points not to preach (goal is to improve not antagonise!)
  3. Getting scrum masters as well as POs involved here is important for transparency, and indeed it may be that different scrum masters may have differing views rather than the individual POs
  4. Also getting dev team members involved is important – agile should not be hierarchical. We need them to participate in all levels of this regardless where they are, and getting their guidance bottom up is a good way of encouraging this
  5. At the end of this initial review the vision and roadmap, project charter, release plan will be created/introspected, improved and agreed amongst all stakeholders. All of these should be then made visible

Vision and value

  1. Getting a single programme vision and strategy which individual products can inherit and expand is critical. This isn’t easy though: Vision can often be abstract for regulatory programmes and “just be compliant” is often cited as the reason for doing this – which is not very helpful to expand on! However other themes such as capital efficiency, improvements in reporting process, improving scope and timings, data sourcing and quality should also be quantified.
  2. Similarly, a single view how value is measured and established. Together with a cross product roadmap, that shows how value is maximised
  3. CPO should own this but will need to solicit and get input and agreement from everyone. Building this vision is best done collaboratively with key stakeholders, POs, scrum masters. Dev teams shouldn’t be excluded from this though!
  4. Each of the Product steams also own a vision that should go through similar introspection and be consistent with one another. It would be practical to define/review these at the same time as the overall vision since all POs should be familiar with one another’s visions

Release Planning

  1. Aim to get consistency and coordination for each of the programme's product release plans (and roadmaps from vision) by building up a top-down picture. As always, do collaboratively with POs, Scrum Masters, and key stakeholders (particularly when agreeing release strategy)
  2. Cover any cross-stream dependencies, and dependencies to common stakeholders.
  3. Try and an agreed strategy for releases consistent across the programme: Do we get these at same time across products, is small and regular the agreed approach, how do we maximise value, how do we increment per sprint to facilitate this?
  4. Once this is done get it visible!

Project Charter

  1. Introduce project charter or equivalent (if not already present) that is common to all product streams. Get all POs, Scrum masters, and selected devs (not all), in standup and collaboratively create.
  2. Should cover how key artefacts are created and how the agile process is followed. But: Use stickies within stand-ups rather than heavy documentations to keep things simple and visible
  3. Even if there is one present, it doesn’t hurt to quickly get all POs together to discuss, reflect and if necessary, improve.

Ongoing activity

  1. Ongoing communication is key. CPO needs to have stand ups with individual product POs regularly. At least once a week, and at critical periods, more. Treat this like a scum of scrums: What are the blockers, what needs to be escalated etc, etc.
  2. CPO can also attend product stream scums periodically, and ideally be involved in introspections. Many issues raised here are likely to be common after all. CPO shouldn’t interfere with PO’s and their scrums – they are still captain of their individual products!
  3. Many of the activities in initial review should be repeated, typically at the end of each release as part of a programme-level introspection. At end of (hopefully now more coordinated!) releases aim to have an introspection of quality of artefacts and process, charter, vision, value, roadmap and amend collaboratively as necessary
  4. CPO does have some programme level activities such as escalation of issues to stakeholders, management of common pain points (especially if a single stakeholder is making things difficult with multiple streams), resource/budget planning (such as moving resources and between product streams). This is consistent with their responsibility of maximising the value of the suite of products as a whole and should be covered with meetings and communication with senior stakeholders regularly.
? Deryck Brailsford
I have 15 years’ experience introducing agile into regulatory and data centric programmes. Please contact me on [email protected] or +44 7710 435227 if you have any questions raised by this article.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了