What To Do When - Your Team Ignores Your Suggestions?

Engineering Manager is Part of Your Scrum team and the team does what their manager says and ignores your suggestions.

👋 Hello, I’m Vibhor, and welcome to the 🔒 monthly free edition 🔒 of my weekly Q&A Series powered by Winning Strategy. Every week, I answer one reader question and publish 2 posts about Agile Products, Role-Based Skills, and anything else that you need answered about your Career Growth. You can send me your questions here.

If you are new, here’s what you’ve missed last month:

1. Unlock User Needs With This User Story Template

2. What to Share and What to Hide from Stakeholders During Sprint Review?

3. 13 Techniques to Handle Difficult Situations During Meetings with Ease

4. Working Agreement for a Scrum Team

5. Why Your Team Doesn't Actively Participate in Retrospectives?

On to this week’s question!

---

Q: During sprint planning, before a sprint is started, should the team have all the work for the sprint in the sprint backlog, or can they move in work from the Product backlog as and when they wrap up work? I have been seeing this pattern where the scrum team doesn't bring in all their work at the start of the sprint. Is there a process to help coach teams on this? I can pull the burndown chart/velocity chart to show them that their SPs at the start of the sprint and end of the sprint almost doubled. Can you please help with a process to get out of this loop? This is causing them to have so much planning on a daily basis and additional backlog grooming sessions. This team is very resistant, provided they have an eng manager working as a QA who neglects any suggestions given and is always speaking the most and making all the decisions for the team.

Thank you for the question.

Your Concern:

1. The team is picking less work for Sprints than their capacity can handle

2. This disrupts their flow. Why?

   1. because they have to pick more work mid-sprint

   2. this work is not refined

   3. so sprint time is wasted making these user stories ready

Your Question:

1. Is it normal to pick work mid-sprint?

2. How to coach (help) the team pick the right amount of work every sprint?

Your Context:

1. The team is resistant to your suggestions. Why?

2. Because their manager is part of the team and controls how the team does stuff.

General Analysis:

1. You are on the right track, but you are asking the wrong question. (I’ll explain why I say that in a moment)

2. Root of the problem lies in the above “context”

Now, before I jump into explaining how to handle the situation, I want to take this opportunity to emphasize the importance of asking the right question.

Over the years, while working with numerous professionals, I have found that most people fail to take advantage of the advice they are given because they do not ask the right questions.

To help people ask the right questions, I developed the PRI Resolution Model as described below.

So let's begin by understanding this model and using it to “ask the right question” that will yield the appropriate solution to the issue you are facing.

Let’s get started.

---

The Process Related Issue (PRI) Resolution Model

Whenever you encounter a “process” related issue (PRI), put it through the following flow:

Step 1. Is this an “issue” because:

• you think the team’s process doesn’t match with the “scrum guide?” or

• your team’s “productivity” is at stake?

Step 2. If your answer is “scrum guide,” then:

1. observe what’s going on

2. keep a watch on your team (no fixing is required yet)

3. if you can coach them out of it (without force) — do it!

4. if not — keep watching

5. the moment this “scrum guide” issue turns into a “productivity” issue (in most cases, it will), treat it as a “productivity” issue and follow the instructions below

Step 3. If your answer is “productivity,” then:

1. Use the options below (in order) to find the root cause:

   Note: The root cause is never “scrum guide is not followed.” If this is the case, ask, “Why scrum guide is not followed?”

   1. Ask yourself the 5 whys (works most of the time). If this doesn’t work, then,

   2. Talk to the Product Owner. If this doesn’t work, then,

   3. Talk to the team (in retrospective). If this doesn’t work, then,

   4. Talk to the team (in 1:1s)

2. Once you have the root cause, check if it can be fixed by training or coaching:

   1. If you think it can be fixed by coaching/training, give it a shot

   2. If this doesn’t work or if it can’t be fixed by coaching/training, then continue below

3. If the root cause can not be fixed:

   1. Identify “visible” negative effects on the team caused by the root cause

      Note: Don’t make any assumptions. Pick the ones that are “visible.”

   2. Try fixing each of these negative effects individually

Examples of Scrum Guide PRIs

1. Team skips Daily Scrum (a few times every month), but their coordination stays effective

2. No Definition of Done, but their work quality is high and consistent

3. Team skips Sprint Reviews, but stakeholders are still satisfied with progress

4. Team skips Sprint Retrospectives but continuously improves its process

5. Product Backlog is not well maintained, but the team still knows what to work on

6. Team doesn’t deliver every sprint but meets their project goals

Examples of Productivity PRIs

1. Lack of user story prioritization leads to wasted effort

2. Scope creep results in missed deadlines

3. Lack of collaboration leads to duplicated efforts

4. Technical debt slows down development

5. Lack of DoD leads to low-quality work

6. Lack of value delivery every sprint is questioned by stakeholders

Let’s apply this model to the issue at hand.

---

Issue — “Team is picking less work for Sprints”

Let's apply the PRI Resolution flow model to the issue

Step 1. Identify if this is an “issue” because:

• You think your team’s process doesn’t match with the “scrum guide”?

• Your team’s “productivity” is at stake?

Answer: This issue seems to fall under both categories:

• It doesn't fully match the Scrum Guide since the team is not completing all planning at the start of the Sprint

• The team's productivity is at stake because they are not effectively planning their work, causing mid-sprint disruptions

We will skip Step 2 and move straight to Step 3 since it is a “Productivity” issue.

Step 3-1: Identify the root cause

Using the 5 Whys, you can easily identify the root cause.

In our case, the 4th and the 5th why are most likely to be similar to the:

Context (provided above):

1. The team is resistant to your suggestions. Why?

2. Because their manager is part of the team and controls how the team does stuff.

Step 3-2: Check if the root cause is fixable:

1. If you think it can be fixed by coaching/training, give it a shot

2. If this doesn’t work or if it can’t be fixed by coaching/training, then continue below

In most cases, fixing “this particular” root cause: “manager is part of the team and controls how the team does stuff” is not an option.

Nevertheless, you might have some questions like:

• Can’t we do anything to fix the situation?

• How can you coach the team?

• Is there an alternative way to fix the situation indirectly?

• What are your options?

All of these questions are answered in the last section of the post.

Step 3-3: If the root cause can not be fixed (due to any reason):

1. Identify the “visible” negative effects on the team due to the root cause

2. Tackle each of these negative effects individually

Presence of a team manager in a scrum team “may” lead to the following “negative effects”:

1. Lack of shared decision-making

2. Limited opportunities for team members to learn

3. Reduced transparency as the engineering manager may not effectively communicate or escalate issues

4. Lack of accountability and shared responsibility

5. Lack of proper Sprint Planning leads to the team doing extra work (planning, refinement, etc) mid-sprint

Note: DO NOT assume a negative effect. Pick the ones that are “visible” in the team.

The negative effect you identified:

“Lack of proper Sprint Planning leads to the team doing extra work (planning, refinement, etc.) mid-sprint”

You’re focusing on fixing one of the “negative effects” of an unfixable root cause, which is the right thing to do.

“When you can’t change the situation cut your losses by focusing on and eliminating the individual negative effects of the situations.”

With the right negative effect identified, let’s answer the 2 related questions you’ve asked and hopefully find the “right question” along the way.

---

Q1: Is it normal to pick work mid-sprint?

The short answer is NO!

This isn’t normal, but it is “occasionally allowed.”

Sometimes teams underestimate their capacity and pick additional work from the product backlog to fully utilize their time and be more productive.

Having said that, using this as an excuse to:

• skip proper Sprint Planning

• ignore the team’s capacity, and

• waste time picking and refining additional stories mid-sprint

on a regular basis is certainly not acceptable.

---

Q2: How to help the team pick the right amount of work at the start of the sprint?

Let’s see if this is the right question to ask.

The negative effect that you’ve highlighted in your ask is:

“Lack of proper Sprint Planning leads to the team doing extra work (planning, refinement, etc.) mid-sprint”

So the problem “is not” that the team is picking work “mid-sprint.”

The problem is that the team is picking “unrefined,” “unplanned,” and “not ready” work, which requires “planning” and “refinement.” This mid-sprint “planning” and “refinement” of user stories for the ongoing sprint is unnecessarily consuming your team’s time.

User story refinement for the upcoming sprints is normal. Refining stories for the ongoing sprint isn’t.

The right question therefore is:

Q: How can we help the team avoid “planning” and “refinement” while picking work for the ongoing sprint?

And the answer is simple and straightforward.

A: By making sure they focus on refining as many additional user stories as possible during their existing refinement sessions.

This may require the team to prioritize refinement and put in extra work to break out of the current loop. The goal should be to have 2-3 sprints' worth of extra refined user stories. Once the user stories are "ready," the team can pick them up anytime (even mid-sprints) without needing to spend time on planning and refinement.

Another question you may ask is:

Q: The team refuses to refine extra user stories. How can we determine how many user stories to refine?

A: The best way to determine this is through StoryMaps.

Why does this work?

A storymap visualizes not only the logical order of user stories but also helps determine how many user stories will result in a “valuable” increment. Seeing this in plain sight, “most teams” can’t resist refining the required user stories.

To learn more about how storymaps can help, please watch the video below.

To summarize the answer:

1. Prioritize refinement for next 1-2 sprints

2. Refine 1-2 sprints worth of extra user stories. To motivate them:

   1. Help your team create a storymap

   2. Help them mark valuable increments in the storymap

3. Then let them pick work however they want

This answers your question.

---

When Eng. Manager is Part of the Scrum Team

Let’s answer a few questions related to this particular situation.

Q1: What can you do to fix the situation?

Situation 1: Eng. Manager is part of the team.

Fix: Remove the manager.

Possibility: Unless you have a strong rapport with the Senior Stakeholders/Management who trust your opinion, the likelihood of influencing this is almost "zero."

Situation 2: The team listens to the Eng. Manager and the Eng. Manager ignores your suggestions.

Fix: Eng. Manager considers your suggestions

Possibility:

1. Not possible if you try to educate them on good Agile manners

2. If your Product Owner or a Senior Developer is an Agile Champion, then it is possible to make your Engineering Manager take your suggestions seriously by applying the technique called “Amplification”

What is Amplification?

Amplification is a meeting strategy in which you, as a Scrum Master, can use the support of your “champion” to reinforce and repeat your ideas and suggestions during meetings and discussions.

This strategy was created and implemented by Valerie Jarrett and Susan Rice from the Obama administration.

When President Obama took office, two-thirds of his top aides were men. Women complained of having to elbow their way into important meetings. And when they got in, their voices were sometimes ignored.

So female staffers adopted a meeting strategy they called “amplification”: When a woman made a key point, other women would repeat it, giving credit to its author. This forced the men in the room to recognize the contribution — and denied them the chance to claim the idea as their own.

“We just started doing it, and made a purpose of doing it. It was an everyday thing,” said one former Obama aide who requested anonymity to speak frankly. Obama noticed, she and others said, and began calling more often on women and junior aides.

Check out the full article here.

Q2: How can you coach the team to listen to you?

Can you even coach the team on this?

Think about it.

Would you listen to your boss, whom you are accountable to, or would you listen to a coach who is not accountable for anything?

No matter how hard you try, the team will listen to the person who controls their paychecks.

Having said that, if you really want to give it a shot, do this:

1. Meet the individual team members 1:1

2. Ask them if they see this (the presence of their manager in the team) as a problem

3. If they don’t then:

   1. record their why and keep observing for “productivity” glitches

4. If they do, then:

   1. prepare your case with the collected feedback

   2. meet with the Engineering Manager 1:1

   3. understand their why

   4. explain your case with examples of “productivity” glitches

   5. deliver the team’s feedback (have a discussion)

5. Accept what happens next

6. If the situation persists and the team still ignores you, then work on identifying the “negative effects” of the root cause as described above

Q3: Is there an alternative way to fix the situation indirectly?

Yes. Through Amplification (discussed above).

Q4: What are your options?

You have the following options:

1. Try Amplification

2. Try 1:1s and delivering feedback

3. Identify the “negative effects” of the root cause

4. Cut your losses by handling each “negative effect” individually

5. Use the existing refinement session to refine a few extra user stories

6. Use Storymap to motivate the team to refine extra user stories.

---

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 find this newsletter valuable, consider sharing it with friends or subscribing if you haven’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