为什么(有些)敏捷团队会失败

关于敏捷团队可能失败的简单解释。
321 位读者喜欢这篇文章。
team meeting

WOCinTech Chat。由 Opensource.com 修改。CC BY-SA 4.0

White cat

在过去的一年里,我与很多人进行了多次对话,这些对话似乎总是围绕着两个问题(令我非常沮丧,并导致我眯着眼睛):

  • 贵公司敏捷的未来方向是什么?
  • 您为公司提供什么样的标准化(和/或框架)?

在回答这些问题之前,让我们先从一个故事开始。当我在 2006 年首次实践敏捷时,我被要求记录我们的 Scrum 流程,以便团队能够更好地理解它如何适用于在移至下一个项目之前有结束或“发布”的项目。我们想出了一个看起来像这样的可视化图表

Agile scrum process chart

回顾这段经历,我发现流程标准化对我来说是完全合理的。我们是一个小团队,我们制作的文档是我们创建时对团队有效的方法。十二年后,我的观点发生了变化,我认为这样的文档充其量是模棱两可或混乱中立的。最糟糕的是,它们经常被用作解决团队问题的圣杯。危险始终在于信息的使用方式。

“看看这里——这个团队似乎做得很好,我们应该直接复制他们正在做的事情!”

团队是不同的,因为它们由不同的人和不同的情况组成。某些实践可以很容易地在团队之间共享,但在我的经验中,试图标准化流程实际上并不可行,并且会给团队增加不必要的开销。更糟糕的是,行业内认证的引入过度强调了敏捷的实施是唯一重要的事情,而不是团队一起试验和学习什么对他们有效。这与我们收集团队指标并在不了解其意图和目的的情况下使用它们所面临的危险相同。

“这个团队在一个 sprint 中可以完成 60 个故事点,而这个团队只完成 40 个。显然,有问题。”

是的,有问题,但实际上可能是“草率下结论”。将一个团队与另一个团队的能力进行比较是一种糟糕的敏捷管理速记方法。这既是对自组织和持续团队改进背后的意图缺乏理解的症状,也表明敏捷行业花费了大量时间关注小型工程团队的绩效。解决组织其余部分如何完成工作的艰苦工作在很大程度上尚未完成。

因此,当面对这个问题:您为公司提供什么样的标准化(和/或框架)? 我的观点始终首先基于以下声明:

不要做对其他团队有效的事情。做对你的团队正确的事情.

Cat sitting on a router

以及更难的问题:贵公司敏捷的未来方向是什么? 我的回答有点含糊其辞,但这是一个诚实的回答。如果我们不忠于 2001 年敏捷要求我们关注的基本真理:在团队中建立信任和透明度,以便他们可以在安全和开放的环境中协同工作以加速学习,那么我们将一事无成。如果我们不首先努力理解为什么和需要什么,就试图将流程强加于他人,那么我们将一事无成。

有人可能会在看到上面的图片后想到,“在路由器过热之前把猫从路由器上抱走”,而不是先问,“猫为什么要坐在那里?” 我可以通过移走猫来解决问题,或者,我可以为猫在冬天提供一个加热床,从而消除问题,这样它的后腿关节炎在寒冷时就不会感觉那么糟糕。

团队的 3 条指导原则

Cat in a laundry basket

我相信你现在正在想,“好吧,Jen,这并没有真正解决我们最初提出这个问题的原因。” 许多与我讨论敏捷主题的人常常感到被现状所困,就像这只猫一样。我理解这一点——我也曾有过这种感觉。有时,我仍然有。为了帮助解决这个问题,我要求我合作的团队遵循一些指导原则,我也提倡其他团队也接受这些实践。

跟踪并分享您的工作,以便组织中的其他人可以理解您正在做什么。

这里的关键不是您正在跟踪工作(虽然这是一个额外的好处!),而是您以外的其他人可以理解您为什么要这样做。如果您无法向不参与细节的人沟通客户价值,您真的自己理解它吗?此外,能够实证地解释您将如何衡量您正在完成的工作的影响,具有重要价值。这遵循简单的用户故事格式:作为客户,我需要这个功能,以便我能够实现这个结果 接下来是:我们知道我们将通过这些定性和定量测量来交付这个结果。

“以终为始”这句话是有道理的。

持续改进您作为个人和团队的实践。

这包括您的团队和产品完成工作所采用的流程以及您的工作职能。如果您是工程师,请学习一些关于编码的新知识并实践它。如果您是项目经理,请尝试您读到的一种新的促进技巧。流程不仅仅是指您如何在跟踪系统中移动卡片。确保您与您的团队公开讨论那些不起作用的事情——无论是与人员流程还是技术流程相关。没有这种承诺,流程和技术将变得陈旧。

也许我们在这个领域能做的最好的事情就是同意就如何持续努力改进以及我们用来证明这一点的指标与整个组织进行例行共享。

注意: 如果你来找我,并且羞怯地承认你的团队已经停止进行站立会议,因为团队没有看到花费时间的价值,并且整个团队在需要时正在为你的客户交付可衡量和清晰的价值,不要指望我会生气。我很可能会问一些问题,祝贺你,并鼓励你继续就什么有效进行良好的对话。

Two cats in a bed

最后,如果您的工作跨越团队、社区或产品边界,请在发生冲突之前就如何进行达成一致。

我不是在谈论实施技术背后的细节。我谈论的是定义每个人在工作中的角色,定义对话发生的地点,以及定义需求如何在团队之间来回传递——在工作开始之前尽可能地建立和谐,并且你们发现自己依赖彼此共享空间——而不会爆发猫 लड़ाई。随着技术继续快速创新,具有繁重的跨职能依赖性的团队将发现问题会恶化。在我看来,这是项目失败的唯一最大原因。这是最需要标准化的领域,因为没有标准化,就很难实现自动化。

做正确的事

White cat with owner

最后,我想再次强调这句话:不要做对其他团队有效的事情。 做对你的团队正确的事情。 我职业生涯中听到的每一个失败的敏捷采用故事都是建立在未能遵循这一原则的基础之上的。我鼓励每个人都接受这个想法,并在团队需要时向您当地的敏捷专家寻求帮助。

最后,当有人以“你必须这样做,因为某某是这样做的,而且对他们有效……”来接近你时,回顾一下我上面定义的指导原则。大多数团队之所以陷入这种境地,是因为他们被认为没有分享他们为什么要做某事,他们没有持续改进他们的流程,也没有确保处理依赖关系繁重的工作时将日常冲突降到最低。我对处于这种境地的团队的行动号召是思考他们为什么会处于这种境地,以及他们应该做些什么来摆脱这种看法。

对我同事、技术专家和敏捷主义者来说最重要的是:如果您不同意我分享的内容,您可以像我的猫一样……或者您可以分享对您的团队有效的方法。

User profile image.
Jen Krieger 是红帽公司的首席敏捷架构师。她在软件开发领域拥有 20 多年的职业生涯,在瀑布和敏捷生命周期中担任过许多角色。在红帽公司,她领导了部门范围的 DevOps 运动,重点是 CI/CD 最佳实践。最近,她与 Project Atomic 和 OpenShift 团队合作。

4 条评论

有时你需要指标只是为了避免追逐非问题。
有什么证据表明猫坐在路由器上会导致路由器过热? 似乎猫已经以节能的方式解决了它的问题。

在互联网上搜索发现路由器通风口被覆盖时过热是多么常见,并不需要花费太多精力。 以我自己的经验——猫坐在上面绝对会导致我们的旧路由器重置并导致服务问题,直到我们重新启动。 ‍♀️

回复 作者 Greg P

Jen,文章写得太棒了!
这是我一直听到的另一个口头禅“如果敏捷对你不起作用,那肯定是你在哪里做错了”。 这句话太不真实了....

我曾在一些公司工作过,他们的 sprint 计划设置为相同的长度,而不管他们正在进行什么项目。

我见过用户故事被纳入 sprint,但没有进行分析,没有详细说明以下内容:
1_ 故事所需的 DB 模式数据
2_ 达到用户故事目标所需的活动
3_ 需要应用的业务规则
4_ 如果需要,进行设计会议
5_ 可重用性分析

如果以上用户故事细节没有实践,那么失败的风险很高。
如果我们等到 Sprint 中期才发现这些细节,那么由于开发人员将不得不等到细节从歧义中明确出来,因此本 Sprint 未能完成的风险也很高。

敏捷框架并没有帮助团队如何在执行分析和设计时保持敏捷。
它只是一个很棒的框架,用于
1_ 更好的沟通
2_ 产品演示
3_ Sprint 任务计划
4_ 流程改进

我会继续使用你的口头禅并在其基础上添加...
“做正确的事
为了你的团队
为了你的项目
为了你的产品待办事项”

SDLC 框架或流程不会构建软件。
遵循软件工程最佳实践进行分析、设计、编码和测试将帮助您构建健壮的软件,并最大限度地减少您在您选择遵循的任何 SDLC 框架中失败的机会。

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.