Listen to this post:
This is part 3 of 7 posts on PMI-ACP Exam Prep (link to part 2). In this post, I focus on working with the project stakeholders, including establishing a shared vision, collaboration, communication, and interpersonal skills.
Taking Care of Stakeholders
Stakeholder management in agile is a bit different than how it’s done in the traditional project management. In agile, the appropriate term for this effort would be “stakeholder stewardship.” The idea is that you comprehensively look after something that is work nurturing, safeguarding, and preserving – in this case, the project stakeholders.
In traditional project management, “stakeholder management” is the process of managing the people who are involved in the project. This typically starts by identifying project stakeholders and continue with controlling and directing their participation in the project plan, until they are released from the project. This doesn’t come across too collaborative and perhaps a bit inhumane as it treats people as resources. Stakeholder stewardship, on the other hand, ensures that everyone is engaged and looked after and has what they need to succeed.
If the project stakeholders are new to agile methods, they need some basic education about how agile projects operate to help them understand the approach that will be used, address any myths about agile, and guide their expectations. This education should include the goals, values, practices of the agile approach to help them understand why the project will be executed in this manner.
Here are some of the common concerns about agile:
- Executives and project sponsors: These folks are often concerned about the risk of failure due to the use of unprecedented practices and counterintuitive planning approaches, even though an agile approach actually provides better feedback loops for preventing failure.
- Managers: Managers may fear a loss of control or erosion of their role when projects assume an agile approach.
- The development team: They may resist agile methods if they feel that this new approach is being forced upon them by management.
- The user community: The user community is often worried they will not get all the features they want or require, or that the early iterations will result in poor quality deliverables.
- Supporting groups: Other groups may be concerned about an apparent lack of control, continual requests for their involvement, or the lack of a clear endpoint.
Earlier I mentioned it’s important to keep the stakeholders engaged throughout the project and collaborate with them. One reason for this is so they hear about change requests as soon as possible. An ongoing dialogue with our stakeholders will also help us identify potential risk, defects, and issues.
It’s also important to note that not all stakeholders are handled the same way. Some people may cause problems and be an impediment to the project progress. In such cases, the Scrum Master or the designated person needs to use their interpersonal skills and emotional intelligence to understand these stakeholders and their concerns in a positive way and engage them with the project. If this is not possible, it may be necessary to shield the team from their disruptive influence. Which, bring me to a point on establishing an escalation process. In case the team runs into an issue where they don’t have the authority or influence, they should be able to follow an established procedure to quickly escalate it to the appropriate stakeholder for resolution.
The most important way that agile incorporates stakeholder values into a project is by engaging the product owner in the prioritization of the backlog. Executing the work according to the customer’s priorities allows the team to deliver the highest priority item and deliver early value to the business. As mentioned in previous posts, without continuous stakeholder engagement, the project is likely to fall into the “gulf of evaluation.”
Another way to incorporate stakeholder values and interests into the project activities is to invite stakeholders to planning meetings and retrospectives. At the end of the day, it is the customers and sponsors who will determine whether our project is a success or a failure, so it is smart to plan our work and actions according to their values.
Principles of Stakeholder Engagement
The exam will assume you know the following principles of stakeholder engagement (you don’t need to memorize them but understand them):
- Get the right stakeholder – e.g. have the right group of developers on your team.
- Cement stakeholder involvement – e.g. document in the project charter how important the various stakeholders’ involvement is on the project.
- Actively manage stakeholder interest – e.g. take actions to recognize and reward stakeholder involvement, celebrate project accomplishments with stakeholders, etc.
- Frequently discuss what “done” looks like: Since knowledge work projects often create intangible products and services, there is a lot of potentials for a gap to arise between what the customer wants and what the development team creates.
- Show progress and capabilities: Projects may take a long time to complete. By showing what’s you’ve built frequently, it will help with increase engagement with stakeholders and show progress.
- Candidly discuss estimates and projections: If bad news is delivered early enough, it can be valuable. by tracking and discussing the features delivered vs. the features remaining, the team and the customer can make important trade-off decisions based on solid data.
Establishing a Shared Vision
On agile projects, failing is okay as long as the failure is fast and cheap and it’s still possible to recover the project. We ideally want to uncover disconnects in understanding at the lowest possible cost. By doing so, we save the organization money that it can then invest in other projects.
Agile provides us with some tools that we could use to establish a shared vision among all the stakeholders: Agile charters, the definition of done, workshops, modeling, and personas.
This is one of the very first documents created for the project. Agile charters recognize that scope may change and that initially, some aspects of a project may be unknown. And so instead of fully specifying the requirements, agile charters focus on goals envisioned for the project at a high level, gain agreement about the project’s W5H attributes, and obtain the authority to proceed. Keep in mind that agile charters are shorter documents and focus on how the project will be run rather than what will be built.
The process of chartering helps align stakeholder with the project. One way to help stakeholders explore and cement the basics of the project is to have them jointly develop a project elevator statement. Elevator statements are short descriptions of the project goals, benefits, and decision attributes that quickly describe the project of product. A popular format for elevator statements is as follows:
For: Target customer
The: Product/service name
Is a: Product category
That: Key benefits/reason to buy
Unlike: Primary competitive alternative(s)
We: Primary differentiation
An example would be:
For project managers who want to become agile project leaders the “learning to lead agile teams” class is a 3 day course that takes participants through a comprehensive agile development lifecycle, incorporating real case studies, and hands-on exercises unlike agile courses from generic training organizations we only use instructors with hands-on agile project experience to ensure they can answer all your questions, and our supplementary materials include valuable tools, case studies, and cheat sheets.
Definition of Done
Creating a shared definition of done is crucial for satisfying our stakeholders’ expectations. Therefore, a shared definition of done is necessary at every level of an agile project including:
- User stories: It may mean developed, documented, and user acceptance tested.
- Releases: The first release may be deemed done when system Alpha is replaced and there are no priority 1 defects or change requests.
- Final project deliverables: Done for the project may mean all high and medium priority features are implemented, there are 2 months of trouble-free operation, and the project receives satisfactory scores of greater than 70%.
The term agile modeling refers to the various modeling techniques that are commonly used on agile projects. While models are important in agile methods, their main value lies in the discussion and creation of the model, rather than the final output. As a reflection of this, agile models are often sketched on whiteboards and then photographed as a means of recording them. So agile models are typically lightweight or barely sufficient, capturing the design without a need for further polish.
Types of agile models that can be created during agile modeling include:
- Use case diagrams
- Data models
- Screen designs
Wireframes are a popular way of creating quick mock-up of a product. Wireframes are a form of “low-fidelity prototyping.” In other words, they are a quick and cheap way to get feedback on something. See a sample wireframe for a website below:
Personas are a quick guide or reminders of the key stakeholders on the project and their interests. Personas should:
- Provide a description of the user
- Be grounded in reality
- Be goal oriented, specific and relevant
- be tangible and actionable
- Generate focus
See a sample persona below:
Personas can help keep the team focused on delivering the features that the user will find valuable, and this leads to better decision making on the project.
Communicating with Stakeholders
Since knowledge work is often invisible, we can’t easily tell the state of the project by looking around the office. It’s critical for agile stakeholders to communicate frequently to ensure that everyone is on the same page and kept up to date since many project failures can be traced back to a failure of communication.
The preferred way for agile stakeholder communication is through face-to-face communication and looking at the above diagram, we can see that paper-based communications are the lowest in terms of communication effectiveness.
Knowledge sharing a key component of agile methods. Agile projects are encouraged to take an abundance-based rather than scarcity-based attitude toward sharing knowledge. This means we aim to share information and make it available to everyone who might want to consume it, rather than hoarding it to secure our jobs or increase our project stature.
Some great examples of agile information sharing include Kanban boards, information radiators, personas, and wireframes (which I discussed above).
Agile methods also emphasize knowledge sharing by using low-tech, high-touch tools like cards on a wall to plan and schedule project.
Another less obvious way to share information ins team co-location. This practice is not done to save space or ease management overhead; instead, it is done to speed the sharing of information that occurs in face to face environments through osmotic communication and tacit (unwritten) knowledge.
“Information radiator” is agile’s umbrella term for highly visible display of information, including large charts, graphs, and summaries of project data. These tools, sometimes referred to as visual controls are usually displayed in high traffic areas to maximize exposure, where they can quickly inform stakeholders about the project’s status. The sort of data that might be displayed on an information radiator includes:
- The features delivered to date vs the features remaining
- Who is working on what
- Velocity and defect metrics
- Story maps
- Burn charts
Workshops should have clear goals and schedule that is visible to everyone. Here are some tips that can make workshops more effective:
- Diverse groups reflect a wider range of viewpoints than just a few experts and therefore are likely to generate a wider range of options. Adding more diverse voices to a group can lead to valuable new ideas and solutions.
- To prevent dominant individuals and extraverts from monopolizing the discussion, use techniques such as round-robins or generate ideas on sticky notes.
- Start the session with an activity that engages everyone. For example, you could simply what “done” means and go around the room asking all participants. This would set the mood and make sure everyone understands this is a working session.
User Story Workshops
Also known as story writing workshops are the preferred mechanism for gathering candidate user stories and starting the process of refining them into well-formed stories. It’s best to do these workshops in a group setting rather than individual interviews to make sure any gaps can be filled and gold-plating requirements doesn’t happen. Often it turns out that workflows can be optimized. For example, the sales team may be passing all sort of info to the finance team but all the finance department cares about is a couple of data points.
Another important reason for conducting user story workshops is to engage the key stakeholders in the design process. As they work with the dev team and discuss the trade-offs and priorities of the work, 2 things will happen:
- The team will get a better understanding of the stakeholders’ needs, without jumping directly to possible solutions, and
- The business will get a better sense of the costs and options of the various approaches before they commit to one of them.
Brainstorming and Brainstorming Methods
brainstorming is a collaborative technique in which a group tries to rapidly generate a lot of ideas about a problem or issue. The goal is to maximize the number of suggestions generated and there are no “stupid ideas.” There are a few methods to use for brainstorming:
- Quiet writing: In this method, the group is given 5 to 7 minutes to generate ideas individually and then share with the group. This helps with minimizing peer influence as ideas are generated in isolation before being shared.
- Round-robin: In this format, people take turns to share an idea at a time and perhaps build upon ideas shared. For this to work, participants need to be comfortable in sharing their ideas publicly.
- Free-for-all: With this method, people just shout out their ideas spontaneously. This method can be collaborative but does require a supportive group. You need to make sure the introverts are not left behind and everyone participates.
Once ideas are captured the task then is to sort them, prioritize them and then implement the best ideas.
There are a number of collaboration games that help group communication. There are few different games:
- Remember the future: This is a vision-setting and requirements-elicitation exercise.
- Prune the product tree: This exercise helps stakeholders gather and shape requirements.
- Speedboat: The goal of this exercise is to identify threats and opportunities (risks) for the project.
- Buy a feature: This a prioritization exercise.
- bang-for-the-buck: This exercise looks at value vs. cost rankings.
Using Critical Interpersonal Skills
Poor interpersonal skills can quickly demoralize and disenchant a technically strong team, while a leader who effectively uses these skills can get amazing results from an average team. A few interpersonal skills in the agile toolkit are:
Emotional intelligence is our ability to identify, assess, and influence the emotions of ourselves, other individuals, and groups.
Active listening is hearing what someone is really trying to convey, rather than just the meaning of the words they are speaking. There are 3 levels of listening:
- Internal listening: At this level, we hear the words being spoken and may be very attentive but we are really thinking “how is this going to affect me?” and so miss the speaker’s message.
- Focused listening: When listening at this level, we let go of our own thoughts and put ourselves in the mind of the speaker. We empathize with their thoughts, experiences, and emotions as they tell us about the situation.
- Global listening: At this level, we build on the above approach, and add a higher level of awareness, like longer antennae, to pick up on subtle physical and environmental indicators.
When facilitating a meeting or session, keep the following in mind:
- Goals: People often think attending a meeting is a waste of time. To avoid this feeling it’s very important to establish clear goals for each meeting or workshop to get people engaged in the discussion.
- Rules: Establishing some ground rules will also help with higher engagement. For example, you may ban cell phones, starting and ending meetings on time, etc.
- Timing: Assign someone as the timekeeper to make sure you don’t lose track of time.
- Assisting: This means you need to ensure the meeting is productive and everyone has a chance to contribute. i.e. the introverts and junior members of your team.
Negotiations happen throughout the agile project, either when gathering requirements or prioritizing tasks. Negotiations are successful when there is an open discussion and all parties can be heard and the pros and cons are noted. Work toward a win-win solution.
Conflict is an inevitable part of project work. Creating an environment in which people can us conflict constructively is a key part of successfully engaging stakeholders on a project. When a team is in conflict, we should first take some time to observe the situation and make sure we are assessing both sides of the dispute. Allow time for proper observation, conversation, and intuition about the issues before taking action. First listen to complaints, without immediately wanting to solve it. Feel the energy of the group and assess the level of conflict. One way to assess the conflict is to examine the language the team is using and compare it to Leas’s description of 5 levels of conflict:
Here is a great link to read more on how to deal with conflict and steps you need to take: https://dzone.com/articles/agile-managing-conflict
Participatory decision making
This means engaging stakeholders in the decision-making process. The speed at which you make decisions and the group’s level of engagement with the decisions will impact both the performance of the project and the cohesion of the team. Basically, commitment increases as involvement increases. There are few different models for decision making but they all have 2 things in common: convergence (the goal is to converge on a collectively agreed-upon best answer) and shared collaboration (they are looking for group consensus rather than yielding to the will of a single influential individual). So let’s look at a few models/tools:
This is simply getting the team to vote “for” or “against” an idea by a show of hands. This technique will limit the opportunity for discussions but if you are looking for a quick vote then this could help.
You are basically asking for a vote on but also giving the people who are not sure (thumbs sideways) a chance to voice their thoughts. This is quicker than getting everyone’s opinion and it could shed some light on some concerns or conflicts the few people in your team may have.
Fist of Five Voting
This approach has the advantage of speed, while still allowing people to indicate their degree of agreement. Using this approach people vote by showing the number of fingers that indicate their degree of support.
Highsmith’s Decision Spectrum
Using this technique, team members indicate how they feel about a decision by placing a checkmark on a spectrum ranging from “fully in favor” to absolutely not, veto.” Again this method invites people who are not entirely in favor of the decision to voice their thoughts and opinions. See below for a sample of how this would look: