敏捷方法需要管理文化变革

罗恩·杰弗里斯（Ron Jeffries），马特·巴康布（Matt Barcomb）和其他一些人写了一个有趣的话题，涉及基于团队的敏捷性的规定性和非规定性方法 。 这些问题是细微的，对我而言 ，请不要参与Twitter讨论。 （学习如何简短而连贯地写作是另一篇文章。）

如果您不想阅读整个主题，请执行以下摘要：人们经常需要敏捷方法的帮助。 有些人从整个Scrum开始。 有些人会结合使用并建立起来。

在某些方面，Scrum是一种规定性的方法：它定义角色，定义工作时间以及计划和反思的最短时间。 这是一个框架，而不是一个完全定义的过程。 而且，这就是问题的一部分。 为了有效地使用Scrum或其他任何敏捷方法，团队成员需要考虑一下敏捷方法对个人和团队的意义。

这就是为什么我们拥有敏捷的价值观和原则 。 我经常遇到那些没有将价值观内在化并且没有阅读原则的人。 （而且，如果他们据说正在使用Scrum，他们还没有阅读《 Scrum指南》 。哎呀！）

吉尔·布罗扎（Gil Broza）拍摄了一段很棒的视频，讲述了人们为什么不意识到思维方式是敏捷转变的关键部分。 请参阅“ 实践并不能完美：为什么敏捷转换失败”（50分钟视频）。

安迪·亨特（Andy Hunt）（与已故的贾里德·理查森（Jared Richardson）一起）开始了“ 成长方法” 。 这个想法是从小规模的实验开始，然后在掌握必要的“卫生”项目时进行更复杂的想法：一次完成一件事情，使用持续集成，按等级顺序工作，等等。

我在“ 创建成功的敏捷项目”的第一章中介绍了敏捷方法的历史，以及人们可能需要考虑的敏捷项目。

我确信罗恩（和切特）会教人理解，而不仅仅是“做这个练习”，因为他们是出色的老师和解释者。

敏捷转换存在许多潜在的问题。 我看到的最大的区别是X理论与Y理论管理之间的区别：人们是需要推动工作的资源，或者人们希望为公司做得更好的想法。

敏捷方法挑战管理理念，从而挑战企业文化。

文化表达了管理者的价值。 文化（根据Edgar Schein的观点）是人们可以讨论的内容，人们如何相处，以及我们能得到的回报。 如果我们奖励英雄的工作，多任务的人员和（过多的）计划而不是吞吐量，并且对所有事情都没有反馈或反馈不足，那么我们的敏捷转型将无法成功。 不管使用哪种方法，我们都不会成功。

诸如Scrum之类的说明性框架可以帮助每个人看到文化更接近理论Y而不是理论X。此外，Scrum使文化冲突可见。

但是，使用技能或处方来转变组织的方式在以下方面会失败：

• 我们看不到如何改变管理文化，而这种文化驱动了整个组织的文化。
• 规定性方法并不能帮助团队成员，团队和经理了解文化，也不知道如何进行更改。 人们相互依赖的基于团队的工作与人们独立工作的工作组工作之间存在差异。 迭代不适用于管理和其他工作组。 站立不适用于工作组，因为站立是关于人与人之间的微小承诺，而不是状态报告。 （我在“ 创建成功的敏捷项目”中对此进行了介绍）。
• 而且，并非每个框架都对您的项目有用。 您可能需要比您的方法建议更频繁的计划和反思节奏 。

我不购买Shu-Ha-Ri进行敏捷转换的方法 ，因为它假设通过改变行为可以改变文化。 对于项目来说可能是正确的。 我还没有看到对管理的正确性。 即使我更喜欢Dreyfus技能获取模型 （因为它更细微的差别），但通常还不够。

我们需要通过小型实验来解决敏捷文化的变化。 （这就是为什么我如此喜欢Cynefin并用它来解释敏捷和精益计划管理中的许多问题的原因。）

对我来说，问题是我们如何帮助管理人员从计划驱动的资源效率思维方式转变为适应性的， 流程效率高，反馈驱动的思维方式？ （是的，我也在考虑/也开始写这本书。）

我们不需要经理先改变。 但是，对于任何敏捷方法或工作方式的转变，我们都需要改变管理文化。 对我而言，这就是瀑布迭代与真正的敏捷文化之间的差异。

翻译自: https://www.javacodegeeks.com/2017/12/agile-approaches-require-management-cultural-change.html