Posted on by Duncs

Surviving Scaled Agile - Identify Stakeholders

This is the third in a series of posts going into more detail around my thoughts on remaining an effective practitioner in scaled Agile - Identify Stakeholders.

To get a wider context of this post, please refer to the original “Surviving Scaled Agile” post outlining the model.

One of the advantages I take from SAFe is the surfacing of all the stakeholders in a programme.

When I was part of an Agile team, there were people within the organisation who were having influence on my project but I was not aware of who they were.

SAFe turned the commonly referenced “Business” into names, faces & their roles & responsibilities (primarily as part of PI Planning). I could also start to understand their personal goals & motivations.

Tom Gilb shares this slide with content from Roxanne Miller which outlines a list of stakeholders typically found in an enterprise organisation:

Can you put a name to each of these roles in your organisation? Each of these has the potential to cause a dependency on your project which may hinder your progress.

Every requirement has a stakeholder. Projects (& programmes) typically fail because one or more stakeholder’s needs have not been met. Identifying the stakeholders gives you far greater chance of eliciting their requirements.

There’s 3 groups of stakeholders I’d to like to draw your attention to:

HIPPOs

HIPPO – Highest Paid Person’s Opinion

These are the folks who have made the decision to adopt SAFe & are outlining the Vision (see later) for your organisation to strive for.

If you’re part of an Agile team already, you may have a greater understanding of Agile & Scrum than your HIPPOs. Consequently, you have to educate your HIPPOs (see later)

Development Team Members

These are the people you’ll be working with for most of your time. You’ll be having some challenging & technical conversations with them to drive out dependencies. These conversations will ensure you’re continuing to deliver value across the teams.

Peripheral Stakeholders

These are those people you wouldn’t typically interact with as part of an Agile team. They have requirements that the delivered system needs to meet in order to be considered “shippable”.

SOx Controllers for financial projects, Risk Controllers & Governance Managers are examples of peripheral stakeholders.

I’ve found when you approach these stakeholders, asking for their needs & challenges, they are super eager to share as they are normally left until the end of the programme when it’s too late to implement their requirements.

RACI Matrix - essential tool

Some might consider the RACI matrix a swear word in an Agile context, but when you’re trying to coordinate & align more than 10 people, the RACI matrix becomes your best friend.

They outline who is Responsible & Accountable for what, who should be Consulted on decisions & who should be Informed.

On the back of the RACI matrix, a Work Product log is typically created which outlines who is delivering what work item.

In my opinion, these 2 tools are essential to support learning of the Scaled Agile Framework as it clearly defines boundaries of who is doing what. In a low-trust organisation, this discussion can cause a lot of churn & waste. The RACI removes that discussion.

What next?