跳转到主要内容

保存的文章

敏捷转型从何开始?无处不在。

Joel Bancroft-Connors |领导敏捷
乔尔Bancroft-Connors
阅读: 敏捷转型从何开始?无处不在。

好吧,你的企业想要开始一个敏捷转型。对你有好处!我们假设你知道你为什么要这么做,价值是什么,并且这不是一个一蹴而就的过程。

这仍然留下了一个问题,你从组织的什么地方开始?您是从小规模的团队级别的方法开始的吗?你是否得到了高层的支持来进行自上而下的推动?你通过PMO工作吗?那么中层管理人员呢?

组织结构问题

答案是,是的

让我们来看看敏捷转换的各种入口向量,以及它们为什么会失败。

从团队开始

向上箭头键
当我第一次获得对敏捷的正式理解时(就像许多我已经做了很多年却没有意识到的人一样),我对敏捷的基本Shu理解是非常注重团队和个人的。我想我的客户服务背景让我很自然地选择了这家公司。作为这一观点的自然延伸,我相信“敏捷必须从团队中成长”。如果你相信你是敏捷的,你就会是敏捷的。

就是在这个时候,我第一次提出了“更好的人会带来更好的团队,更好的团队会带来更好的项目,更好的项目会带来更好的产品,更好的产品会带来更好的公司,更好的公司会创造更美好的世界。”“哲学。

不幸的是,这就像一个孩子脖子上绑着毯子从父母的屋顶上跳下来,以为自己能飞一样。在万有引力定律面前,信念只能带你走这么远。在遇到大型组织的障碍之前,团队级的敏捷转换在企业中只能走这么远。

从上到下

DownArrow在另一端,你有坚定地相信敏捷转换必须来自执行层的敏捷人员。没有他们的支持,您永远无法克服敏捷的抗体和组织障碍。这种方法最常见的问题是提交失败。该高管说“我们正在进行敏捷化”,甚至可能会聘请一些顾问来帮助我们。

就像产品经理没有转变为产品负责人一样,高管也没有参与转变。除非高管愿意将时间直接投入到工作中,否则来自高管层的授权和愿景很少能成功。即使他们这样做了,他们也会遇到来自中层的强烈阻力,而没有来自上层的持续支持。

在中间相遇

Candle_Both_Ends_frankieleon_3528950399_362521a615_z有一段时间,我相信这就是成功的秘诀。找一个想要进行敏捷试验的团队,让管理层自上而下地支持。这也充满了风险。我了解到这就像蜡烛两头烧一样。很快中间部分就开始融化了。即使敏捷的试点成功了,也会有两件事将其粉碎。第一个是最敏捷的试验是小规模、高绩效的项目,它们不会跨越组织障碍。另一个问题是,处于中间位置的管理者会因为担心这会改变他们的角色而倾向于成为诽谤者。

这让我意识到,没有中层管理人员的参与和支持,你是不可能成功的。这让我开始寻求帮助,教育管理者在敏捷组织中成为管理者意味着什么。虽然教导经理们从管理任务转向使他们的团队成为可能当然是有价值的,但这并不是开始转变的神奇切入点。它确实建立在我的“更好的人”信念之上,即我在帮助经理更好地支持他们的指导,即使他们不做敏捷开发。这并没有帮助我找到开始敏捷转换的向量。

PMO

PMO

我对更好的管理者的关注,加上我的PMI背景,使我开始探索如何从项目管理办公室推动敏捷转型。我真以为我发现了什么。项目管理办公室通常拥有流程或对流程有很大的影响。作为中层管理者的同僚可以对他们施加一些强大的影响。但问题来自四面八方。团队对项目经理对“每月的过程”有一定的了解。“这些非工程师想告诉我们如何编写软件吗?”接下来,虽然PMO可能能够得到一个执行发起人,但通常这个发起人只延伸到启动会议。虽然PMO拥有自己的流程,但由于敏捷要求人们管理人员与他们的上司互动的方式发生根本变化,这些管理人员通常是高度抵制的。

因此,底层、上层和中层都面临着发起敏捷转型的挑战。那我们该怎么办?

全面的方法Structure-Governance-Metrics-Predictability

当我在探索如何指导更好的管理者时,LeadingAgile的创始人Mike和Dennis开始意识到,只有系统的方法才能成功地将企业级组织转变为敏捷。通过建立一个敏捷的结构、治理和度量标准,公司可以使团队清晰地了解他们的需求、责任(和能力),并能够通过工作的、测试过的软件来可度量地跟踪进度。

这种方法并不只关注一个方法向量。相反,它建立了一个敏捷的转换计划,从投资组合,通过规划级别(产品所有者团队)到交付级别。当敏捷试验完成时,它不是尖端的XP实践或精益创业。相反,试点是测试组织的其他成员也将采取的第一步。执行发起人直接参与,就像产品所有者应该做的那样。经理们不仅知道发生了什么,他们还直接参与其中,获得支持他们的团队所需要的支持,而不是驱使他们走向死亡之路。当然,团队会得到实际的帮助,以过渡到Shu级敏捷框架,这是敏捷转换的多步骤旅程的第一步。

团队片不像敏捷本身

当我们谈到创建一个稳定的敏捷团队时,我们经常使用蛋糕的类比。Scrum团队(选择敏捷框架)应该拥有发布潜在可发布产品增量所需的所有技能。敏捷转型需要成为整个组织的一块蛋糕,在转型中每个人都是平等的参与者。

当我们谈到企业敏捷发布仪式时,我们有发布计划、sprint计划和起立演讲。在敏捷转换中,项目组合是发布计划,程序是sprint计划,团队是每日站立。

结论所有的组织结构

如果你想要一个成功的企业规模的敏捷转换,你不能从顶部、底部或中间开始。你必须同时从连续体开始。

对我来说,这是一个认识,我的“更好的人,更好的团队”的哲学不是“一个通向下一个”的发展尺度。相反,你必须与公司作为一个整体合作,让各个层面都变得更好。我仍然相信更好的公司将拯救世界,这就是我在帮助一家公司进行企业级敏捷转型时所做的。

下一个;这是关于完成,而不是开始

Joel Bancroft-Connors是一位经验丰富的敏捷实践者,他致力于解决与企业程序和项目相关的挑战。

留下你的评论

您的电子邮件地址将不会被公布。必填字段被标记