敏捷领导力
总结一下:您的敏捷转换被困住了。 您已经考虑了自己的原因,就像成为敏捷领导者一样,第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
敏捷领导力