作为首席敏捷教练，我的重点是激励和鼓舞开发人员在我们的团队中采用并贯彻敏捷框架。最初，我失败了，因为我并不真正了解在开源生态系统中工作的团队的心态。我假设由于敏捷和开源价值观非常一致，因此采用敏捷框架的障碍会很低，我们的人民会如鱼得水般接受它。
一开始，这很容易。几乎没有阻力，除了一些过去有过非常糟糕的经历或认为敏捷不适合开源开发工作的人。由于大多数团队成员都同意，我们继续为我们的大多数团队采用了 Scrum。
在我们采用敏捷的三个月后，我们注意到一些团队表现良好，而另一些团队则在挣扎，因此我们认为现在是时候开始收集指标来客观地衡量绩效并找出导致成功或挣扎的问题了。我们积极与我们的两个团队合作，开始为用户故事分配故事点，以便我们可以确定每个团队的速度。它运作良好，并且通过与团队合作，我们能够找出障碍并开始解决它们。
短暂的成功
在我（没有持续多久的）热情中，我向我的所有团队发送了一封电子邮件，要求他们遵循相同的流程。我希望每个团队都开始为用户故事分配故事点，以便我们可以衡量他们的绩效并在冲刺结束时采取纠正措施。
随之而来的是来自一些最优秀和最聪明的人的如潮水般的电子邮件回复，内容是关于为什么这不是一个好主意以及为什么它会以糟糕的结局告终。本能地回应，我开始回复该主题，争论为什么这将对我们有所帮助并给出各种类比。我越是试图捍卫我的计划，我遇到的阻力就越大。
很快我就放弃了，因为通过强制流程赢得这场战斗只会让事情变得更糟，而且我意识到我会失去我最初获得的所有善意。我以为我会在团队变得舒适并在敏捷流程和技术方面变得成熟后稍后重新拾起它。
我的导师，资深的红帽员工，一直在后台观察事态发展。他们帮助我从不同的角度看待它。我们组织的领导者有兴趣从整体上找到采用敏捷框架的积极影响；这不仅仅是团队的绩效。他们想知道诸如
- 我们的组织有多敏捷？
- 我们在哪些方面需要改进？
- 有没有一种方法可以可视化进度？
- 正在使用哪些指标来跟踪我们的敏捷转型？
不幸的是，大多数可用的工具和技术都在跟踪团队的生产力或流程的实施情况，而不是深入问题的核心。
我们没有依赖速度或对流程的遵守，而是通过评估团队的成长和能力（而不仅仅是生产力）来衡量团队的真正敏捷性。我们认为这可以通过反思他们的行为、行动和决策与核心敏捷原则的契合程度来完成。
我们引入了一种全新的方法来跟踪我们的敏捷转型之旅。我们首先创建一个环境，在该环境中，在团队的敏捷旅程的背景下，积极鼓励以下四种行为
- 实验： 让我们保持新鲜
- 分享： 让我们从我们所知道的开始
- 倾听： 让我们观察和反思
- 学习： 让我们发展想法和理解
当团队被赋予实验和发展他们自己风格的敏捷的自由时，阻力就小得多，对持续改进的热情也高得多。由于团队积极分享，我们开始将想法和信息交叉传播到其他团队。团队现在已经成熟，并且每当出现意外情况时，自纠正就开始发生。
一种新方法：敏捷反思卡
我们开发了 敏捷反思卡 ，我们将 12 条敏捷原则 分成三个模板，每个模板包含四条原则。在每次迭代之后，团队都会反思他们与每条原则的对齐程度，并在 1 到 10 的范围内给自己评分。
由于 12 条敏捷原则是通用的和通用的，团队必须进行热烈的讨论，才能就每条原则对他们的团队的意义达成共识。然后，他们必须平均团队成员的评分，并将该数字绘制在列出敏捷原则的轴上。
由于我们是一个高度分散的团队，我们使用在线调查工具在视频会议期间捕获评分，然后将它们显示在敏捷反思卡上。一旦我们将四个评分映射到每个轴上，我们就连接这些点以形成一个四边形。随着时间的推移，这个四边形的形状和大小让我们清楚地了解了团队的敏捷思维方式。
通过允许团队进行自我反思和分析他们与敏捷原则的契合程度，我们能够释放团队的潜力和能力，以便团队在每次迭代或检查点中都能改进和成长。我们真正授权团队绘制他们的旅程，并进行自我纠正，以规划他们的敏捷之路。
2 条评论