The Quick And Dirty On Stakeholders

A Scrum Product Owner’s Quick And Dirty Guide To Stakeholder Management

Identify Stakeholders

One of the core responsibilities of a Product Owner is managing stakeholders. Successfully managing Stakeholder expectations, decisions, and time are all signs of effective stakeholder management. There are many tools and techniques to help you identify your stakeholders, however, below is a list of ideas to help you wrangle in those stakeholders and identify who they are:

  1. Follow the money – find out who’s got some skin in the game
  2. Resources – find out who’s giving your their people to assist with development
  3. Deliverables – find out who you are delivering the product to
  4. Decision-Makers – find out who will make decisions before you can deliver the goods
  5. Related Programs/Products/Projects – find out who acts as a supporting function to your product
  6. Organizational Charts – find the organizational chart and make sure it is up to date
  7. Team members – if you’re new, ask your team members
  8. Find Influencers – Unofficial People of Influence who yield power through influence and not their position

Know What Motivates Your Stakeholders

Understanding what motivates the stakeholders is just as important as knowing the organizational goals. Of course, we like to think that everyone thinks, “yes! go team and go us! let’s move towards our goal.” Unfortunately, politics also play a part in the Product Development game. Some stakeholders have their own interests in mind or put their own department needs first. They lose focus on the over-arching strategy of the organization. Effective Product Owners need to be aware of:

  1. The Organizational Strategy
  2. Budget Positioning
  3. Personal Agendas
  4. Stakeholder “Pet Peeves,” “Pet Projects,” and their “Pet People.”

Problem Children

Some stakeholders bring their “baggage with them.” Sometimes they lose trust in a Project Manager, Scrum Master, organizational leadership, the delivery team, or have no faith in the product itself. Some stakeholders might have been recently burned by a project. They can have some sort of “baggage” they carry with them. No one is perfect, and sometimes, as a Product Owner, you just have to own those past issues to keep development moving forward. Saying, “I’m sorry” is free and owning those issues and sharing how you intend to do it better (sharing the lesson’s learned with the stakeholder) is the first step in gaining the confidence of any “problem children.” Below is a list of reasons why your stakeholders may be “acting out.”

Lack of trust in

  1. Project Manager/Product Owner/Scrum Master
  2. The Project/The Product/Product Delivery Team
  3. Product/Project/Program goals not articulated or defined in accordance with the organizational strategy
  4. “Bad Project Experiences”
  5. Your Own Past Mistakes

Problem Children exhibit the following behaviors:

  1. Meddlers: Always inserting themselves into decisions, processes, or meetings where they are not required
  2. The Forever SME (Subject Matter Experts): Usually a high performer who was promoted but hasn’t let go of the responsibilities of their old position
  3. Indecisiveness: Can never make decisions in a timely manner
  4. Lack of Budget: They ask for everything but don’t want to help pay for it

Golden Unicorns

The ideal stakeholder exhibits the below traits. Our “golden unicorns.” As a Product Owner, we want to make sure we keep the trust of our golden unicorns all the way to the finish line.

  1. Belief in the Product/Program/Project
  2. Don’t revel in the past — even if they had a bad project experience
  3. Communicate their needs well
  4. Availability
  5. Team Player
  6. Excellent Manager and Employee
  7. Positive self-esteem
  8. Helps motivate team members and other stakeholders
  9. Accountable & Responsible
  10. Can make timely decisions

Share your thoughts on stakeholder management in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

Scrum Product Owners Part 1

Scrum Product Owners Part 2

Urban Legends In Our Organizations. Listening To Our Naysayers, Seers, And Jaded Sage

The 5 P Pyramid Model. Assessing Policy, Process, Procedure, People and Personalities In Scrum.

The 5 P Pyramid Model.

I recall my first software development project as both exciting and nerve racking. Luckily, I was paired with an extremely talented Business Process Analyst who’s approach to requirements gathering was both methodical and like watching an artist at work. He introduced me to several ways of thinking about organizations — what I now call the 5 P Pyramid Model. This model has helped me analyze business processes and has been a wonderful tool for change management and exercising business agility. I continue to refine his ideas and accumulate my own knowledge, however, I would like to share his lessons with you by using the Scrum Process as an example.

“When eliciting requirements or attempting to document information from your stakeholders, keep the following items in mind:

The 5 P Pyramid Model
  1. Policies,
  2. Processes,
  3. Procedures,
  4. People, and their
  5. Personalities”

Policy

Policy is about understanding the landscape you operate in and those affected by your decisions. Policies guide decisions and provide rationale for their existence. Well written policies describe the what — they do not describe how an organization will fulfill the requirements of the policy. Generally, you can bucket your policies as external and internal. Internal policies also have two characteristics: De jure and de facto.

  • External policies are the laws and industry standards your organizations must adhere to. These include international, federal, and state laws you must adhere. In the case of Scrum, a government agency has policies regarding purchasing. Here is a great article regarding public-sector purchasing using Agile.
  • Internal policies are the policies related to the organization’s vision, mission, and goals. Whether undergoing business projects or internal IT projects, policies regarding how products and projects are delivered also exist. In the case of Agile, an organization’s policy describes the use of iterative and incremental development techniques vs. gated and sequential development.
    • De jure internal policies: Have been formally evaluated, approved, and adopted by the organization. Usually, they are easily accessible, understandable, and “written in stone.”
    • De facto internal policies: Have been widely adopted and accepted by the organization, however, they are not written and documented — leaving room for interpretation. Finding and documenting these policies can be difficult. At times it can feel like you’re on a journey to find the tribal leaders who can teach you the “song of the tribe.” It becomes increasingly difficult to find the tribal leaders to teach us their “songs” as more people retire and the trend for job hopping continues to grow.

Process

Business processes are the high level activities that an organization accomplishes in order to fulfill policies. They can and should be analyzed at different degrees of resolution. Think about the saying, “Give me the 30,000 foot view” vs. “At the ground level.” They should be assessed and dropped into three different categories:

  1. Operational processes are the processes related to an organization’s value chain. They are the core business activities that organizations engage in to deliver their goods and services. Using the processes that our Scrum teams use, we can see that the Sprint Review and Pushing Code to Production directly add value to our customers because this is where our stakeholders review and accept the code (sprint review) that was developed during the iteration and the delivery team makes it available to for use (delivery of shippable code).
  2. Supporting processes are the secondary functions that exist within the organization. They support the core business processes but do not provide value to the customers directly — Sprint planning and the daily scrum is where our delivery team plans what will be worked on (planning) and discusses the work being done over the past 24 hours to address any impediments to meeting the sprint goals (daily stand up). 
  3. Management processes help coordinate the operations and supporting processes. They drive for business efficiency and success. The sprint retrospective is used by the delivery team to inspect and adapt their daily work to improve efficiency and product backlog grooming is for prioritization, addressing dependencies, and writing effective user stories before the next planning meeting.

 

Scrum Process Diagram
A 30,000ft view of the Scrum Process

Procedures & People

Procedures are the steps that need to occur in each process to reach desired outcomes. They are normally fulfilled by a combination of people & technologies and are sometimes referred to as standard operating procedures. Let’s look at the procedures in our Scrum processes as an example and identify the people involved.

Sprint Planning
  1. Scrum Master: Opens the planning session, sets expectations, announces the agenda, and enforces a “time-box” throughout the planning session.
  2. Product Owner: Presents a prioritized and groomed product backlog to the Delivery Team and states what business objectives the stakeholders want attention during the iteration.
  3. Delivery Team: Examines the high priority user stories, asks clarifying questions with the Product Owner, identifies potential risks & dependencies, and helps refine acceptance criteria.
  4. Scrum Master and Delivery Team: Reviews the velocity from the last few iterations and plans their capacity for the coming sprint.
  5. Delivery Team: Uses relative estimation to size the user stories.
  6. Delivery Team: Uses their past velocity to benchmark how many user stories should be responsibly committed to.
  7. Product Owner and Delivery Team: Finalizes the Sprint Goal together.
Daily Scrum (aka. Daily Stand-up)
  1. Scrum Master: Ensures the meeting occurs, ensures no management interference on the free flow of information and discussion, and enforces a 15-minute “time-box” on the Daily Stand-up.
  2. Delivery Team: Conducts the meeting and discusses the progress towards the Sprint Goal.
  3. Product Owner: When available, attends the meeting to answer questions for the Delivery Team and makes decisions when needed.
  4. Scrum Master: Makes notes of any impediments that the Delivery Team is facing and immediately takes action following the Daily Stand-up to resolve impediments.
Sprint Review
  1. Scrum Master: Opens the Sprint Review, sets expectations, announces the agenda, and enforces a “time-box” throughout the review.
  2. Delivery Team: Presents their work in accordance with the acceptance criteria agreed upon during the planning meeting to both the Product Owner and any stakeholders invited to the meeting.
  3. Product Owner & stakeholders: Once the Delivery Team has finished presenting their work, the Product Owner and stakeholders are invited to ask clarifying questions and interact with what was built.
  4. Product Owner & Delivery Team: Takes notes of any issues, risks, or concerns from the stakeholders related to what was built or will be built in the near future.
  5. Product Owner: Accepts or Rejects each user story the Delivery Team worked on during the sprint.
Delivery of Shippable Code

Teams and organizations have their own way of pushing their code into their production environments. Due to the various best practices that exist, a separate blog post will be posted to address this at a later time. Seriously! This could be a ph.D thesis!

Sprint Retrospective
  1. Scrum Master: Facilitates the meeting, enforces a “time-box” and “sets the stage” –all information shared during the Retrospective stays within the meeting. I call this the “Vegas Rule” because what happens in Retro stays in Retro.
  2. Scrum Master: Starts with an ice-breaker if the Delivery Team is new and reviews past velocity with the team. The Scrum Master may also reminds the team of all the impediments that occurred during the sprint if the Delivery Team faced any during the sprint.
  3. Scrum Master and Delivery Team: The Scrum Master facilitates “Data Gathering” activity and the Delivery Team produces the data.
  4. Scrum Master and Delivery Team: The Scrum Master facilitates an “Insight Creation” activity and the Delivery Team creates the insights.
  5. Scrum Master and Deliver Team: The Scrum Master facilitates a “Prioritization” activity and the Delivery Team prioritizes what they want to improve.
  6. Scrum Master and Delivery Team: Decides how they will improve their own processes (either operating, supporting, or managerial processes) and creates a realistic plan to execute on. Scrum Master may need to coach new Delivery Teams about developing SMART Goals or some other goal setting techniques.
Product Backlog Grooming
  1. Product Owner: Prioritize the Product Backlog based on business objectives.
  2. Product Owner and Scrum Master: Gathers the requirements from stakeholders and writes preliminary User Stories and Acceptance Criteria
    • User Stories: As a <some role or person>, I want to <some procedure>, so I can <achieve a business outcome>.
    • Acceptance Criteria:
      • Functional
      • Non-Functional
      • Performance
      • Security
  3. Product Owner, Delivery Team, Scrum Master and invited stakeholders: Scrum Master and Product Owner facilitates an activity for the stakeholders and Delivery Team to refine the user stories and acceptance criteria.

Personalities

The personalities of our employees influences their effectiveness for their role(s). Selecting the right people with desired personalities ensures that the procedures and processes are completed correctly and in a manner that matches the organizational culture. While I won’t go into the different “types of personalities,” I will speak to the types of characteristics and traits that make an effective Scrum Master, Product Owner, and Delivery Team member.

  • Scrum Master
    • Ability to coach others with empathy.
    • Ability to resolve conflict and communicate with empathy.
    • Deep understanding of Agile and Project Management.
    • Facilitation skills and creativity.
    • Servant Leadership.
    • High level IT skills and knowledge.
    • Business acumen.
  • Product Owner
    • Strong leadership.
    • Ability to prioritize work and competing demands.
    • Ability to make decisions independently.
    • Ability to gather business requirements and elicit information from stakeholders.
    • Understanding of Agile and Project Management.
    • Domain knowledge.
    • Tactful communication skills.
  • Delivery Team Member
    • Ability to work well with others.
    • Openness to coaching.
    • Strong communication skills.
    • Strong technical skills.
    • Ability to analyze and solve problems.
    • Honesty and integrity.
    • Understanding of Agile and Project Management.

I’d love to hear your thoughts on the 5 P Pyramid Model in the comments below or if you’d like to have a discussion about Business Process Analysis, please contact or connect with me on social media!

Photo Credit: Flickr

Related Posts
For more on: