成为敏捷领导者，第4部分：确定下一步

总结一下：您的敏捷转换被困住了。 您已经考虑了自己的原因，就像成为敏捷领导者一样，第1部分：定义原因 。 您已经开始衡量可能性。 您像要成为敏捷领导者，第2部分：与谁接轨中一样，会与谁交谈。 您已经考虑了需要哪些人作为盟友，以及如何招募他们成为敏捷领导人，第3部分：如何创建盟友 。

现在，是时候考虑下一步要做什么了。

您可能会想：“我知道下一步该怎么做。 我有一个路线图，我知道我们要去哪里。 你在说什么？”

影响。 我说的是考虑发现短期和长期的行动，这些行动将帮助掌握敏捷转型关键的人成功地实现敏捷转型。

这是一个例子。 帕特里克（不是真实姓名）希望帮助他的组织敏捷转型。 当他来到有影响力的敏捷领导者时，这就是他的目标：帮助变革。 那是一个大目标。 当我们到达影响力部分时，他意识到自己的目标已经太大。

他现在想要什么？ 他与一个撰写技术故事的团队合作，难以完成工作，没有演示或回顾，并希望将其迭代的时间从两周增加到四周。 他知道那可能是错误的方向。 （有时候可以增加迭代的长度。该团队进行了很多更改并要求提供更多交付，增加时间并不是一个好的选择。）

他以为自己在管理上有问题。 他做到了，但这不是团队中的问题。 正如第1部分所述 ，当他回顾自己的理由和地图时，他意识到组织需要一种敏捷的方法来频繁地交付客户价值。 如果这个团队（和其他几个团队）能够定期释放价值，那么来自客户和管理层的压力将会减轻。 他可以与经理一起解决项目组合和其他管理问题。 但是，他确信实现这一目标的方法是帮助该团队频繁交付。

他意识到自己有两个有影响力的人一起工作：架构师和质量保证主管。 这些人看上去都好像在“抵抗”。 实际上，架构师希望开发人员重构模式以保持代码库干净。 质量检查负责人认为他们在创建测试之前需要计划，并且正在寻找“完美”的测试自动化工具。

他认为自己的具体目标是“至少每两周一次帮助该团队创造价值。 在六个月内维持交货。” 这个目标（“敏捷”的子集）使他可以先与架构师合作，然后与QA负责人合作，然后再与两者（是的，他在研讨会上练习了全部三个对话）以实现自己的小目标。

帕特里克·帕特里克（Patrick）在工作坊的对话中练习探索短期和长期交付成果。 虽然谈话的方式并没有完全一样，但他有足够的实践能力在影响力和指导之间进行切换，以了解他可以根据自己的情况与他人做些什么。

团队又花了3次迭代才能开始制作小故事，但他们做到了。 他花时间邀请架构师与团队成员一起在团队中工作，以传达一些小故事，从而使代码库保持整洁。 他要求建筑师提供有关如何与质量检查负责人一起工作的帮助。 架构师向负责人展示了如何启动自动化和重构，以便测试人员甚至在开发人员完成代码之前就可以进行测试。

该团队又花了三个月的时间才能每周定期交付价值，而不必等待迭代结束。

帕特里克的原始路线图很棒。 而且，一旦他开始与团队和管理层合作，就需要调整他和其他教练最初计划的交付成果。 相互影响的对话使他能够看到其他人的担忧，并考虑在整个过程中哪些小型交付品将有助于该团队成功。

他在该团队中学到的一些知识为其他团队提供了帮助。 而且，其他团队有不同的问题。 他使用了不同的教练，并影响了与不同人的对话。

如果您想体验如何影响力以及如何学习，在帮助您的敏捷转型继续进行的背景下，请参加我们于2017年5月9日至10日在多伦多举行的下一届有影响力的敏捷领导者会议 。

我的下一篇文章是关于我们的参与者学习的。

翻译自: https://www.javacodegeeks.com/2017/03/becoming-agile-leader-part-4-determining-next-steps.html