敏捷开发生产率 标准

作为首席敏捷教练，我的重点是激发和激发开发人员在我们团队中采用和遵循敏捷框架。 最初，我失败了，因为我不太了解一直在开源生态系统中工作的团队的心态。 我的假设是，由于敏捷和开放源代码的价值是如此紧密地结合在一起，因此采用敏捷框架的障碍将很低，而我们的人民会像鱼到水一样去接受它。

一开始，这很容易。 除了过去曾经历过非常糟糕的经历或认为敏捷性不适合开源开发工作的人之外，几乎没有阻力。 由于大多数团队成员都参加了会议，因此我们继续前进，并为大多数团队采用了Scrum。

敏捷采用三个月后，我们注意到少数团队表现良好，而其他团队则在苦苦挣扎，因此我们认为是时候开始收集指标以客观地衡量绩效并确定导致成功或奋斗的问题了。 我们与两个团队积极合作，开始为用户故事分配故事点，以便我们确定每个团队的速度。 它运行良好，并且与团队合作，我们能够发现障碍并开始解决它们。

短暂的成功

出于热情（持续时间不长），我向所有团队发送了一封电子邮件，要求他们遵循相同的过程。 我希望每个团队开始为用户故事分配故事点，以便我们可以评估他们的表现并在冲刺结束时采取纠正措施。

随之而来的是来自一些最优秀和最聪明的人的电子邮件回响，讨论为什么这不是一个好主意，以及它为什么会收效不佳。 我本能地回应了这个话题，并争辩说这为什么会对我们有所帮助，并给出了各种各样的类比。 我越努力捍卫自己的计划，遇到的阻力就越大。

我很快就放弃了，因为通过强制执行过程赢得这场战斗只会使事情变得更糟，而且我意识到我将失去最初获得的所有善意。 我以为我会在团队变得更适应并在敏捷流程和技术方面变得成熟之后再选择它。

我的导师，长期的红色帽匠，一直在后台观察这种情况。 他们帮助我从另一个角度看待它。 我们组织的领导者有兴趣从整体意义上寻找采用敏捷框架的积极影响； 不仅仅是团队的表现。 他们想知道类似的事情：

• 我们的组织有多敏捷？
• 我们需要在哪些方面进行改进？
• 有没有办法可视化进度？
• 哪些指标用于跟踪我们的敏捷转型？

不幸的是，大多数可用的工具和技术都跟踪团队的生产力或流程的实施方式，而没有深入到问题的核心。

我们不依赖于速度或流程的依附性，而是通过评估团队的成长和能力，而不仅仅是生产力来衡量团队的真正敏捷性。 我们认为可以通过反映他们的行为，行动和决定与敏捷敏捷原则的一致性来做到这一点。

我们引入了一种全新的方法来跟踪我们的敏捷转型过程。 我们首先创建一个环境，在团队的敏捷旅程中积极鼓励这四种行为：

• 实验：让我们保持新鲜
• 分享：让我们从我们所知道的开始
• 听：让我们观察和反思
• 学习：让我们发展思想和理解

当团队可以自由地进行实验并发展自己的敏捷风格时，他们的抵抗力就会大大降低，而对持续改进的热情就会大大提高。 由于团队之间一直在积极共享，所以我们开始将想法和信息交叉授粉到其他团队中。 团队现在已经成熟，只要出现无法按预期进行的情况，就可以进行自我纠正。

一种新方法：敏捷反思平台

我们开发了敏捷反射平台 ，在该平台中 ，我们将划分为三个模板，每个模板由四个原则组成。 每次迭代后，团队将反思与每个原则的一致性，并以1到10的等级对自己进行评分。

由于12条敏捷原则是通用和通用的，因此团队必须进行热烈的讨论，以就每种原则对团队的意义达成共识。 然后，他们必须平均团队成员的评分，并在列出敏捷原则的轴上绘制该数字。

由于我们是一个高度分散的团队，我们使用了在线调查工具来在视频会议期间捕获收视率，然后将其显示在Agile Reflection Deck上。 一旦将四个等级映射到每个轴上，我们就将这些点连接起来，形成一个四边形。 随着时间的流逝，四边形的形状和大小使我们清楚地了解了团队的敏捷心态。

通过让团队自我反思并分析他们与敏捷原则之间的紧密联系，我们能够释放团队在每次迭代或检查点改进和发展的潜力和能力。 我们真正赋予了团队测绘旅程并进行自我更正的能力，以绘制出敏捷的路线图。

翻译自:

敏捷开发生产率 标准