企业敏捷转型的5个谬论

我最近写了一篇博客，阐述了一个谬论在企业敏捷转换中不需要项目经理。回想那篇文章，它让我想起了其他我见过的误解，我的客户也经常问我这个问题。下面是我听到的最多的一些，我试图澄清一些常见的误解。

谬论#1:“我们不需要文档，我们是敏捷的!”

我一直听到这种谬论。它源于敏捷宣言的价值“工作软件高于全面的文档”。许多人读了这篇文章后认为我们只是想编写代码，而不是提供文档。这实际上意味着看到工作的、经过测试的软件比预先花费大量时间记录更有价值。这并不意味着没有文档。

在许多组织中，长期存在的文档非常重要。它超越了在未来提供价值的主动性。这个值可以是角色、满足审计需求、理解设计决策或系统需求。文档也可以嵌入到代码、自动化和测试用例中，或者可视化规范中。我所指导的重要的事情是专注于提供仅仅足够的文档。我们的目标是提供足够的文档来提供共享的理解，仅此而已。除此之外的任何东西都是无用的。没人会去看搁在架子上积满灰尘的巨型文件!

谬论#2:“敏捷意味着我们从第一天起就会更快!”

我经常在转换开始时听到这句话。客户将试图比较他们在敏捷开发前一年完成的工作和他们现在交付的工作。当然，这是在比较苹果和橘子。

敏捷做得很好，它专注于首先交付最有价值的工作，尽早降低风险(而不是等到项目结束时)。我们不想把去年做的事情都做完。我们想要快速交付最高价值的项目，并使用反馈来修正航向。

随着时间的推移，稳定的团队、自动化和过程改进将使团队更快。但是，你可能真的觉得你在一开始就慢下来了。关注价值优先级和高质量可以减少返工，让你的产品更快地进入市场。

谬论#3:“已经3个月了，我们已经完成了!”

跟着我重复，“我的敏捷转换永远不会完成!”这是一个需要理解的重要概念。你总是在评估。你会不断进步。这是一个持续的循环，永远不会结束。

世界正以惊人的速度向前发展。如果你停下来休息在你的桂冠上，有人会与你擦肩而过——你可以是“百视达”或“柯达”的同义词。我们实施的一个关键概念是您的转型的可持续性。许多敏捷转换失败的原因是它们没有内部支持和机制来在初始阶段之后继续前进。这就是新的生活方式!

谬误#4:“我们永远不可能在2周内交付产品!”

如果您是传统的瀑布式组织，那么从8-12个月的发布周期到2周的sprint似乎是令人生畏或完全不可能的。你绝对可以做到，但这不是一夜之间就能实现的。

企业敏捷转换需要时间。你需要帮助。定义最终状态愿景、实现结构、治理和度量将使您走上正轨。在敏捷实践中形成、培训和指导团队将开始改变您交付的方式。使用指标来评估您的交付系统，并做出改变以减少您的批规模和优化价值流。开始自动化和DevOps工作，识别并解耦依赖项。

当您实现更改时，您将看到进展。真正的转变是一个旅程，但它是可以做到的!

谬论#5:“我们仍然可以做我们一直在做的事情，只是以敏捷的方式!”

改变是困难的。它可能会让人不舒服。当事情变得有压力时，我们想回到舒适的状态。但如果成功了，你为什么要变形?

我们都听过疯狂的定义——“一遍又一遍地做同一件事，却期待着不同的结果。”真正的改变意味着以不同的方式做事。它不需要一次做很多改变。事实上，我喜欢做一些小的改变，衡量进步，并适应那些不起作用的事情。

在规模上，我们不能通过同样的结构来实现敏捷。它将需要改变，围绕产品或价值进行组织，将人们聚集到跨职能团队中，将工作分解成更小的增量。

请记住，当我们采用敏捷时，我们正在培养一些特殊的东西。回到你原来的工作方式会减少你的成果，产生坏习惯。确保你有一个清晰的愿景，明确的最终状态，以及关于为什么迫切需要真正推动改变的良好沟通。关注“为什么”将帮助组织在改变背后保持一致。