Should 'stakeholder' and 'leader' be accountabilities in Scrum, like Scrum Master, Product Owner, and Developers?
Should 'stakeholder' and 'leader' be accountabilities in Scrum, like Scrum Master, Product Owner, and Developers?
No team is an island. It's easier for a team to succeed with the support of stakeholders. There are four main reasons:
- Distance from the team to the customer/user has an inverse relationship with desired customer/user outcomes.
- Distance from the team to other stakeholders has an inverse relationship with organizational desired outcomes.
- Some stakeholders can cultivate the environment to reduce the incoherence of management processes and ways of working,
- Some stakeholders can cultivate the climate with effective DEI and increase the levels of psychological safety, inspiration, and motivation.
However, the Scrum Guide mentions 'stakeholder' thirteen times and does not explain 'stakeholder.' Further, 'leader' is mentioned only in the context of a Scrum Master.
A Stakeholder is an individual or group interested in or impacting an organization's inputs, activities, outcomes, products, or services. Stakeholders may have a direct or indirect interest inside or outside the organization. Some stakeholders serve teams. Some stakeholders are served by the teams.
Examples include customers, users, vendors, influencers, leaders, compliance, and governance.
Some stakeholders are more critical than others. Each stakeholder values various factors:
- Constraints such as time, effort, and budget, or
- Values such as usability, information security, usefulness, or cost reduction.
Leaders lead people; managers manage things (Admiral Grace Hopper). Not all managers can become leaders, and not all leaders are managers.
I have no issue with a manager with the right attitude taking on the Scrum Master accountability. Often, a manager has more power and influence to remove impediments, most of which are organizational.
The Scrum Master does not have to be one person. Indeed, the Developers could share the Scrum Master's accountability. For the Scrum Master accountability, I prefer people who take the responsibility of being a change agent seriously.
Indeed, there is nothing to stop a manager from being a Product Owner; Product Owners should, in my view, delegate product backlog management to Developers. It's much better for people with problems or opportunities to clarify their direction with the people who will solve or capture them. If that seems inefficient, try delivering the wrong thing right.
Leaders cultivate the climate and environment for emergence in a direction. Leaders embrace uncertainty and failures. The best failures result in learnings that are quickly adopted. Failures are kept small if releases are frequent and result feedback is gathered intentionally and promptly.
A manager, colleague, or stakeholder could be a Leader. Leaders go to the source to find facts to make effective decisions. Leaders also remove organizational non-value-adding waste, such as incoherence in workflows, processes, and systems. And they improve flow across value streams––psychological and actualized value.
They do so even in an organization where only some people need adaptiveness. They know organizational adaptiveness will be limited if processes are not adapted, even if only 5% of the organization needs it. Key processes include those in:
- HR (who to hire/promote/rotate, rewards, recognition, pay),
- Finance (budgeting),
- Procurement (vendor contracts),
- Release Management (continuous delivery), etc.
Good Leaders create followers, and great Leaders create Leaders (L. David Marquet). Great leaders improve coherence between what is said and what is done (Bjarte Bogsnes). Beyond Budgeting offers a path to more coherent management processes with agility through the Viable Map.
The Product Goal is the current single, clear, meaningful, valuable, more strategic, long-term, and ambitious objective for the Product represented in the Product Backlog. It is the why. The Product Goal enables focus for the teams working on the product.
The teams strive for desired outcomes with minimal outputs toward the Product Goal.
The Product Backlog is the emergent, ordered, sole source of work needed to attain the Product Goal. Even if there are multiple teams for the product, there is one and only one Product Owner, Product Goal, and Product Backlog.
Imagine trying to deliver value when objectives are not unambiguously clear. While the Product Goal can and should change if we learn it is wrong or we have done enough, there is merit in being unambiguously clear about it. Planning Language, or Planguage for short, offers a means for quantifying objectives.
- TAG NPS
- GIST Improve Net Promoter Score to what is deemed good by NPS experts
- AMBITION Segment leading NPS in the region.
- STAKEHOLDER Product Manager
- CONSTRAINT {current moment, end-to-end-customer-satisfaction-with-product}
- DEFINED https://en.wikipedia.org/wiki/Net_promoter_score
- AUTHORITY Market Insights team
- SCALE Net Promoter Score
- METER high to low NPS range previous 180 days
- NOW 5
- TOLERABLE >0
- GOAL 20
- STRETCH 30
- WISH 50
- PAST -30
- TREND -30 |<-| to +10 |-->| last 18 months
But it's crucial to precede objectives with a deep if quick, consideration of stakeholders, their criticality, and what they value specifically.
Some work can be for learning purposes. The best value validation is informed by result feedback. When I hear about high-cost failures that were never released, I wonder why anyone was surprised.
Have you ever wondered, "How can a team be successful without collaborating effectively with stakeholders?"
It's worth asking the 'twelve tough questions' from Tom Gilb.
Twelve Tough Questions - Copyright © 2024 Tom Gilb
- How do we know this is the most important problem? Why isn't the improvement quantified?
- What's the risk or uncertainty, and why?
- Are you sure? If not, why not?
- Where did you get that from? How can I check it out? How frequently can I check that out?
- How does your idea affect my goals?
- Did we forget anything critical?
- How do you know it works that way? How do you know perception is reality?
- Have we got a complete solution?
- Considering potential market value, are we going to do the 'profitable things' first?
- Who is responsible? Who else is responsible?
- How can we be sure the plan is working? And what empirical rhythm is in place to help us adapt quickly?
- Is it no cure, no pay, in a contract? Why not? What is the risk of not harvesting value?
Collaboration starts in the elicitation of strategy and objectives and continues through:
- product backlog refinement
- discovery (if there is a lack of evidence that value can be harvested and delivery is likely to be expensive),
- delivery (including timely review), and
- value validation (if the team is serious about making a difference).
Delivery of outputs is insufficient for product success. Measure outcomes and tweak for better impact.
I am also curious to know how a team can be successful without proactive support from leaders inside and outside the team. To attain more product success, the stakeholders and management processes must act coherently with the ways of working. Consider the Viable Map from Beyond Budgeting and the Beyond Budgeting principles.
Beyond Budgeting Management Processes –
Copyright © 2023 Beyond Budgeting
1. Targets- Set directional, ambitious, and relative goals; avoid fixed and cascaded targets (181).
2. Forecasts- Make forecasting a lean and unbiased process; not rigid and political exercises (182).
3. Resource allocation- Foster a cost-conscious mindset and make resources available as needed. Plan and make (financial) resources available as needed; not through detailed annual budget allocations (183).
4. Performance evaluation- Evaluate performance holistically to guide interventions; not based on measurement only and not for rewards only (184).
5. Rewards- Reward shared success against the competition; not against fixed performance contracts (185).
6. Coordination (formerly Rhythm) - Organize management processes dynamically around business rhythms and events; not around the calendar year only (180).
Beyond Budgeting Leadership Principles - Copyright © 2023 Beyond Budgeting
1. Purpose - Engage and inspire people around bold and noble causes; not around short-term financial targets (174).
2. Values - Govern through shared values and sound judgment; not through detailed rules and regulations (175).
3. Transparency - Make information open for self-regulation, innovation, learning, and control; don't restrict it (176).
4. Autonomy - Trust people with the freedom to act; don't punish everyone if someone should abuse it (178).
5. Organization - Cultivate a strong sense of belonging and organize around accountable teams; avoid hierarchical control and bureaucracy (177).
6. Customers - Connect everyone's work with customer needs; avoid conflicts of interest (179).
If you are a leader:
- Research Cynefin.
- Be slow to take on a new fad without dealing with what killed the last one and will likely kill the next one.
- Research aligned autonomy. Then, co-create boundaries with teams.
- Check out 'Trillion Dollar Coach,' 'This is Beyond Budgeting,' 'Alchemy,' and 'Out of the Crisis.'
- Research Genchi Genbutsu.
- Keep an eye out for training that takes a fresh perspective.
There is a saying
"A fish dies from the head."
Change also dies from the head; don't be that head.
Inspirations for this article:
- Ralph Jocham
- Nigel Thurlow
- Martin Hinshelwood
- Jesse Houwing
- Richard Hundhausen
- Simon Reindl
- Fabio Sanches
- Dave Pryce
- Sunil Gulia
- Nader Talai
- Eric Naiburg
- Kristen White
- Stas Pavlov
- Wilbert Seele
- L. David Marquet
- Tom Gilb
- Bjarte Bogsnes
- Steve Morelidge
- Dave Snowden
- Rory Sutherland
- W. Edwards Deming
- Admiral Grace Hopper