您的Scrum团队等待Sprint回顾的5个理由

您的团队抱怨同时召开太多会议和无用的Sprint回顾会议? 是时候站在复古了!

如果您进行了无聊的,无精打采的Sprint回顾会议,而同时又在特别会议和小组中处理了多个相关主题,那么问题可能出在Retro的实施方式上。 但是有时候,对于Retro来说,没有什么好话题了。 这里有一些论点可以帮助您说服队友将他们的主题带入Retro,而不是召开下一次临时会议。

最简单的论据是,通过等待Retro,团队总体上将在会议上花费更少的时间。

您可以通过向团队展示诸如此类的示例性时间表来轻松地解释这一点,其中至少四个主题看起来至少应该在Retro中决定:

可以在Daily Scrum中决定是否将主题移入Retro。

这当然只有在团队更喜欢在Sprint上工作而不是召开大量会议的情况下才有效。 如果不是这种情况,那么您已经有一个相关的Retro主题…

符合此论点的另一种反模式是无限的每日Scrum。 如果定期参加长时间的检查与适应讨论,那么Retro将会遭受重创。

查看上面的示例性时间表,您可以轻松发现另一个问题:如果在下一次Sprint的四次会议和Retro中,团队至少要进行五项不同的改进,该怎么办? 这听起来很现实吗? 绝对不是。 我遇到的一个普通的Scrum团队在一个出色的Sprint中,对他们的工作方式进行了一项明显的改进,也许还做了一些次要的改进。 如果您将其推断为一整年,那已经相当不错了。

《 Scrum指南》中的Jeff Sutherland和Ken Schwaber将Retro称为“一个专注于检查和适应的正式机会”。 我知道,最有经验的Scrum大师也利用这个机会,让团队选择最相关的适应方法,然后做出正确的选择。 他们这样做是因为这增加了团队成功实施这些适应措施的可能性。 反过来,这会加强检查和适应循环。 最后,每种改编都是一个实验,您需要一些时间来检查其结果。

典型的临时问题会议通常不是很包容,并且通常仅由受到问题影响的人员组成。 但是,如果真的应该使用问题来改善团队的工作方式,则整个团队必须决定。 也许必须从一个问题的狭the角度扩大讨论范围。

如果最终证明只有几个团队成员才能最好地解决问题,至少这是一个有意识的决定-然后,团队将制定建议的工作委托给这些团队成员。 当他们回来时,整个团队都会做出决定。 自组织的Scrum团队在这些问题上是基层民主,因此在做出大的适应决策时,全体选民都应出席。

发生问题时召开会议感觉非常精益和敏捷,就像拉起安东绳以停止在丰田装配带上的生产一样。 有时这确实是必要的。 但是,软件开发团队中的情况通常与汽车厂的情况不同。 如果眼前的问题不会使整个Sprint变得毫无意义,那么也许就不应该打断整个团队的宝贵工作。 最好等到尘埃落定,然后在Retro中以平静的方式评估问题的相关性和影响。

仅仅召开一个临时会议会产生很大的机会来应对一次性问题。

解决此问题的一种好方法是先与另一位团队成员讨论(在这里使用配对编程),然后写下“障碍卡”或Retro的类似内容。 或者,如果你们俩都认为这是绝对必要的,请敲响警钟,让所有人员都坐上甲板,进行激烈的临时会议。 通过使用即时回顾格式,这可能会变得不那么引人注目。

如果该问题是有争议的问题,例如人们非常自以为是的技术决策,则最好使用众所周知的会议格式以及所有参与者都知道的决策机制。 如果您有一个不错的主持人,例如Scrum Master,那就更好了。 您应该已经拥有的所有这些:已经安排好的Sprint回顾!

永久的“小适应”流是一个健康的Scrum团队的标志。 例如,这些是即时重构,对Daily迅速达成共识的构建管道的小改进,或者是回归测试套件中引入的新测试用例。 这是一件非常好的事情,不应推迟到Retro之前。 Retro适用于需要讨论和决定的适应方法,以及所有团队成员都应该听到的地方。

除了检查Retro中的已知问题外,它还可以并且还应该用于发现在表面下逐渐恶化的新主题。 如果您收集了Sprint期间遇到的许多已知问题,请确保Retro上还有足够的时间进行此操作!

为Sprint回顾展保留最有趣的讨论应该有更多的理由。 如果您有一个,请留下评论! 可能有人在那里只需要那个论点。