Stakeholder Mapping – The Lost element / Missing Piece of our Jigsaw puzzle

So much data is written, spoken, taught and available across the industry on Stakeholder mapping and management and the best surprise or part is, that we all are still struggling to get a handle on this concept and engage our stakeholders in the right way.

I personally believe the basic problem is the one size that fits all approach that all of us apply and think it will always work. Stakeholders come in different shape, size and formats along with their own wimps and fancy, they need to be catered to, nourished and for a lack of idea – We need to do literally baby-sitting for them, but the worst possible element is that we doing just the opposite, we are painting the town RED and look and treat all our stakeholders thru the same lens and 100% similar approaches. This strategy is bound to fail and is actually failing, and we are not learning from the same.

Once again … I shall throw some light on elements that have worked for me, will they work for you, not sure but it would worth reading and relating to your own concepts.

As much we do stakeholder mapping in the initial stages of the project, this concept is always ever-going, it is like Risk Management – to be done on a continuous basis, as stakeholders would change, move out of your engagement, new ones would be added, business dynamics could incur changed, environmental conditions will bring different levels of changes, there is no standard recipe here.

Recommend developing a stakeholder mapping document, this is a visualization document that helps clarify positions and interest of each stakeholder category and individually, it helps to identify the supporting factors of the stakeholder including power structures with in the system.

This analysis helps identify all characteristics of the interest group, their relationship among themselves and serve the purpose of effectively communicating with them.

Draw initial observations about the alliances or power structures along with conflicts between stakeholders (we all know that there is a decent amount of politics in all organizations), we do not want our projects to get stuck in this mess and have clear ideas on management of our deliverables.

Steps to develop Stakeholder Maps:

• This would involve a SPOC from the organization, who is has connections internally in the system, who knows the system inside-out.
• 1^st level brainstorming happens with the SPOC and a few select members of the scrum team
• Define and use different symbols for connections. E,g, for more complex elements use broken lines.
• When developing the map, consider the following:
  • Why this project?
  • What are the goals and objectives at Business Level, Department level and Org level?
  • Who will benefit from its success?
  • Who has an interest in the project getting successfully rolled out?
  • Who could be your potential showstoppers?
• This would lead to a draft level stakeholder map, which then needs to be validated
• This entire activity of creating the initial draft of the map would be around 60 – 180 mins which again depends on the complexity of the organization and number of stakeholders.
• Remember: it often takes time before all parties involved speak openly about themselves and their own needs and needs of their Business / department / organization.

This approach would help us obtain valuable information on how and when and what to communicate, what should be the format of communication? How often it should be done? Who all needs to be there, at times we also need to identify the personality profiles of our stakeholders, this would enable us to understand if they are detailed oriented or big picture view, as we do not communicate adequately and sufficiently (even though our information would be true and complete), we shall loose the focus of our stakeholders, if to a detailed oriented person we provide high level information and vice versa, it a just a disaster waiting to happen

The dynamics within the team, department and organization are hugely complex and critical. It is important for the Product Owner along with the Scrum team to understand these interactions, and for doing the same, stakeholder mapping as an activity is essential.

Generally, when defining stakeholders, it is important to move away from being generalist and one should be focused on being as specific as possible.

A good stakeholder map can be instrumental for your project success, Applying these principles would solutions worth its salt over a period.

Remember you need to have different approaches and strategies for dealing with the stakeholders who are interested in the outcome of your deliverables and the others who may not be on the same side of the coin as others or yourself. There is no one size that fits all approach.

A few final thoughts:

If you are involved in managing or leading a project, it is your responsibility to ensure the project is delivered successfully. It is up to you to deliver the project on time, to budget and to quality. Stakeholder mapping and stakeholder engagement is crucial to achieving these goals.

Product Owners should not under-estimate the power and value of stakeholder management and engagement, this could be a potential make/break of your assignment.

“How Might We” – A Tool to solve issues that surface @ Retrospective (Innovate your Retrospectives and Product Backlog Management)

The How Might We framework is quite often called HMW. The framework was originally created to define and frame design challenges, but you can use it to address a lot of different challenges you might encounter.

The How Might We framework is basically a way to reframe a problem. You’re not only trying to see the problem from a positive perspective, but also opening your mind and consequently your possibilities to new solutions. This can be an amazing opportunity.

This concept has been borrowed from Design Thinking approaches. I have personally used this concept to resolve issues and impediments in my clients Agile transformation and adoption journey. It is a different way and a method to tackle things that would bring different views and perspective to life.

Normally HMW question can be quickly formulated if good findings / issues / problems statements have been identified. This definition of HMW should not take more than 15-20 mins / issue or problem. We would typically do this with a lot of white boarding, using Post Its, Pen and Paper.

When we redefine our problem with the How Might We approach, we are actually turning challenges into opportunities. It’s a process, and you might not get it right the first time. It’s an important tool for mastering the ability to develop creative solutions to problems. Redefining our problems in this way can unlock a world of possibilities.

Make sure your team is empowered to come up with even silly and crazy ideas. Create a safe environment where brainstorming is truly valued. At this point, don’t worry about the feasibility of the ideas, just brainstorm and go crazy. In some cases, the crazy-impossible ideas can be reframed in a brilliant and innovative way, so don’t constrain your mind or your team. HWM questions are a way to foster brainstorming and other ideation sessions.

Why are they called “How Might We”

“How” part suggests that we do not yet have the answer. It allows us to consider multiple avenues for innovation and reinforces that we are still exploring the problem and solution space.

“Might” emphasizes that there are many different paths we can go down when thinking about solutions. This allows for open-minded creativity and brainstorming and thinking about the problem from multiple perspectives. This “might” is where innovation becomes part of the process.

“We” immediately brings in the idea of teamwork. “We” should all work collaboratively to come up with a joint understanding of the problem and put our heads together to come up with a joint solution.

How should this work for an Agile team?

Reflect upon all the issues / challenges / Improvements as needed and identified during the retrospective, then reflect upon them to see and understand the context a lot more better (at times, we are emotional during the retrospective and want the whole world to improve)

Motivate the team to explore and come up with several HMW questions that could address the needs or the problem statements

Each question should follow the logic of “How Might We” and it should be followed by a verb, noun and type of the user base that we are trying to address the problem for

As a passing thought this approach of HMW can be used for any type of problem solving or identifying new ideas / thoughts / innovations or opportunities – this could be used in resolving the issues or challenging the current status quo of the Product backlog approaches, how user stories are to be developed, what solution would address the problem in hand.

I have seen a lot of people using HMW statements to invoke discussions leading into innovation, but as the case with some other models, they can go horribly wrong… Like too much of Open Ended Ness

• How might we make our app more usable?
• How might we redesign our website to make it better?

Or at times, we go so deep, that we have created a narrow view:

• How might we make our app’s add to cart experience more functional?

When HMW statements are too narrow, we lose all the incredible, innovative ideas that can come from them. With too much focus, we are stuck on one particular solution already. We want several different ideas to test at the end, so focusing too much on one solution will limit creativity and innovation.

Always remember that in addition of the description of the problem, a target customer must be defined for the project / problem to be resolved. In doing so, we are now trying to highlight the user and his / her needs (now notice we have got Persona as concept involved here)

Have multiple HMW ‘s for each problem statement, Each HMW question can then be understood as a prototype and testing in a short brainstorming session, The one that is the most appropriate one will then be chosen and pursued.

Key elements to take care of:

• Do not discuss a HMW question for too long, Timeboxing should be performed for each HMW and do not get bogged down in the phrasing of the question.
• It is essential to be optimistic and close to the needs of the user to come up with several good HMWs

Use the above ideas and thoughts in your next retrospective or product backlog refinement session, do share your experience and help us improve the approach and tool sets for continuous improvement approaches.

I propose this approach to be added to the concept of Liberating Structures

Gemba Walk – A method to collect requirements & observe current approach of working (Forgotten tool in the industry)

A Gemba Walk is the practice of Product Owners, Product Managers, Business Analyst personally observe the place where work is being done. The original Japanese term comes from gembutsu, which means “real thing” or “real place.” Thus, the Gemba is wherever work happens, and value is added to products or services. The Gemba may be a production floor, an emergency room, a construction site, or a classroom.

During a Gemba Walk, PO’s / PM’s should physically go to the places where people are putting together products or using them, helping customers, analyzing data, maintaining machinery, or any other process. The philosophy behind Gemba Walks rests on the idea that it is easier to gather feedback, spot process or workspace issues, and build trust with the team by observing work firsthand. Employees tend to be more open to pointing out opportunities for improvement or sharing concerns when they are in their own workplace.

PO’s / PM’s who have committed to Gemba Walks typically spend about 60 minutes a week at the Gemba. They pay careful attention, ask questions, and observe processes, The idea is to catch on ground information and understand the nature of work getting performed

Some Tips on doing a GEMBA walk:

• Define a clear focus – In terms of what is to be observed? Who is to be observed? What is the purpose and scope of my learning?
• Communicate with the Team Before the Walk:You don’t want your client / end users to feel blindsided by a Gemba Walk – it isn’t a surprise inspection, rather it is a technique for collecting requirements, it is essential to describe the purpose of Gemba Walks and let the team know what to expect. Open communication in advance will help people feel more comfortable and foster engagement.
• Pay Attention to the Handoffs: If you follow the value stream, you will likely find that all the stakeholders and output of that process along with the handoffs between processes, peoples, or departments. Those areas may yield the most potential for eliminating waste.
• It’s not about just observation: The process of capturing the information / data is very important.
• Separate Observations from Interpretation: Pay heed and attention to the methods of working, work around solutions as used, challenges faced, discussions between 2 people (do OSMOTIC communication – do not participate)
• Pay attention to routines and details: Qualify how long a work takes (measure it), Quantitative analysis can be easily visualized with charts and graphs and more meaningful insights can be obtained.
• Based on all of the above: Obtain new insights on how the problem is resolved today and how the process is lived in the real world
• Do not fire or make judgement calls.
• Follow Up: After your walk is over, be sure to follow-up with the teams, let them know what you learned and ask for additional input. It’s a good idea to close the loop so people aren’t left wondering about your impressions.

Gemba Walk Checklist

Every time when a PO / PM performs a Gemba walk, they will need to prepare a checklist in advance. This list will help them focus and target their efforts in right direction.

The checklist has to include questions that will help understand the process that they are going to observe in a better way. Questions may vary depending on the theme of your Gemba walk.

Here are some basic Gemba walk checklist questions:

Use Gemba walks a means to collect needs, observe the current behavior and work as performed, challenges, If possible speak to end users or doer’s of the process, understand their needs and viewpoints.

Perform this activity for multiple days and across different segments of people, this would enable you to focus on different situations and scenarios that may come up.

Indecisive – Use 2×2 matrix – A tool to narrow down options and help prioritize your ideas / Product Backlog

The 2×2 Matrix is a decision support technique where the team plots options on a two-by-two matrix.

Each axis represents a decision criterion, such as cost or effort. Each axis is divided into two sections (example: low cost/high cost and easy/difficult).

The matrix is drawn on a whiteboard, then the team plots the options along the axes. This makes it easy to visualize the options that are low cost and easy, and low cost and hard, for example.

The best results happen when the team defines the boundary between the quadrants. For example, if the horizontal axis represents the time it would take to complete a project, the boundary line between the Fast and Slow quadrants might be defined as 4 weeks.

Where is the value for 2×2 matrix in usage?

• It helps in quickly determining which ideas / thoughts or options should be pursed or rejected or parked for now
• Obtain a 1^st hand overview of ideas that have already have a certain qualification and maturity
• Carry out prioritization, innovations, identify market opportunities
• In cases where the problem statement is complex, it helps in breaking down the idea into individual components
• Use it when you have a decision to make

Use this tool in place of:

1. Kano Model
2. Dot Voting

Use this tool in conjunction with:

• Venn Diagrams for feasibility, economic viability and desirability
• Dot Voting for prioritization within a quadrant

This tool can be as versatile as a Swiss Army Knife (multiple purpose), It can be used across spectrums ranging from basic technical decisions to solution-oriented business models. Quantification in form a cost / yield chart can be of help, Sponsors are happy to use such a chart as a basis for decision making.

Steps to use 2×2 Matrix

1. Draw the 2 x 2 matrix and designate your X and Y axis as per your needs and requirements. Use opposite references such as High: Low / Important: Negligible / Cost: Savings and so on..
2. When evaluating for ideas, focus more on the benefits for the user and the feasibility and use measurable and tangible criteria for evaluation / opportunity analysis
3. Start with a board classification and question in which quadrant the idea should be placed
4. Place your current idea in relation to the other already existing ideas
5. Pay attention to the opinions of the team and try and find consensus
6. First take the idea and position it for X or Y axis, once a side is decided, then plan for the next axis, this approach would help in identifying the right or more suitable quadrant.
7. Repeat this process for all the ideas on the table
8. If there are several ideas in a quadrant, then select the top 3 for further discussions (do not attempt all)
9. Also check if there is any quadrant which are empty, they represent further opportunities and unfulfilled needs

Key elements to be aware of:

• Keep ideas as simple as possible – complexity means confusion on the matrix
• Rewrite or split the idea into several ideas if it helps to clarify the positioning
• Experiment with different possibilities and adapt the axes to the problem statement and the objectives

This tool can be used for Product Backlog Prioritization, Involve your customers to do the 1^st level review and then involve your scrum team to perform the 2^nd level of review from a technical stand point

Use different approaches and mix and match to get the best and the optimum results for your product, customer, end users and the team Innovate yourself, to engage the customer and keep your scrum team motivated

Empathy – A tool for better understanding of our end users and solution users

Several times in my career, I have heard many people / gurus say to use Empathy as a tool to better understand your customers and their needs, their behaviors’, their pains, and their future outlook. The idea is empathy would only provide the experience from the past and not give any new insights in the needs and requirements of the future.

A lot of us (including me) get confused, when we speak about Persona and Empathy … are they similar concepts, do they capture and provide similar information, how are they to be used, when are they to be used, what is the value proposition of using them, which one is a better approach?

This document of mine would try and shed some light on the Empathy part and hopefully in future we shall explore the depth of Persona also.

Empathy map is a tool for target audience analysis. It is used to identify feelings, thoughts and attitudes of existing or potential users / customers and understand their needs, The idea is to obtain in-depth insights on potential users by means of what, why and how questions. Empathy maps focus more on the emotional state of customers.

Let’s first focus on the usage and value that Empathy would provide:

• It would help us better understand and appreciate insights from testing or observations with the users and capture different perspectives
• Helps understand where the user has problems or potential benefits
• Helps to collect findings to build Persona

Empathy map as a tool should be used in conjunction with other tools like Customer Journey mapping, Persona / User Profiling and Value proposition canvas

When doing Empathy mapping with the customer, ensure that we have 2 people, one person documents and records the information while the other would-be posing questions. Typically, this should max 30-45 mins of session

Use a template for Empathy map where you record everything about the customer such as:

• Think & feel
• Hear
• See
• Say & Do
• Pains
• Gains

Use questions such as:

• Where is the customer? What do they see?
• Who influences them, with whom do they interact / communicate?
• What emotions are driving the customer
• What does it say about their attitude?
• Where does the customer behave in a contractionary manner?
• What are their biggest challenges / pain areas?
• What are the opportunities and benefits they may have?

While doing this exercise, focus on human values – like thoughts, opinions, feelings, emotions (at times these may not be directly available, you have may to infer based on their body language, tone, word selection).

Pay special attention to contradictions, often we can identify something new from what the customer says and the way they behave.

Using this data, analysis all the edge cases, dig into unique behaviors and identify what are we building … why are we building, will it serve the purpose?

Empathy mapping is a unique tool that a Product Owner or a Business Analyst should have in their armory to better serve and engage the End User community, better your tools, product and services are aligned to the end user … higher is the potential for your products to dominate the market.

Again it should never be one size that fits all.

OLD WINE, IN OLD BOTTLE – BUT WITH NEW LENS

Agile and its variants / frameworks like Scrum, Kanban’s has been around us for more than 2 decades now, but very few organizations have been able to apply and reap the benefits of the same to the degree of investments made by each organization.

We want to be Agile, but do not want to embrace the value and eco system of Agile, I see a lot of organizations wanting to do Spotify ways of doing things, they have gone ahead and labeled their teams as Squads, Tribes and Chapters … but has anything changed, has the approach changed? Or the culture undergone a transformation? Has labelling teams made them adopt the Spotify ways of working …. I do not believe so.

Any change needs to be driven, its needs to anchored, its needs support and needs to be groomed for survival. It needs time, patience and attention from the Leadership or the sponsors who are putting the hard dollars ($$$) on the table, but alas dollars ($$$) are available, but the sponsors or the leadership team is missing from action.

Why is it so difficult to follow in practice 14 pages of PDF called Scrum Guide? Have we understood the intent of the document? Or it was just a new buzz word or a new kid on the block?

Historically if we see we had 7S theory, Lean, ISO, CMMI, Six Sigma’s and many more … where they now, if organizations have used them, have they got tangible cum measurable benefits? Why would an organization adopt ISO and CMMI and also Six Sigma (either together or one after other) … at the end of the day all speak the same language but with a slight difference, the end result is supposed to the same, the outcome needs to be the same. Why would any organization need improvement approaches using different models and methods, well the harsh truth is that we never implemented the initial one in the true spirit, therefore news ones would be required.

I would like to present an analogy over here … Each day when I get out of my bed, I would brush my teeth (well – Let’s say I use Colgate as a toothpaste), once done and dusted with Colgate, would I use Close-Up as new toothpaste for doing the same job, well my response would be a BIG “NO”, why No … Well, if I have done my job clearly and well with Colgate / 1^st option, I should not be needing the second option.

Over a period of years based on my experience, I am jotting down a few elements to be implemented or practiced to gain the true value of using Agile as a framework for developing solutions and products.

As mentioned in of my earlier post, we need a beginner’s mindset and attitude to be succeeding in Agile. Beyond this a few more elements as food for thought:

Start with understanding the problem statement:

Whenever we develop any product, solutions, or any output, it is critical to understand the user base, end user behavior, their needs, their requirements, their current pain areas, problem statements. By doing this we as a Scrum Team would start to understand the big picture of our purpose and create the right vision and objectives for development. In order for the team to create a solution, it needs to internalize the problem, understand the depth of the need, impact of the wrong solution or no solution.

Visualize how our developed solutions and products would change the working pattern or the social behaviors of the society and people who would use it or be impacted by it.

I would like to sound critical here … In real life our Product Owners directly jump to the explaining the user story … but the science behind the story is missing for the team, they are unable to see the vision and visualize the trances of their incremental solution on how it would lead to the potential solution.

Start with Human Beings

Remember our solutions would be used by real people, we need to start engaging and interacting with potential end users for understanding the needs, possibilities, experience, knowledge for creating a deeper understanding. End Users know their pains and gains of the system better than anybody else.

Interdisciplinary Teams

Collaboration is a key element of working on any project (irrespective of using Agile or not), Projects cannot be done by a single source or an entity, we would require collaboration of skills and talent to come together and ensure there is a healthy chemistry of working and all of us are working towards a common goal. Teams with varied skills and talent help in developing a creative process and continuous reflect on the same to see its feasibility of applicability

Our current challenge is that our teams are having different objectives, vision, goals and KRA. Each of us are focused on getting our KRA done to meet the performance appraisal objective. We are conveniently missing the client goals and objectives

Experiments and Prototypes

Only final product when used by the real end users would we know if our development has been successful or not, but to get intermediatory feedback, Scrum team should heavily depend upon experiments and prototypes, this is a quick way to get feedback and understand if our course of direction needs to change. Reviews should always be at 2 levels, one at the Product Owner level and other with the team that would be in touch with the end user community. Both the reviews should be looking at the holistic approach. One should always practice that “Less is More”. Emphasize that solutions have to be proven, ones that have got feedback should be actioned upon … Important – do not focus on only negative elements (actually there should be no negative element, it is more about a feedback).

Be mindful of the process

As in project, there would be some degree of process, that is either pre-defined or the scrum team would define it for itself. Process could be on how the Product Backlog Refinement would occur, Of Defining and agreeing on Definition of Ready/Done, What approach the team would adopt on Daily Standup / Scrum and so on … It could also lead into how conflicts have to be managed, how issues / impediment management would be taken care of.

The idea is to have simple and effective processes that would enable the team to work on a cruise control mode and deliver value

Accept Complexity

At times our solutions would be very complex even for a simple set of problem statement, we may have to integrate multiple 3^rd party tools and products, that itself would raise a level of complexity, sometimes working in some cultures could have its own set of challenges, the stakeholder community is changing regularly, this puts additional burden on getting re-aligned with the ever-changing thought process and new stakeholders.

 Co-Create and Grow with the concept of Co-Create

Agile is to solve problems, create new solutions, have happy customers. All this cannot be done in isolation, we need to engage multiple vendors, stakeholders, partners, business models, financial elements.

At times systems thinking along with Lean Start up approaches would be critical. Agile recommends collaboration with the stakeholders and the best approach would always be to co-create, It would help us pose right questions to the right people at the right time to get feedback and enable our journey to the next logical stop.

We need to regularly converge and diverge to reconverge back. This is a constant process and should be helping and assisting scrum team along with the decision makers.

All that is described above is nothing new, we all know it, we have read it, heard it, but are unable to put all of these elements in practice.

It takes 3 things to make Agile work in any organization …

1. Willingness of the Leadership to embrace agile (it cannot be just a lip service)
2. Attitude of the Scrum Team towards Agile
3. Aptitude of all involved stakeholders to respect the agile ways of working.

How many of us are willing to say that all 3 happen in our respective organization.

It is time that Leadership wakes up and smells the coffee … before its too late (remember they close the Check In Counters at the Airport 45 mins before the scheduled take off) … we being late would only impact us … as the flight has got its money and flown without you, with this analogy, Industry and Users would move forward and provide their dollars and business to your competitors, if you are not there.

Choice is always yours. Exercise the right one.