BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Role of Managers in Agile Retrospectives

by Ben Linders on Apr 10, 2014 |

Agile teams use retrospectives to reflect upon their way of working. Since it’s the team’s own responsibility to continuously improve themselves they have to decide upon the actions that they will do. What can managers do to support their teams when they are doing agile retrospectives?

Len Lagestee wrote the blog post a managers guide to attending agile team events in which he talks about the role of managers in the sprint planning sessions, daily stand-ups, sprint reviews and retrospectives. He explains what makes it different for managers to attend these events:

If you are a manager with direct reports on an Agile team (you are making performance, promotion, or salary and bonus assessments on one or more team members), I believe a set of expected behaviors should apply to you. This is not meant to be exclusionary but your presence, reactions, words, and body language WILL impact team dynamics – sometimes negatively.

Len stated his opinion about how managers should be involved in agile retrospectives:

Don’t attend [sprint retrospectives], ever. The team should be comfortable sharing areas to improve when necessary and when they believe something may come back to haunt them or someone else in a performance review they may not say what should be said. If you are sensing something is not right with the team, setup a different time with your direct report, the team, product owner and/or Scrum Master to discuss your concerns.

In stead of being directly involved in retrospectives, managers can support their teams by become visionary and human as Len described in his blog post two things leaders should be:

As a leader begins to craft and communicate a vision, anticipation begin to build around what the future may bring and a network of teams begins to rally around the vision. This will require breaking away from day-to-day decision making and allowing those closest to the action to make those decisions in real-time.

When leaders and managers are authentically themselves, a connection begins to form between the visionary and those who will work to make the vision a reality. This connection cannot be underrated and will begin to establish the trust necessary for a nimble, networked, and flexible organization to exist. And without the trust of your people, your vision is meaningless.

In the book Agile Retrospectives: Making good teams great Esther Derby and Diana Larsen wrote about a risk they see when managers attend the retrospective:

Managers won’t be in every retrospective, but when they are, they are particularly prone to dominating the conversation. It’s not always their fault—if team members hold back when a manager is in the room (for whatever reason), the manager tends to fill the dead air. Meet with managers before the retrospective. Coach them on appropriate participation. Ask them to let others talk first, acknowledge the contributions others make, and be careful how they disagree.

It can be useful to have managers attending release and project retrospectives say Esther and Diana, where they suggest to coach managers about their involvement in the retrospective prior to the meeting:

Differences in power and status influence interactions within a retrospective. People who have responsibility for evaluating or appraising the performance of team members—functional managers, project managers, directors, development managers—hold a form of power, and people may defer to them. Meet with each manager before the retrospective to consider his or her roles in discussions. Ask each manager to hold back and create signals to help communicate when a manager is being too assertive.

The InfoQ eBook Getting Value out of Agile Retrospectives - A Toolbox of Retrospective Exercises written by the author of this post and Luis Gonçalves says:

Managers should enable and support teams in doing retrospectives. They can ask and expect teams to improve within the possibilities and constraints of the organization, and contribute to the organization’s goals, but it is up to the team to choose how they improve and where they decide not to improve (now). A manager must respect the judgment of his/her employees and rely on the team’s professionalism, trusting them to manage their own journey.

Kristin Runyan wrote a blog post on agile culture: Management and teamwork in which she describes how managers can support agile teams:

Members of management – manager, director, VP, whatever – should present the team with the problem or opportunity and let them ‘self organize’ to determine how they will solve the problem with teamwork.

She explains how adopting agile impacts the role of the manager in agile meetings such as stand-ups and retrospectives, which can initially be uncomfortable for a manager:

One of the hardest things for management in an Agile organization is to truly empower self-organizing teams because – by definition – it means that the manager is not part of the team. That is a hard position to be in. To attend a Stand-Up meeting and not speak is difficult. To have a suggestion for how to solve a problem, and yet be silent so the team can come to their own solution is difficult. To watch the team head off to their retrospective and know that you are not invited is difficult. The effective Agile Manager is the one who can accept the differences in the role, respect the boundaries of the team and allow everyone to grow and learn. When the manager does this, their value to the organization goes up exponentially. They are no longer just a manager divvying out tasks and writing performance reviews – they are now a leader, a builder of talent, a facilitator of progress.  That is something that every organization needs!

In a follow up blog post called agile culture: Impacts to the organization Kristin provides a idea for managers on how to support their teams in using retrospectives to improve themselves:

The next time [the team] come to you with a problem or roadblock, instead of offering a solution, ask questions. “How do you think the team could solve that issue?” ”Have to talked as a group about this situation?” “Did you discuss this in your retrospective?” It will only take one or two instances of you pushing the problem back on the team for them to figure out that they need to solve their own problems and you will support them.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT