Should management or project management come to the sprint retrospective

Question

Disadvantages: Team will not feel free to talk about issues.

Advantages: Project management and management like to know what is going on.

How should this be done? Getting conflicting reports here...

Answer 1

I think this largely depends on your team. If you really think they'll avoid or hide issues if management is present, ask management not to attend and then send them a summary of the points discussed later.

On the other hand, if your team is comfortable enough with management to be open anyway, you may as well bring them in: they might even provide a positive contribution to the review.

Answer 2

The purpose of the sprint review or retrospective is to present what you accomplished to your customers, product owner and other interested parties. You are SUPPOSED to discuss what went right and what went wrong. If your team doesn't feel free to actually talk about their issues, something isn't being done correctly. The meeting is intended to be informational, not critical or action-oriented.

Quoting from Schwaber and Beetle's book Agile Software Development with Scrum, "As the team demonstrates the product increment, it helps the attendees understand the weaknesses and strengths of the product increments, and the difficulties and successes it experienced pulling it together.... Everyone should get an understanding of the product increment, as this is the knowledge they will need for the Sprint Planning meeting."

In other words, it's very important that the team is able to let management know if they are having issues, so that management understands how planning for the next sprint needs to change.

Answer 3

What format do you use for your retrospectives? If it's unstructured then people may not feel free to talk with the suits present. You also don't want it to turn into a bitch session.

I like the Mute Mapping technique described by James Shore here:

http://jamesshore.com/Agile-Book/retrospectives.html

I've found that it gets the issues up on the whiteboard without fear of retribution. I've done it with management present and they find it very informative. It usually helps to get buy in for things the team needs.

For example, if the team overwhelmingly indicates that they need a clearer "definition of done" on stories, then that often needs to bubble up outside the room, and having management see that first hand can help get it fixed.

Answer 4

Please refer to the official scrum guide here: http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit

My opinion is that in certain cases, having the stakeholders and product owner involved is an asset if there is something to improve in the interaction between the team and them.

The management can see what's going on by checking the information radiator and seeing product done in the sprint reviews.

Answer 5

Sprint retrospective and Sprint review are two different things that shouldn't be confused.

Sprint review is for everyone involved, especially stakeholders, to inspect where the project is and discuss how to adapt as needed. Sprint review revolves around the "shippable product increment" produced in the last sprint - not how it was produced.

It is good if Product Owner "represents" stakeholders, but it is even better if they can see themselves what was accomplished, what runs etc. So I'd say welcome management of all kinds if they want to come to sprint review, but be careful to at least tell them what that meeting is and what their role is. I'd say that educating them is primarily PO's job, SM may assist him.

Sprint retrospective is primarily for the team to inspect their last sprint, concentrating less on what was done than on how it was done. I wouldn't include anyone besides PO if he/she wants to join in those. Your objection that team may not be comfortable talking about their dirty laundry in front of management is very valid - but also from managements' prospective this would be waste of time to, for example, listen to developers debating how to improve branching in their code repository. Even if the management knew what the heck team is talking about this is not something they should waste their time on - they have bigger picture to manage.

Having said that an overall retrospective on the project or on a longer chunk of it (like a quarter or half year) that would include management may make sense, but it would not necessarily include all team members (if you have many teams that would make it impossible) and would concentrate on "big picture".

Speaking of books - definitely buy "Agile Retrospectives". There is not much to read there - it is just a great cookbook of various techniques to use in different phases of a retrospective based on how much time you have and what is the retrospective about. Great help, since classic "what we did well? what we didn't do wellt?" etc. becomes boring pretty quickly.

Answer 6

I run a safety check before every retro. The safety check should be as anonymous as possible - usually same-sized postits, same Sharpie pens - and I ask for numbers between 1 and 5, where 5 is "talk about anything" and 1 is "sit and nod and smile nicely".

If the safety check comes out high (mostly 4s or 5s), I go ahead and run the retrospective. If it comes out low, I ask anyone in a mangement or leadership position to leave, then run it again. If it still comes out low, I concentrate on retrospecting on safety to express ideas (What stops us from sharing our ideas? What helps us?)

Otherwise I run the retro without the leadership, then hold a separate session with the leadership to ask what they can do to make it safer for the team to express their ideas.

If there's just one 1 or 2 then I ask the team to respect that some people are feeling unsafe, to be respectful to each other, and to consider what they could do to increase people's ability to express ideas within the team. Then I run the retro anyway.

In one case my fellow coach and I were the only leadership people in the room. We had trained another team member to run retros, so we left the room and got him to run the safety check for a retro without us. The safety check showed they felt safer without us, so we bowed out. Got some great feedback from that one! (I usually tell this story if leaders insist on sitting in unsafe retros.)