How to facilitate impediment resolution?

Step-by-Step Guide To Help Teams Find Potential Solutions For Impediments.

👋 Hello,

Welcome to a free monthly edition of my weekly newsletter, the “Winning Strategy.” I’m Vibhor, and every week, I answer one question from you about agile, product, roles, processes, frameworks, career growth, working with humans and anything else that’s stressing you at your office. Send me your questions here, and in return, I’ll offer actionable, down-to-earth, and straightforward advice.

If you are new, here’s what you might have missed:

1. Technical Skills For SMs, ACs and POs

2. First 30-60-90 days as a Scrum Master

3. Team Trust Coaching Cards

Note: If you enjoy reading this post, would you mind showing your support by clicking the little gray heart below the title above? It would really mean a lot and help spread the word about this growing newsletter. 😍

On to this week’s question!

---

Q: How can I, as a SM help my team find potential solutions for common impediments? I know I am not the one who removes the impediments, how can I facilitate the removal?

Thanks for the question.

The method I use is the adapted version of the popular CIRCLES method. For those who are not familiar, CIRCLES is a great method/framework to structure “problem solving.”

In its original form, it stands for:

1. Comprehend the situation (What? Why? Who? How?)

2. Identify the customer

3. Report customer’s needs

4. Cut, through prioritization

5. List solutions

6. Evaluate tradeoffs

7. Summarize your recommendation

I adapted this method to facilitate my team/s to find potential and robust solutions to common team impediments.

The adapted version, CIRCLE-P looks like this:

1. Clarify

2. Identify the root cause

3. Rephrase the problem

4. Create the structure

5. List out potential solutions

6. Evaluate the potential solutions for feasibility

7. Plan the implementation

To help you better comprehend this adapted version, I have summarized a walkthrough of an actual impediment resolution exercise/workshop I conducted a few years ago while training new Agile Coaches on the method.

Note: I have changed the names for privacy.

Let’s get started.

---

CIRCLE-P Walkthrough

Problem identified during retrospective: Frequent interruptions that disrupt focus and impede progress.

Here’s how I used the adapted version of the CIRCLES method:

1. Clarify

Before we all started working on the above problem, I made sure we were all on the same page. I asked a bunch of questions to get more info and made sure we all knew exactly what we were dealing with. It was really important that we all understood the problem the same way.

Me: Let's start today's workshop by discussing a concern that many of you have brought up during our recent retrospectives - frequent interruptions during your work hours. We're here to understand it better. Can someone start by sharing their experiences?

Jack (Developer): I have been facing constant interruptions due to urgent emails that require my immediate attention. These emails mostly ask for some clarification about the code I'm working on or some feature functionality.

Me: Thanks for sharing that, Jack. When do these interruptions mostly happen?

Jack: It's pretty random, but mostly when I'm deeply involved in coding tasks, which is quite frustrating as it breaks my flow.

Lisa (Designer): I can relate to that. I don't get as many emails as Jack, but I frequently get pulled into ad hoc meetings, which often disrupt my work.

Me: Thanks for sharing, Lisa. When these ad hoc meetings happen, are they typically about ongoing work or something else?

Lisa: They're usually about ongoing work or about immediate changes requested by stakeholders.

Me: I see. It seems like these interruptions - whether they're urgent emails for Jack or ad hoc meetings for Lisa - tend to be related to immediate needs or clarifications about ongoing work. Does anyone else have similar experiences or different types of interruptions they face?

I continued to facilitate this discussion, allowing all team members to share their experiences. I made sure that everyone's input was heard and that a clear, common understanding of the problem was achieved. By the end of this step, the team and I had a concrete idea of the different ways interruptions occur and how they impact the team's workflow. This clarity was vital for identifying the root cause in the next step.

2. Identify the root cause

We used 5-Whys to discover the root cause:

Me: Now that we have heard everyone's experiences, let's try to dig a little deeper and identify the root cause of these interruptions. We will use the "5 Whys" technique for this.

Me: Why is Jack frequently interrupted by urgent emails?

Jack: I'm getting a lot of questions about the code and features I'm working on.

Me: Interesting. Why do you think you are getting these questions, Jack?

Jack: Well, I guess it's because the information isn't easily available to others, and since I'm working on these features, they turn to me for quick answers.

Me: Great insight, Jack. Why isn't the information easily accessible to others?

Team (in general): We do have documentation, but it's spread out over multiple places - Confluence, Jira, and Google Docs. It can be difficult to know where to find what you're looking for.

Me: So why is our information spread out and not centralized?

Lisa: We never really decided on a single place to store all our information. It's more of an ad-hoc decision based on the type of information or personal preference.

Me: And why have we not decided on a centralized location for all our information?

Team (in general): It's something we overlooked. We've been so focused on our tasks that we didn't fully consider the impact of not having a centralized information source.

In this case, the root cause appeared to be the lack of a centralized and accessible source of information. This caused team members and or stakeholders to interrupt the members of the team to find the information they needed, leading to disrupted workflows and decreased productivity. The next steps would involve rephrasing the problem, structuring it, and brainstorming potential solutions, keeping this root cause in mind.

3. Rephrase the problem

Based on our identified root cause," lack of a centralized and accessible source of information" we rephrased the problem to identify different angles and perspectives.

To simplify the rephrasing of the problem, I designed a simple template that the team could use to speed up things.

Template: X (who) is impeded by Y (what) due to Z (why)

We rephrased the problem using the components X, Y and Z: the Who, the What, and the Why. The objective here was to expand our understanding of the problem by looking at it from various angles.

1. Team perspective (Change in "Who")

   • Original: "Our team is frequently interrupted due to the lack of a centralized and accessible source of information."

   • Rephrased: "Our designers and developers are losing significant work hours because they have to hunt down scattered project information."

2. Productivity perspective (Change in "What")

   • Original: "Our team is frequently interrupted due to the lack of a centralized and accessible source of information."

   • Rephrased: "Our team's productivity is severely affected due to the time spent searching for project information in multiple places."

3. Information management perspective (Change in "Why")

   • Original: "Our team is frequently interrupted due to the lack of a centralized and accessible source of information."

   • Rephrased: "Our team's workflow is frequently disrupted due to inefficient information management practices."

These rephrased problems, while addressing the same core issue, highlighted different aspects of the problem.

1. The team perspective emphasized the impact on different roles,

2. The productivity perspective underscored the impact on work efficiency, and

3. The information management perspective focused on the underlying system causing the problem.

Each of these perspectives could have led the team to consider different aspects of the problem and helped in generating a broader range of potential solutions.

4. Create the structure

With our rephrased problem statements, we then structured the issue using a table. This helped us understand all the contributing factors to our main problem: "The team's workflow is frequently disrupted due to inefficient information management practices."

This structure highlighted the different types of information challenges, their frequency, and their impact on individual team members and their tasks. It also gave insight into potential root causes, which were beneficial in the next steps, where we brainstormed, evaluated, and recommended potential solutions.

5. List potential solutions

The team then brainstormed potential solutions:

Me: I'd like to re-emphasize that we're in a brainstorming session, and I encourage everyone to think freely and propose any solution that comes to mind. No idea is too outlandish at this stage.

Jack: I think a good start would be to have a designated "Knowledge Manager" role within our team. This person would be responsible for organizing and maintaining our information resources.

Me: That's an interesting idea, Jack. Having a dedicated role could ensure that our information management gets the focused attention it needs. What else?

Lisa: Can we consider implementing a ticketing system for information requests? This way, instead of immediate interruptions, we can address questions in a more organized manner.

Me: Good point, Lisa. That could minimize interruptions and ensure that questions don't go unanswered. Any other ideas?

Sam: What if we set up a FAQ or a knowledge base where common queries can be addressed? That might cut down on repetitive questions.

Me: Excellent, Sam. A self-serve resource like a FAQ could save a lot of time. More ideas?

Amy: I suggest we include a short training session on effective information management in our onboarding process for new team members.

Me: That's a proactive approach, Amy. Ensuring everyone starts off with good information habits could prevent issues down the line.

After a sufficient amount of brainstorming, I wrapped up and summarized the proposed solutions as follows:

1. Adopt a single, unified platform for all documentation.

2. Establish clear guidelines for storing information, including naming conventions, tagging, and logical folder structure.

3. Perform a regular audit of the documentation, possibly as part of the sprint review.

4. Conduct training sessions on the new platform and the documentation process.

5. Create a designated "Knowledge Manager" role for organizing and maintaining information resources.

6. Implement a ticketing system for information requests to minimize immediate interruptions.

7. Set up a FAQ or knowledge base for common queries.

8. Include a short training session on effective information management in the onboarding process.

We then proceeded to evaluate these solutions in the next step.

6. Evaluate the potential solutions for feasibility

At this stage, we looked at each potential solution we brainstormed and considered the pros and cons, the feasibility, and the potential impact of each. This evaluation helped in selecting the most promising solution/s to move forward with.

After the team completed this evaluation, they discussed the results and selected the solution/s that was most feasible and had the highest potential impact. It's important to note that the solutions were not mutually exclusive. The team could select a combination of solutions to implement.

To select potential solutions the team quantified each suggestion using the Fist of 5 scoring method as followed:

So, based on this analysis,

1. adopting a unified platform,

2. establishing information storage guidelines,

3. conducting training sessions, and

4. setting up a FAQ or knowledge base

were the top solutions.

The next step for the team was to plan the implementation of these solutions.

7. Plan the implementation

The team then developed a concise plan with actionable steps that they implemented over the next 8 weeks as part of their ongoing sprints. Each cell was treated as a User Story and included as part of the Sprint backlog.

It's important to note that these solutions were not set in stone. After implementation, the team continued to monitor their effectiveness and made adjustments as necessary.

---

Things to consider

1. Participants: Invite whoever is needed to make the decision. For this meeting, I invited the Scrum Team, Product Owner, and all relevant stakeholders. Also since I was training other Agile Coaches they were invited as the silent audience.

2. Duration: 2 hours (depending on the complexity of the issue and the size of the team)

---

This is it 🙏

If you have any questions (related to this topic), don’t forget to use the comments section to ask the community. I will try my best to get you an answer.

---

🙋🏻‍♂️ Your Questions!

If you want me to answer your questions in this newsletter, please send them my way using this link - Send me your questions.

If you’re finding this newsletter valuable, consider sharing it with friends or subscribing if you aren’t already.

---

Till next week!

Sincerely,

Vibhor 👋

P.S. Let me know what you think! Is this useful? What could be better? I promise you won’t hurt my feelings. This is an experiment, and I need feedback. You can reply to this email to send your message directly to my inbox.

---

“I share things I wish I knew in the starting years of my career in the corporate world"

Vibhor Chandel