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