If project management or project management comes to a sprint retrospective

Question

Disadvantages: The team will not be free to talk about problems.

Advantages: Project management and management love to know what is happening.

How to do it? Getting conflicting reports here ...

Answer 1

Sprint retrospective and Sprint review are two different things that should not be confused.

The Sprint review is intended for all participants, especially interested parties, to check where the project is and to discuss how to adapt if necessary. The Sprint review revolves around the “delivered product gain” produced in the last sprint, not how it was produced.

It’s good if the owner of the product “represents” the stakeholders, but even better if they can see what has been done, what works, etc. Therefore, I would say that we welcome the management of all kinds if they want to come to a sprint review, but be careful to at least tell them what a meeting is and what their role is. I would say that training them is primarily working with software, SM can help him.

Retrospective Sprint is primarily a team to test their last sprint, focusing less on what was done than on how it was done. I would not turn on anyone other than software if he wants to join them. Your objection to the fact that the team may not have conversations about their dirty laundry in front of the management is very important - but for management’s reasons it would be a waste of time, for example, to listen to developers discussing how to improve branching in their code repository. if management knows what the heck team is saying, this is not what they should spend their time on - they have a bigger picture to manage.

Having said that a general project retrospective or a longer piece (e.g. a quarter or six months) that includes management may make sense, but it will not necessarily include all team members (if you have many teams that would make it impossible) and focus on " big picture. "

Speaking of books, definitely buy Agile Retrospectives . There is not much to read there - it’s just a great cookbook of various methods for use at different stages of a retrospective, based on how much time you have and what a retrospective is. Great help, because the classic is "what did we do well, what didn’t we do well?" etc. getting bored pretty quickly.

Answer 2

I do a security check before every retro. The security check should be as anonymous as possible - as a rule, the same posts with the same size, the same Sharpie pens, and I ask for numbers from 1 to 5, where 5 "talk about everything" and 1 "sit, nod and smile beautifully "

If the security check goes high (mostly 4 seconds or 5 seconds), I go ahead and run a retrospective. If it goes low, I ask someone from the leadership or leadership position to leave, and then start it again. If it still goes low, I focus on security retrospective to express ideas (what prevents us from sharing our ideas? What helps us?)

Otherwise, I start retro without leadership, and then I will have 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 is only one or two, I ask the team to respect what some people feel unsafe, respect each other and believe that they can do to increase people's ability to express ideas within the team. Then I still launch retro.

In one case, my colleague and I were the only leaders in the room. We trained another member of the team to launch a retrograde, so we left the room and forced him to conduct a security check on a retro without us. A security check showed that they felt safer without us, so we bowed. Got great reviews from this! (I usually tell this story if leaders insist on sitting in unsafe flashbacks.)

Answer 3

I think it depends a lot on your team. If you really think that they are avoiding or hiding the problems, if the guide is present, ask the guide not to be present, and then send them a summary of the points that will be discussed below.

On the other hand, if your team is comfortable enough that the leadership is open anyway, you can also bring them: they can even make a positive contribution to the review.

Answer 4

The purpose of a sprint review or retrospective is to present what you have done to your customers, the product owner, and other interested parties. You GIVEN to discuss what went right and what went wrong. If your team cannot talk freely about their problems, something is being done wrong. The meeting is intended to be informational rather than critical or action-oriented.

A quote from the Schwaber and Beetle Agile Software Development book with Scrum: “When a team demonstrates product growth, it helps participants understand the weaknesses and strengths of product increments, as well as the difficulties and successes that they have encountered, bringing them together ... Everyone must get an idea of ​​the product increment because it’s the knowledge they will need for a Sprint planning meeting. "

In other words, it is very important that the team can tell the management whether they have problems, so that the management understands how to change the planning of the next sprint.

Answer 5

What format do you use for retrospective? If it is unstructured, people cannot talk freely with gifts. You also do not want him 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 found that he was raising problems on the board without fear of retaliation. I did this with the presence of leadership, and they find it very informative. This usually helps to get money for what the team needs.

For example, if the team overwhelmingly indicates that they need a clearer “definition of what has been done” in the stories, then this often needs to go outside the room, and management sees that it can help to eliminate it first hand.

Answer 6

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

My opinion is that in some cases, the presence of interested parties and the owner of the product is an advantage if there is something to improve in the interaction between the team and them.

Management can see what happens by checking the information radiator and seeing the product made in sprint reviews.