How to be a good Agile Stakeholder

The Stakeholder Role

Stakeholders ultimately aim to deliver value to the end users and customers of the organisation, as well as serving complementary concerns, such as staff sustainability and happiness, legal obligations, and organisational effectiveness and profitability.

In trying to serve these aims they will frequently request work from Agile Development teams via the intermediary of the Product Owner, who constructs a single prioritised backlog for his or her team.

Coöperation over Competition

Stakeholders may be viewed as competing with each other for the development team's finite capacity. But a better way to view their role is in coöperating with other stakeholders to deliver maximum value (on balance) per time period, be it a sprint, a quarter, or a release.

Good Agile Stakeholders work with the Product Owner to clarify their needs, which then get queued up in the form of a single backlog.

Key points

1. Participate in collaborative planning and prioritising exercises — especially Discovery sessions — with other stakeholders with the aim of educating about your area, while understanding how it fits into the big picture.
2. Learn about the Agile approach to development: watch (and periodically re-watch) Henrik Kniberg's excellent Product Ownership in a Nutshell [15 minutes]
3. Attend workshops and sprint reviews (product demos) to help plan and inspect the output from the team
4. Help break down large pieces of work into smaller bits
5. Respect the prioritisation process

What about when I need something done now?

Agile teams typically maintain an Express or Expedite lane to allow for emergency work. As a stakeholder you may request truly urgent work via this mechanism, but do not abuse it! 

Although emergency services vehicles can travel fast through traffic, everyone else has to slow down. In the same way, use of the express lane gets the expedited work done faster, but it slows down all other work. Use sparingly.

Lessons on Product Ownership

I interviewed my wife, Andi Herman, who acts as Product Owner for our start-up, youpatch.com, on the big lessons she has learned in learning about how to be an (awesome) product owner.

Understanding the Product Owner role is helpful for stakeholders, who get most of their work done via the Product Owner.

Here's the summary:

1. Shared Understanding: Take the time to develop absolutely clarity of understanding between PO and the team around what is meant by backlog items. Learn each other's language. 
• Why? Because ambiguity leads to wild goose chases and waste.
• Examples, sketches, screenshots, etc. are helpful here.
• Invest the time to express yourself clearly and to validate understanding through discussion
• This is a great reason for the team to write the stories to demonstrate their understanding and the stakeholders to read them
2. Steer clear of micro-management: Understand that although you might envisage one way to accomplish a task, but don't try to enforce that on the development team. They may have better ways. Learn to trust the competence of the team.
• Stakeholders own the Why? of backlog items
• The PO and team collaborate on the What?
• The team owns the How?
3. Prioritisation: Understand that things need to happen in a certain order
• The PO balances business value (ideally cost of delay) with estimated duration when prioritising the product backlog
• The team may somewhat re-order by adding in considerations of risk, learning, and dependencies
• E.g. You can't put the roof on a house before the walls (dependency)

Conclusion

Agile delivery offers a great deal to stakeholders: faster feedback, better quality, and the ability to change course in the light of learning, new ideas, or changing external conditions. But it does demand a shift from giving orders to greater interaction and collaboration, and for most people it will be a journey of learning ... but one that can be professionally and personally extremely rewarding.