Sometimes, a framework does not provide all of the answers needed to apply concepts in the real world. This is to be expected as a framework is a framework! At the SAFe Summit in Berlin last month, Scaled Agile Chief Methologist Andrew Sales defined a framework as “a basic structure underlying a system or concept… intended to serve as a guide of something that expands the structure into something useful.”
The Scaled Agile Framework uses a combination of Business Owners, Product Management and System Architects to shape and prioritise the ART backlog. Often, we can apply SAFe “out of the box” so to speak and it all goes swimmingly well. However, it is not always that simple, which is hardly surprising given organisational contexts can vary widely.
While SAFe’s requirements hierarchy and associated content authority roles make life simpler for the teams on the Agile Release Train, this model doesn’t always cater for ARTs with especially broad stakeholder groups. This can result in important voices being missed when scope and prioritisation decisions are being made. Our solution for this is a Product Advisory Group, also known as a Product Council or a Product Management Group.
There are four main scenarios in which we have applied this approach.
When identifying Business Owners, we start by identifying the executives who have a fiduciary responsibility for the outcomes being delivered by the Agile Release Train (ART). Often, these folks were program sponsors (or equivalent) in your pre-SAFe world.
Usually, the challenge is to get the right level of seniority in the organisation to champion the ART(s) and navigate the politics. However, sometimes, the opposite happens—the C-Suite volunteers to be the ART’s Business Owners and follow through by performing the role! While this is exciting, it can create a problem whereby the people who would normally be the Business Owners have no role in defining scope or priorities. In this scenario, creating a Product Advisory function that advises the Business Owners provides a way for all the right voices to contribute.
SAFe Product Managers often have a range of stakeholders who are effectively their peers. These folks likely represent specific customer segments or business functions that use the product(s) being delivered by the ART. SAFe doesn’t provide any specific guidance as to how Product Management should approach creating an inclusive environment for a wide and varied stakeholder group. Some Product Managers have a gift for stakeholder management and barely bat an eyelid. Others will find the formation of a Product Advisory function an effective construct to ensure these critical stakeholders get a voice. We think of this as an example of moving authority for decisions closer to the information.
When an Epic Owner, as a content authority, is not a Business Owner, Product/Solution Manager or System/Solution Architect, they can find themselves without a voice when “their” epic is being prioritised and progressed by the Agile Release Train. Ideally, Product Management will recognise this important stakeholder and invite them to participate, but this is not always the case. Including these epic owners as part of a Product Advisory Group formalises their role on the ART and ensures their voice is heard.
In some enterprises, there are technology leaders who don’t fall into any of the above categories but are responsible for the operational performance of the systems being enhanced and maintained by the ART. Unless they own an epic (or feature), there is no simple SAFe answer as to how these people fit with the ART. However, given the role of the Product Advisory Group in shaping and prioritising the ART backlog, the managers are a logical inclusion.
The ART’s Product Manager(s) and System Architect(s) won't always know everything about every potential feature. Product Advisory can play a valuable role when identifying features from epics by being active contributors to impact mapping and/or feature-storming workshops. Their broad business knowledge will assist with identifying the people and roles that should be represented in feature definition sessions.
When it comes to Feature Definition (aka Feature Disco), Product Management may identify that the benefits of a specific feature would be better represented by another ART stakeholder from Product Advisory. This often results in the Product Managers empowering a better-informed Product Advisor to own feature definition and acceptance. We tend to refer to this individual as the Feature Owner for that particular feature.
Some potential Product Advisors will be initially identified through feature definition workshops. When this happens, make sure Product Management takes the action to confirm if this person should join the Product Advisory Group and, if so, invite them to the relevant upcoming ART events.
While SAFe suggests that Product Management and System Architects prioritise features for the ART, we believe the best prioritisation involves the ART’s stakeholders. Whenever we have an ART with a Product Advisory group, we have them join Product Management and the System Architect(s) for ART backlog prioritisation. We find this provides Product and Architecture with a more holistic view of organisational priorities and results in great alignment across stakeholders.
In most cases, the Product Advisors have a deeper understanding of the feature benefit hypothesis than the Business Owners; therefore, they are often empowered to prioritise the ART backlog. Sometimes, the Business Owners will still want to be included in feature WSJF. However, this will only work when the total number of people involved is less than ten.
Product Advisors can get involved in PI Planning in a multitude of ways.
The System Demo is the opportunity to see how the teams are progressing with their PI Objectives. Product Advisors must attend and provide feedback. In our experience, Product Advisors love System Demos because they can see all the great outcomes the ART is enabling.
Inspect and Adapt is the Product Advisory group’s opportunity to see the outcomes of the PI, celebrate the ART’s success and contribute to the relentless improvement of the ART.
Product Advisors are an extension of the Product Management function in SAFe. They interact with Product Managers regularly as part of the ARTs cadenced-based events. Some Product Managers have a fortnightly sync with their Product Advisors following the System Demo. This provides time and space to digest the ART progress and discuss priorities for future PIs. The Product Advisory Sync can also be used to support the rolling prioritisation of Features.
One of our principles when launching an ART is that everyone has a home on day one. A Product Advisory Group is one way to ease the transition to the new way of working. Sometimes, it can feel a little odd, but it does work. As a virtual team, a Product Advisory group can broaden the ART’s reach into and across the organisation, help the organisation align on priorities and strengthen the connection between the ART and all its stakeholders. As is the case with all Product Management-related roles in SAFe, it is a critical success factor that the Product Advisors are empowered by the part(s) of the organisation they represent.
44 Mary Street, Richmond
VIC 3121 Australia
Australia: 1300 723 369
Outside Australia: +61 3 8592 1994