Who is reponsible when the team doesn't implement the Scrum Master's ideas for continuous improvement?

Question

I am working as a Scrum Master. With an intention on continuous improvement I am coming up with ideas in order to deliver better software. I realized that the team is not making enough progress from an improvement perspective even though the ideas are small to implement. Not sure if this is a process issue or the team's incompetence.

I want to make the improvements happen. An example of continuous improvement could be implementing automation, implementing TDD, embracing tools like SONAR for measuring code quality etc. If the team is not implementing the ideas, who should take the responsibility (in a positive sense; NOT complaining): the Scrum Master or the Development Team?

Answer 1

TL;DR

Based on your question, it seems likely that you are practicing command-and-control project management rather than functioning as a coach or process referee within the Scrum framework. You should fully embrace the principles of the Agile Manifesto and empower your team to find their own solutions within the twin constraints of the Sprint Goal and the Definition of Done.

Command-and-Control Isn't Agile

I am coming up with ideas in order to deliver better software...I realized that the team is not making enough progress from improvement perspective even though the ideas are small to implement.

These statements are an indication of Scrum gone wrong. Agile frameworks like Scrum are based on self-directed teams, not top-down management directives. As a member of the Scrum Team, the Scrum Master may certainly propose improvements during the Sprint Retrospectives, but it is up to the team as a whole to determine how to optimize its processes.

In addition, you seem to be trying to hold the team accountable for "improvements" that they have not agreed to, presumably have not estimated for level of effort, and for which you have not defined any objective metrics. Specifically:

1. Who says the ideas are "small to implement?"

   In Scrum, stories, tasks, and processes must always be estimated by the task performers (e.g. the Development Team) rather than decreed from on high. Just because you believe a process change is simple or lightweight doesn't make it so; only the task performers are in a position to judge.

2. Who says they haven't made "enough progress?"

   What problems are you trying to solve? How are you measuring progress? Are you measuring internal processes or deliverable outcomes? Unless you have clearly identified a process problem, and clearly defined a set of objective metrics to measure outcomes, you're practicing voodoo management.

   In addition, measuring adherence to a process is almost always a mistake; in Scrum, you want to measure value delivered rather than the process for delivering that value. In other words, focus on "Does the sausage taste good?" instead of on how the sausage gets made.

3. Why isn't the team empowered and engaged in finding its own solutions?

   Scrum will not make mediocre teams into superstars. All agile frameworks rely on self-directed engagement by the team members. If your team isn't populated by individuals who are self-starters capable of producing a workman-like product and interested in continuous improvement, then you should probably review your management and hiring practices before spending time on frameworks like Scrum.

   If you already have capable, engaged team members, then the best thing you can do is to empower them to build their own self-organized processes. If you've correctly defined the goals and the constraints, the power of Scrum lies in giving the team leeway to optimize the implementation details internally.

Leverage Retrospectives

If your software has a quality problem, you should review your Sprint Goals, your Scrum processes, and your Definition of Done to ensure that you are providing an adequate framework for success. If you're still falling short, then use your Sprint Retrospectives to ask the team about the problems and to brainstorm solutions that the entire team can get behind.

Answer 2

In order for the team to improve, they will need:

• Clear goals, and a plan on how to get there. What's the desired outcome of the improvement?
• Resources. Do they have the time to learn new skills? The proper software to implement new ways of coding?
• Motivation. Are the ideas for improvements coming from the team, or from management?

If the team doesn't know what to do, or don't have the time to actually do it, or simply don't see the improvement as necessary, nothing will happen.

Answer 3

Let's start with your last question. The role of the scrum master according to the Scrum Guide is:

The Scrum Master is responsible for ensuring Scrum is understood and enacted.

If no retrospectives were occurring, maybe the responsibility for that would fall to you, but it sounds like they are but you're not sure the team is getting the most out of them.

During the retrospective, the team should be identifying challenges that made it harder to meet their goals. After that, you should encourage the team to propose possible solutions to those challenges or at least improve in those areas.

Assuming all this is happening, the next issue would be if their improvement ideas are actually effective. One way I've found to help ensure that is to take a validated learning approach. When you decide to improve something, agree on what actions the team will take, what you expect the effect to be, and how you'll measure if it is working. That way you can show what improvements are helping and which ones aren't. It helps that whole part of Scrum be a little less nebulous.

Answer 4

Coach the team to self-organize and set up Release retrospectives

Your goal of continuous improvement is good. It is certainly the Scrum Master's responsibility to look for ways to improve the process.

@CodeGnome suggested some steps if your team is not self-organizing. In addition, you can influence and coach the team to get there. Read Mike Cohn's recommendations on this topic:

Many would-be ScrumMasters and agile coaches go to the extreme of refusing to exert any influence on their teams at all. Others retain too much of their prior command-and-control management styles and fail to unleash the creativity and productivity of a self-organizing team. Many want to understand how to walk the fine line of leading a self-organizing team with agile project management.

Self-organizing is about the team determining how they will respond to their environment (and managers/leads can influenze that environment).

As you see the team self-organize you can influence, but not control or direct, its path.

In addition to Sprint retrospectives, you should also organize Release retrospectives. You can gather the data and set the agenda for these so that the team can come up with suitable solutions. See more about it in this article:

Sprint retrospectives are the right place for developing action plans consisting of small, tactical improvements that can be implemented in the next sprint.

A release cycle is typically be 3 to 6 months long...At the end of a release cycle, a release retrospective should focus on strategic objectives that drive the agile transition of an enterprise.