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.
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.)
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.
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:
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.
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.
引用 Schwaber 和 Beetle 的书《Agile Software Development with Scrum》，“当团队演示产品增量时，它可以帮助与会者了解产品增量的弱点和优点，以及将其整合在一起所经历的困难和成功......每个人应该了解产品增量，因为这是他们在冲刺计划会议上需要的知识。”
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.
发布评论
评论（6）
Sprint 回顾和 Sprint 评审是两个不同的事情，不应混淆。
冲刺审查适用于所有参与者，尤其是利益相关者，以检查项目的进展情况并讨论如何根据需要进行调整。冲刺评审围绕上一个冲刺中产生的“可交付产品增量”展开，而不是它是如何产生的。
如果产品负责人“代表”利益相关者，那就更好了，但如果他们能够看到自己完成了什么、运行了什么等，那就更好了。所以我想说，如果他们想参加冲刺评审，欢迎各种管理人员，但要至少要小心地告诉他们这次会议是什么以及他们的角色是什么。我想说，教育他们主要是PO的工作，SM可以协助他。
Sprint 回顾主要是让团队检查他们上一次的 sprint，重点关注做了什么，而更多地关注如何完成。如果 PO 想要加入的话，我不会包括任何人。您的反对意见是，团队可能不愿意在管理层面前谈论他们的脏衣服，这是非常有道理的 - 但从管理层的角度来看，这将是浪费时间，例如，听开发人员讨论如何改进代码存储库中的分支。即使管理层知道团队到底在谈论什么，他们也不应该在这件事上浪费时间——他们有更大的蓝图需要管理。
话虽如此，对项目或项目的较长部分（例如一个季度或半年）进行整体回顾（包括管理层）可能是有意义的，但不一定包括所有团队成员（如果您有很多团队，这是不可能的）并且会专注于“大局”。
说到书籍 - 一定要买“敏捷回顾”。那里没什么可读的——它只是一本很棒的食谱，其中包含了根据您有多少时间以及回顾的内容在回顾的不同阶段使用的各种技巧。非常有帮助，因为经典的“我们哪些做得好？哪些做得不好？”等等很快就会变得无聊。
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.
每次复古之前我都会进行安全检查。安全检查应尽可能匿名——通常是相同大小的便利贴、相同的记号笔——我要求提供 1 到 5 之间的数字，其中 5 是“谈论任何事情”，1 是“坐下来，点头微笑”。
如果安全检查结果很高（大多是 4 秒或 5 秒），我会继续进行回顾。如果结果很低，我会要求管理或领导职位的任何人离开，然后再次运行。如果结果仍然较低，我会集中精力回顾安全性以表达想法（是什么阻止我们分享我们的想法？什么对我们有帮助？）
否则我会在没有领导的情况下进行回顾，然后单独举行一次回顾与领导层进行会议，询问他们可以采取哪些措施来使团队更安全地表达他们的想法。
如果只有一个 1 或 2，那么我要求团队尊重某些人感到不安全，互相尊重，并考虑他们可以做些什么来提高人们在团队内表达想法的能力。然后我无论如何都会运行复古。
有一次，我和我的教练同事是房间里唯一的领导者。我们已经培训了另一名团队成员进行回顾，所以我们离开房间并让他在没有我们的情况下进行回顾的安全检查。安全检查显示，没有我们，他们感觉更安全，所以我们退出了。从那个人那里得到了一些很好的反馈！ （如果领导者坚持坐在不安全的倒车中，我通常会讲这个故事。）
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.)
我认为这很大程度上取决于你的团队。如果您确实认为如果管理层在场，他们会避免或隐藏问题，请要求管理层不要参加，然后向他们发送稍后讨论的要点摘要。
另一方面，如果您的团队对管理层持开放态度感到足够满意，那么您也可以将他们引入：他们甚至可能为审核提供积极的贡献。
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.
您使用什么格式进行回顾？如果它是非结构化的，那么人们可能无法随意与在场的西装革履者交谈。你也不希望它变成一场恶作剧。
我喜欢 James Shore 在这里描述的静音映射技术：
http://jamesshore.com/Agile- Book/retrospectives.html
我发现它可以将问题写在白板上，而不必担心遭到报复。我在管理层在场的情况下完成了这项工作，他们发现它提供了非常丰富的信息。它通常有助于获得团队所需的东西。
例如，如果团队压倒性地表示他们需要对故事有一个更清晰的“完成的定义”，那么这通常需要在房间外冒泡，而让管理层第一手看到这一点可以帮助解决这个问题。
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.
请参阅此处的官方 Scrum 指南： http://www .scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit
我的观点是，在某些情况下，如果利益相关者和产品所有者之间的互动有需要改进的地方，那么让利益相关者和产品所有者参与其中是一种资产。团队和他们。
管理层可以通过检查信息辐射器并查看冲刺评审中完成的产品来了解正在发生的情况。
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.
冲刺评审或回顾的目的是向客户、产品所有者和其他相关方展示您所取得的成就。你们应该讨论哪些是正确的，哪些是错误的。如果您的团队无法自由地真正讨论他们的问题，则说明某些事情没有正确完成。这次会议的目的是提供信息，而不是批评或以行动为导向。
引用 Schwaber 和 Beetle 的书《Agile Software Development with Scrum》，“当团队演示产品增量时，它可以帮助与会者了解产品增量的弱点和优点，以及将其整合在一起所经历的困难和成功......每个人应该了解产品增量，因为这是他们在冲刺计划会议上需要的知识。”
换句话说，团队能够让管理层知道他们是否遇到问题非常重要，以便管理层了解需要如何改变下一个冲刺的计划。
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.