什么是敏捷与精英的团队_为什么（一些）敏捷团队失败

什么是敏捷与精英的团队

在过去的一年中，我与人们进行了很多对话，这些对话似乎总是围绕着两个问题进行的（这让我沮丧不已，并因此而眼花quin乱）：

• 您要在公司敏捷哪里去？
• 您为公司提供什么样的标准化（和/或框架）？

在回答这些问题之前，让我们从一个故事开始。 当我在2006年第一次练习敏捷时，我被要求记录我们的Scrum流程，以便团队在进入下一个项目之前最好地了解它对结束或“发布”的项目是如何工作的。 我们想出了一个看起来像这样的视觉效果：

回顾这段经历，对我来说标准化流程是非常有意义的。 我们是一个很小的团队，我们创建的文档对我们团队来说是有用的。 十二年后，我的观点发生了变化，我认为这样的文档充其量是矛盾或中立的。 最糟糕的是，它们通常被用作解决团队问题的圣杯。 危险始终在于如何使用信息。

“看看这里-这个团队似乎做得很好，我们应该照搬他们正在做的事情！”

团队之所以不同，是因为它们由处于不同情况的不同人员组成。 可以在团队之间轻松共享某些实践，但是以我的经验，尝试标准化流程实际上是行不通的，并且会给团队增加不必要的开销。 更糟糕的是，行业认证的引入过分强调了敏捷性是唯一重要的思想，而不是团队进行实验并共同学习对他们有用的思想。 这与我们在获取团队指标并在不了解其意图和目的的情况下使用它们时面临着同样的危险。

“这支队伍可以冲刺完成60个故事点，但是这支队伍只能冲刺40个故事。显然，这是有问题的。”

是的，这是有问题的，但实际上可能是“跳入结论”。 比较一个团队可以做什么与另一个团队可以做什么是在最坏情况下敏捷的一种捷径管理方法。 这既是对自组织背后的意图缺乏了解，又是团队不断改进的一种征兆，同时也表明敏捷行业已花费大量时间专注于小型工程团队的绩效。 解决组织其余部分如何完成工作的艰苦工作在很大程度上尚未完成。

因此，当面对以下问题时： 您为公司提供什么样的标准化（和/或框架）？ 基于以下陈述，我的观点始终是首要的：

不要做对另一支球队有用的事情。 做适合您的团队的事情 。

还有一个更棘手的问题： 您的公司要敏捷地去哪里？ 我的回答有点怪异，但这是一个诚实的回答。 如果我们不遵守敏捷在2001年要求我们关注的基本真理，我们将无处可走：在团队中建立信任和透明度，使他们能够共同努力，在安全开放的环境中加快学习速度。 如果我们希望在不首先努力理解为什么和需要什么的情况下将流程推向其他人，我们将无处可走。

看到上面的图片后，人们可能会想，“先把那只猫从路由器上拿开，然后使其过热”，而无需首先问到“那只猫为什么坐在那里？”。 我可以通过移走猫来解决问题，或者，我可以在冬天为猫提供加热的床，从而消除问题，这样他的后腿关节炎在寒冷时不会感到那么糟糕。

3个团队滑轨

我确定您此时正在思考，“好吧，Jen，这并不能真正解决我们首先提出问题的原因。” 与我讨论过敏捷问题的很多人都经常被现状所困，例如这只猫。 我知道，我也有这种感觉。 有时候，我还是这样做。 为了解决这个问题，我要求与我合作的团队遵循一些指导方针，并且我主张其他团队也应遵循这些做法。

跟踪并共享您的工作，以便组织中的其他人可以了解您的工作。

这里的关键不是您正在跟踪工作（尽管这是额外的收获！），而是您之外的其他人可以理解您为什么进行工作。 如果您无法将客户价值传达给与细节无关的人，您是否真的了解它？ 此外，能够凭经验解释您将如何衡量完成的工作的影响具有重要价值。 这遵循以下简单的用户故事格式： 作为客户 ，我需要此功能 ，以便可以实现此结果 。 接下来是： 我们知道我们将通过这些定性和定量测量结果来提供此结果。

“从头开始”这句话有道理。

不断改进个人和团队的实践。

这包括团队和产品完成工作的过程以及您的工作职能。 如果您是工程师，请学习有关编码的新知识并进行实践 。 如果您是项目经理，请尝试一种新的便利化技术。 流程不仅指您如何在跟踪系统中四处移动卡片。 确保您正在与团队就无法解决的问题进行公开交谈，无论是与人员流程还是技术流程有关。 没有这种承诺，流程和技术将变得过时。

也许我们在这个领域可以做的最好的事情就是同意与整个组织定期共享我们如何不断努力改进以及用于证明这一点的度量标准。

注意：如果您来找我，但令人毛骨悚然地承认您的团队已停止单口站立，因为团队看不到花费时间的价值， 并且整个团队都在需要时为您的客户提供了可衡量的清晰价值，请不要没想到我会难过。 我可能会问一些问题，向您表示祝贺，并鼓励您继续就有效的方法进行良好的对话。

最后，如果您的工作跨越团队，社区或产品边界，请在冲突发生之前达成共识。

我不是在谈论实施技术的细节。 我正在谈论定义每个人在工作中的角色，定义在哪里进行对话，以及定义需求如何在团队之间来回传递—在工作开始之前建立尽可能多的和谐，您会发现自己彼此依赖一起共享空间，而不会吵架。 随着技术的持续快速创新，具有大量跨职能依赖性的团队将发现问题将进一步恶化。 在我看来，这是项目失败的唯一最大原因。 这是最需要标准化的地方，因为没有标准化，很难实现自动化。

做正确的事

最后，我想再次强调以下声明： 不要做对其他团队有用的事情。 做适合您团队的事情。 我在职业生涯中听到的每一个失败的敏捷采用故事都是建立在未能遵循该咒语之上的。 我鼓励每个人都接受这个想法，并在团队需要时寻求当地敏捷专家的帮助。

最后，当遇到“您必须这样做，因为某某东西对他们有用……”时，请回头看我在上面定义的导轨。 大多数团队之所以处于这一位置，是因为他们被认为没有分享他们做某事的原因，他们没有不断改善他们的流程，也没有确保在日常冲突最小的情况下处理依赖于依赖项的工作。 我对处于那个领域的团队采取行动的呼吁是考虑为什么他们处于那个位置，以及他们应该怎么做才能摆脱这种看法。

对于我的同事，技术人员和敏捷专家来说，最重要的是：如果您不同意我分享的内容，则可以做我的猫所做的事情……或者您可以分享对您的团队有用的内容。

翻译自: https://opensource.com/article/18/6/agile-vision-consider

什么是敏捷与精英的团队