为什么敏捷很难推销?
我觉得非常有趣的是，为什么定义价值如此困难。敏捷的支持者从一开始就在敲价值的鼓。把客户放在房间里……了解他们的需求……构建他们想要的东西……以小的增量交付软件……获得不断的反馈……集中于最佳的解决方案……尽早并经常交付价值。敏捷是关于提供价值的。为什么一个管理团队不接受一套如此专注于提供他们最需要的东西的方法呢?
以下是我的看法……
敏捷(在很大程度上)是对错误应用瀑布式开发和天真地应用项目管理原则的一种反应，这些方法与软件的实际构建方式不一致。这是对非人化、过程和工件驱动的管理方法的一种反应……过程假设有足够的过程，我们可以以某种方式商品化软件工程的实践。我们想要将不确定性从工程和艺术的结合中剔除。我们的愿望是让一切都是可预测和可重复的。
我们试图把人当成机器，可以无限地分割成不同的任务，这些任务有正确的过程和计划，有正确的项目管理和监督，可以神奇地卷成我们的客户想要购买的工作软件。Jefferies、Cockburn、Schwaber和Sutherland等人开始意识到，成功的项目实际上是高效、忠诚的个人在小团队中共同工作的结果，所有人都朝着共同的结果努力。
XP、Crystal和Scrum是由于认识到这些被授权的小团队交付了最好的结果并且随着时间的推移是最成功的。当这些敏捷方法开始出现时，它们都倾向于小型团队、密切的客户交互和频繁的价值交付。有趣的是，如果你和大多数在小公司工作的人交谈，你会发现他们很自然地就会这么做。人们不是被分配到一个单一的角色，你有一个团队的高效率的个人一起工作，为了他们的集体生存。大公司似乎把事情搞砸了，但我离题了。
快进10年或15年…
现在我们在大型组织内有敏捷的口袋......有时我们甚至可能会在整个大型企业中敏捷。我们正在探索敏捷方法，并试图看出他们是否可以在小团队承诺中提供......但在大中。与这些较大组织的主要区别在于，价值与小型团队或小公司的价值不同。团队表现和业务结果之间没有直接关联......团队提供的直接连接以及我们可以向客户销售的内容。亚博vip9通道它需要太多小团队的产出，共同交付任何价值。
敏捷方法通常会像黑匣子一样对待团队。我们将优先级产品积压作为输入，我们将有价值的工作软件作为输出。但现在......我们必须协调几个团队的产出......甚至可能是几十个团队......进入某种协调可交付。我们必须以协调的方式处理越来越多的人和数百人。当那是我们的上下文......团队合作和协作的信息......团队与客户之间的密切关系不会产生共鸣。这些组织中唯一的方法可以获得任何舒适感......任何感觉他们都是负责任地管理他们的业务......是要求他们的团队致力于庞大的前线计划亚博vip9通道
作为一个组织，我们知道我们需要尽可能快地交付价值。我们知道我们需要有能力应对变化。我们知道，我们需要以更高的可预测性和更高的质量交付。我们有一种直觉，认为我们所做的是行不通的。我们想要得到敏捷所说的好处。我们怀疑像Scrum或XP这样的东西会有帮助，但是我们不知道如何将小团队的概念应用到我们特定的业务问题上。亚博vip9通道这就是为什么你会得到经典的“敏捷永远不会在这里工作”的评论。在团队层面的敏捷方法指导和您的高级主管正在努力解决的更大问题之间，存在着内在的脱节。
团队级别与企业级别的价值之间存在差距。
在一天结束时，我们的社区需要制定指导，帮助我们的高管获得敏捷的好处，而是专注于真实的企业级值交付......在实际结果和真实业务结果方面定义的价值。亚博vip9通道那么，为什么敏捷是一个艰难的卖？我们要求我们的领导人信任一个专注于基于团队的成果的过程，但并没有给他们一个可靠的方式来阐明开发组织如何提供业务更复杂的目标。亚博vip9通道
评论（35）
费德里科•Zuppa
伟大的文章。敏捷如何扩展到大型企业仍然是一个开放的话题，对吗?(我看过几本书，像这本http://bit.ly/2GvBB，但我还没有读过)。有一件事是真实的，当项目变得更加复杂，有更多的人参与，你需要更多的过程来协调工作，因此它变得不那么敏捷(Cockburn的书中有一个矩阵说明这一点)。
斯科特·邓肯
我不相信敏捷必须解决“世界饥饿”，即，底部到企业最高的价值的各个方面，在本组织中具有有效性和有用性。我当然没有看到序列，顺序开发生命周期，也可以解决这个整个值谱问题。所以我不相信这是问题，Thopugh这个问题可能是相关的。
过去，每当出现某种新的进程方法时，根据我的经验，总有人出于某种原因，要求它解决“世界饥饿”以证明自己。当然，这是避免改变的好方法。
当然，这不是那么公然。通常，它被要求展示改变或一些这样的东西的投资回报率。现在，juist关于一个更大的组织中的任何人都知道这类请求的红鲱鱼是什么。除了人们已经想要相信的情况下，大多数组织没有可靠的欧洲数据收集和分析努力，以“证明”任何东西。
大约15-20年前，需求是证明过程改进工作的ROI。当然，人们仍然在争论这个问题。但是我想起Bill Curtis曾经说过的关于PI的ROI度量。当一个组织拥有足够可靠的数据来真正回答这个问题时，他们似乎不再需要证据。他们通过数据来实现管理的努力已经证明了PI对他们的价值。
这可能和敏捷是一样的(就像其他任何类似的变化一样)，也就是。当一个组织能够回答这个问题的时候，他们可能已经不再问了。
Pawel Brodzinski
我想你说到点子上了。我最近和一个人交谈，他来自一个大量使用Scrum的公司，并把它作为他们的区别。他们在这方面非常成功，而我一直在想“你们到底是怎么做到的?”
然后他告诉我们，他们大多是做得非常小的项目（2-3次迭代）。当然他们是小组织。
当我试图将敏捷方法映射到大的组织中时，我通常会遇到一些敏捷团队，他们通常使用Scrum，但却包含着老式的重量级项目管理过程。团队有他们的长期目标，而敏捷只是一个或另一个团队对他们承诺的回应方式。从高层来看，这只是一小部分，不管他们是采用Scrum、瀑布法还是硬核黑客。
FlowChainSensei
优秀的帖子！
有一天，我在twitter上发表了类似的评论:“没有系统思维的敏捷会是一场灾难吗?”
敏捷通常是一种局部优化，源于解决聪明开发人员直接关注的问题的愿望，他们可以看到有比旧方法更好的方法。但作为一种局部优化，本质上它只能为更好的业务结果做出贡献。亚博vip9通道大多数时候，这还远远不够。因此，当前的兴趣系统思维，精益，约束理论等。
不幸的是，许多开发人员在他们自己的团队之外并没有太多的影响力来让这些想法成为他们组织中的主流。
马提亚Marschall
我同意在整个企业中应用以团队为中心的过程是困难的。但重视个人及其贡献肯定会有所帮助。另一个关键点是尽量保持团队在一起，并把工作分配给他们，而不是“为项目配备人员”。这两件事都可以帮助企业更好地工作。
Mike Cottmeyer
费德里科•,
我喜欢考克伯恩的网格已经有一段时间了。敏捷适合在左下象限。许多组织正试图将其应用于顶部和极右象限。我认为这是可以做到的，但要想让敏捷在这些更大、更关键的项目中获得成功，还需要一些额外的流程和框架。我想让大家注意的是，小型团队敏捷本身并不具有可扩展性，而且小型团队敏捷所传达的价值信息并不总是与那些掌握资金的人产生共鸣。谢谢你的评论。
迈克
Mike Cottmeyer
斯科特,
当然，敏捷并不一定要解决世界饥饿问题，或者为中东和平进程提供解决方案。但我总是被问到，我如何向我的领导团队推销敏捷?人们意识到Scrum在团队层面，在大型企业内部，是一种局部优化。这些团队取得了成功，然后他们被解散，重新分配，只是为了重建他们已经拥有的。
所以肯定...如果你想在一个团队层面做Scrum而不是煮沸的海洋......去吧。下次您的组织决定重新组织时，您创建的所有“价值”的所有“价值”都在聋耳朵上令人惊讶。
我保证，我并不是想要急躁;-)但是，当我们只专注于在我们自己的问题领域变得更好时，有时我们实际上损害了整个系统的生产能力。
谢谢你的评论!
迈克
Mike Cottmeyer
流动，
我可以假设Sensei是你的姓;-)
谢谢你的评论。作为一个开发团队或项目经理，您是正确的，在大多数情况下，我们没有足够的影响力来领导组织中必要的改变，以使敏捷可持续。我想现在已经有足够多的高管关注了，也许……只是也许……如果我们继续讨论这个问题……下次他们决定重组时，他们就会考虑这些问题。
如果没有别的，也许我们正在培养下一代的组织领导能力。
谢谢你的评论!
迈克
Mike Cottmeyer
马提亚,
是的，重视个人和保持团队合作一样重要。也就是说，大多数公司的结构和信念每天都在与这些目标作对。人力资源政策、薪酬计划、职业规划、资源跟踪和资源能力报告都促使我们的业务努力优化个人绩效和个人利用，而不是基于团队或绩效或基于团队的结果。亚博vip9通道
因此，虽然你是正确的，但不采用系统方法进行组织设计，将导致长期的失败。我的意思是…抱歉听起来这么可怕;-)
德里克Huether
迈克,优秀的帖子!这真的让我思考。
虽然我看到企业管理团队渴望拥抱敏捷，允许更多的价值被交付，但我也看到他们暂停并设置障碍。目前，他们认为自上而下的命令和控制结构会被自下而上的团队所削弱，交付价值突然变得不那么重要了。虽然我理解企业管理团队提供战略愿景的必要性，但我认为战术实施应该留给团队之外的人。不管我们是否愿意承认，对于管理团队来说，想要而不是需要的层次结构是不同于执行团队的。
问题的关键是，为什么管理团队不接受一套如此专注于提供他们最需要的东西的方法?我的答案是，我认为这是因为传递价值不一定是他们想要的，而是他们需要的。
Mike Cottmeyer
有趣的观察德里克。你和我最近谈过这个。目标实际上可能无法提供更多价值。它可能会覆盖自己，以合适的价格花钱，确保不要摇滚船，得到那个促销或奖金。你想认为这些事情与价值交付相关，但你知道和我一样......这并不总是如此。
伟大的评论!
迈克
Kenneth Clyne.
好帖子迈克。当我与试图扩大规模的公司合作时，我发现我的字典里并没有敏捷这个词。许多高级管理人员已经决定了敏捷意味着什么，我无法改变这种看法(至少短期内不能)。最好专注于定义和交付价值，这直接触及底线。
匿名
你很简洁地描述了我的组织目前面临的困境。这家小公司发展得很快，几年后就变成了大公司。他们正在努力解决你在这篇文章中提到的许多问题。我希望你能发表一些关于如何解决这些挑战的想法。下一步是什么?
Mike Cottmeyer
肯尼斯，
非常感谢评论。我已经探讨了这一点，敏捷是一种手段和结束......这是重要的事情......以及大多数人真正关心敏捷的事实。看看这篇文章错过了。
http://leadingagile.wpengine.com/2009/12/adopting-agile-isnt-point.html
迈克
Mike Cottmeyer
匿名的,
在过去的一年里，我一直在“领导敏捷”上探索这个问题的解决方案。我重新开始问题陈述只是为了弄清楚一些。随着我向前迈进，与更多的人交谈，我表达问题的能力(希望)变得更好。我也在写一本关于这方面的书，所以有些文章在前几章探讨了语言。
也就是说，看看我为VersionOne做的这个视频。你得在他们那里注册才能看到视频，但我认为这是值得的。这是我早期尝试解释值除以速度的问题。
http://leadingagile.wpengine.com/2009/08/adopting-agile-video.html
鲍勃·威廉姆斯
迈克,
优秀的文章。
人们抵制变革，管理团队将抵制变化，因为它对他们的组织能力和站立构成了风险。如果你进入一个组织并告诉他们现在的事情是错误的，这尤其如此，你有解决问题。
我并不以推销敏捷为生，但是作为一个旁观者，我想知道您是否应该从您的推荐中去掉这些名字。而不是告诉管理团队你有一个新的程序(敏捷开发)，让他们真正关注业务价值和需求。亚博vip9通道不要告诉他们做错了，而是向他们展示你有渐进的改进，使他们的组织更加以客户为中心。对待销售engagement和组织转型就像对待方法论本身一样。小的迭代步骤而不是大规模的改变。
问候，
鲍勃
Mike Cottmeyer
我有很多聪明的人看我的博客，真的，真的很酷!
伟大的评论鲍勃。我相信循序渐进的改进。我们必须将改进工作集中在尽可能快地交付最大价值的组织领域。我一直在说，这与敏捷无关。它总是关于尽可能快地交付价值。
迈克
亨利
这一切都与金钱有关，敏捷过程末尾的小增量让客户感到害怕。这就像一个永远不会结束的故事。
瀑布式的客户喜欢的是，一旦他们验证了他们想要的东西，就不再有问题了，他们就不会回头。这是开发团队的问题。
在敏捷开发中，客户大量参与其中，他们必须说出自己想要什么，还必须每周参加会议，监督开发的进展，最糟糕的是，在开发过程中，你可能会发现一些他们不想谈论的黑点。
这就是为什么基本的客户不喜欢敏捷，一个敏捷项目让他们面临最大的恐惧，事实上，有时他们不知道他们想要什么，他们希望你找到最好的解决方案，他们希望能够责备你做了错误的选择。
有时客户的第一个优先级没有完美的产品匹配他们真正想要的东西。不，在失败的情况下，客户想要的是什么都不是责任。
Mike Cottmeyer
他们，
在某些情况下，我不反对你的观点。我只是不认为你的观点是普遍的。与我合作的一些客户喜欢控制他们的产品，喜欢在项目结果上掌握主动权。也就是说，许多组织和许多产品负责人都没有安排全职的产品负责人参与到团队中来。许多人不具备团队所需要的交互层次的知识。领导团队不是他们的激情所在。
在我更愤世嫉俗的时候，很容易假设人们不想与团队接触，因为他们想要指责某人，虽然有时候这可能是真的，但我确实希望这不是普遍现象。
谢谢你的评论。
迈克
大卫平淡
迈克,
我们的敏捷对话的基调并不是一种巧合，包括更多精益，看板和扰顾主题。
我认为这是自然发生的，因为:
1.敏捷社区充满了聪明人。
2.我们正在寻找弥合这一差距的解决方案。
3.越来越多的企业正在尝试在下降生物迅速下的增量交付。
我赞赏您的努力，并预期这些敏捷/精益线程将会成长和发展。
的节日
Mike Cottmeyer
谢谢你大卫,
我同意我们有许多人在那里寻找解决这个问题的方法，并保留有关敏捷的东西。当我得到传教士，或者做某种呼吁采取行动时，我试图确保人们理解这是一个问题。我不确定每个人都认识到这一点。我也想提请注意简单的解决方案可能并不总是解决我们的复杂情况。我们必须是非常背景的。
很高兴收到你的来信，谢谢!
迈克
斯科特·邓肯
你完成说,敏捷是一个“艰难”,因为“我们要求我们的领导人相信这一过程关注团队的结果但不给他们一个可信的方式阐明开发组织将如何兑现的更复杂的目标业务。”亚博vip9通道
几次您注意到，小型团队敏捷方法并未扩展到大型组织的真正问题。在评论中，您注意到播放和提升Alistair的矩阵需要“需要放置敏捷的附加流程和框架，以使其在这些更大的更大，更多的关键任务项目中取得成功......”
你还在评论中提到一些大客户/项目是如何想要保留控制权，而不是提供全职的PO支持等等。也就是说，他们对敏捷方法不感兴趣或不能够遵循敏捷方法。因此，在这种情况下推销敏捷很可能会失败，也就是说，“很难推销”。
所有这些都告诉我，您的主要观点是，有些情况是如何不适合采用敏捷方法的。在这些情况下，试图强制采用敏捷方法是不会成功的。还需要一些其他的方法，或者至少是一种不需要特定实践的敏捷方法。
从根本上说，这就是要传达的信息吗?
Mike Cottmeyer
斯科特，谢谢你的评论。
不，最基本的信息并不是敏捷不能在这些环境中工作。我想说的是，我们需要扩展我们对敏捷的定义。我去过很多用敏捷= scrum的客户网站。
如果我重新构建你的评估，问你我是否在建议有些地方scrum不是答案，我会明确地说“是的”!
我是一个大帐篷敏捷家伙......我们需要拥抱不仅仅是scrum，因为虽然Scrum是强大的，但它没有讲述整个故事。
斯科特·邓肯
好吧，那么这篇文章是关于Scrum的局限性，而不是敏捷的局限性。你提到Scrum时提到的XP和Crystal呢?这种担忧是否会扩展到FDD和DSDM，作为其他敏捷方法的例子?我意识到这些工作并没有得到广泛的应用和推广，但是，特别是对于DSDM来说，目标似乎是更大的组织和项目规模。
那么我们需要什么敏捷的方法/做法，超过scrum？还是它是别的，如瘦肉/卡班板？
Mike Cottmeyer
斯科特,
不是真的。更重要的是，我们往往会忽视对我们的业务真正有价值的东西。亚博vip9通道用户故事是价值的增值吗?对开发人员来说是，做产品经理，不是。对于产品管理的高级副总裁来说，这些人想要考虑任何少于3-6个月的产品交付。
任何敏捷方法都可能因此受到影响。Scrum现在拥有最多的思想份额。XP和价值几乎处于同一条船上。克里斯托也一样。AUP和DSDM得到了更好的扩展，并更正式地承认了业务涉众。亚博vip9通道我认为，既然AUP在RUP和用例分析中有更坚实的传统，那么考虑更大的范围就更好了。
总之，我认为解决方案包含了所有这些元素。团队层面的Scrum, XP, Crystal。AUP和DSDM，我们尝试扩展。精益是我们考虑整个企业的价值流。我的书就是围绕这个主题写的，所以不用说，解决方案并不适合一篇博文。如果你读了下一篇文章，我解释说这篇文章的目的是澄清问题，而不是阐明解决方案。
希望这对你有所帮助，但我猜不会;-)
詹姆斯
嗨,迈克!我来晚了，但我还是想说说我的看法。我认为很难将敏捷方法推广到更大的环境中的一个原因与这些组织在过去几十年里首先倾向于使用大量方法的原因是相同的——恐惧。对不确定性的恐惧。我断言，软件开发本质上是不确定的，而我们人类也同样本质上害怕不确定。我们喜欢“知道”任何行动的结果。我们特别想知道我们投资的回报(投资越大，了解的需求就越大)。因此，我们已经尝试创建流程和控制来增加我们的确定性。当然，这通常是不成功的，但(也许具有讽刺意味的是)我们更愿意相信我们已经尽了全力，即使有证据表明这是无效的(至少我认为这是“某种东西”)。
敏捷方法有很多优势，但大大的最强大（在我看来）之一是早先交付有形产品，更频繁地。即使这不会加速这个过程（相信它），它仍然提供了正面反馈，我们在正确的路径中，数据以证明（或调整）我们的假设，以及更快地适应改变条件的机会。但是，在某些方面，它也包含如此令人不安的不确定性。当然，这是其优势之一。但承认这一点并接受它是非常困难的。即使我们大胆并采取一些步骤，我们也仍然经常将那些安全毯拖着我们 - 只是为了:)
斯坦Yanakiev
好的文章,迈克!这是对为什么敏捷在团队层面很有吸引力，但在更高层面却很难奏效的最佳分析。
史蒂夫•丹宁
嗨,迈克,
问题不在于敏捷不能扩展。问题是，敏捷在为客户提供价值方面的整个动态与从根本上为股东赚钱的传统管理是不相容的。
敏捷通过交付价值来赚钱:赚钱是结果而不是目标。传统的管理以赚钱为目标，最终为了实现这个目标而剥削客户和员工。这是两种非常不同的哲学，它们导致了完全不同的管理实践。当这两种管理实践相互接触时，传统管理倾向于在小规模或大规模上摧毁敏捷。
好消息是，现在存在普遍的认可，即甚至可以根据自己的条款失败。它变得越来越缺乏生产力。它不适合今天的市场或今天的工作场所。现在有一个相当大规模的运动来重塑传统管理，这是一种代表敏捷价值的演变，即重点是向客户提供价值。我在此开始的一系列博客帖子中描述了这一进化：http://stevedenning.typepad.com/steve_denning/2010/11/the-deathand-reinventionof-management-a-draft-synthesis.html.．
我还在我的新书《激进管理的领导者指南:21世纪重塑职场》(josey - bass, 2010)中更详细地讨论了正在进行的变革。
敏捷难以向传统管理者解释的原因是它代表着一种彻底不同的哲学。我在博客文章中勾勒出了博客文章，如何解释为CFO：http://stevedenning.typepad.com/steve_denning/2010/09/how-do-you-explain-agile-or-radical-management-to-a-cfo-.html.
更根本的需要是向传统管理者解释，他们的管理方式越来越不合时宜。苹果(Apple)、亚马逊(Amazon)和Zappos等新管理理念的典范在市场上非常成功，朝着这个方向的持续发展是不可阻挡的。唯一的问题是它会以多快的速度发生。
阿尔伯特·刘易斯
我认为并保持敏捷和瀑布从根本上不同，因为他们解决了根本不同的问题/情况。Agile arose to address situations with high uncertainty around requirements yet there was a need of something functional in very short periods of time…hence the notion of gradually “discovering” requirements, a f ew at a time, and developing/delivering software code to address what was known at the time and rapidly iterating to gradually increase the functionality addressed. Waterfall, addresses situations where there is room for time to dsicover the requirements in a more holistic manner and think through their implications prior to design/development. each of these methods have logical consequences in terms of scope creep/change control.
此外，当你有小团队时，敏捷是有效的(而不仅仅是最好的)，在小团队中，每个人都有很高的能力和经验，有很强的团队化学和能量。如果没有这一点，您的敏捷开发就不会真正地敏捷，并且由于设计人员的能力不够高，将会出现大量的返工(因为发现新的需求越来越需要设计返工)。
因此，我不相信敏捷能够完全替代瀑布，反之亦然。
刘易斯，你的评论是一个有趣的评论。我同意你的一些积分并不同意他人。
我不会试图解开它，我只想让你知道:
无论我有时间还是不发现......我必须权衡问题的知识。我必须评估我对确定性的假设。如果问题是知识，并且通过尽早提供解决方案，瀑布很好（可能）没有增量值。如果我可以通过早期交付（业务风险，技术风险，后勤风险）和优化我的业务成果，请降低风险，然后亚博vip9通道我可能需要考虑敏捷。
我不认为敏捷仅仅是关于紧急需求。我相信敏捷只不过是一种降低风险的策略。降低我建立了错误的产品,降低风险,我有一个解决方案,满足时间和成本的限制,减少我可以建立产品风险,减少风险,我将耗尽资金,降低风险,我建立质量差或不同步与其他交付团队。
瀑布式通过文档和签名来减轻风险。敏捷通过增量构建产品来降低风险。对我来说，就是这么简单……但与此同时，当我开始回复这个问题时，我意识到我可以一直谈论关于瀑布是如何在我能想到的所有软件项目中都是次优交付策略。总之，我的0.02美元。
阿尔伯特·刘易斯
不要不同意你，也不会这样做，我认为转移我的观点。我认为不同的是你的观点。如果您认为客户的观点或矿井的观点，两者都将同时有效。
然而，如果我是一家外部承包软件开发公司，那么如果有客户来找我说“敏捷”(或类似的情况，需要敏捷)，我会回答“时间与材料”，但如果他说“瀑布”，我可能会愿意出价“固定价格”，特别是如果我对我的过程能力/成熟度的水平完全有信心。我的观点是控制“失控范围蔓延”的风险。
保罗Ionica
我同意大多数评论者的观点，这是一篇很棒且令人耳目一新的文章。
我欣赏对传统管理技术和敏捷之间关键区别的总结，以及敏捷思想背后的驱动力是交付客户价值。一切都很整洁。
但我更看重的是，当敏捷在大型组织或企业层面实施时，您坦率地解决了敏捷遇到的挑战。承认敏捷目前的局限性以及它目前正在努力站稳脚跟可能需要一些谦虚。然而，这可能是为企业级敏捷实现开发长期解决方案的第一步。
继续干得好!
阿尔伯特·刘易斯
现在我几乎和鲍勃·马丁叔叔一样老了，但我只是最近才接触到他的演讲，我刚刚看了他的几段视频。
所以现在，我有理由暂停和重新考虑我在敏捷上的立场。
我大家仍然是我在2011,2015的敏捷中的评论，我仍然会站起来。我也可以纠正，也许是敏捷，客户可以在更短的时间内看到更多可交付成果，并且整体本身可以是工程过程的一流程度。我想我现在了解最好的为什么这些家伙建立了敏捷宣言。即使你扔掉所有不成熟的废话，睾丸激素驱动的年轻人围绕着敏捷，但保持短暂的迭代周期，小型竞争力，良好的铰接和沟通，良好的软件工程纪律训练，并保持原来的敏捷宣言前往前方和中心然后，我同意敏捷可以很好地工作，适用于程序员，为项目经理和客户提供。
但是，这是否就像说任何一群高度能干、训练有素、训练有素的工程师总是胜过大多数其他队伍....?
如果像Bob叔叔说的那样，每5年，程序员的数量翻一番，有一半的程序员有少于5年的经验，....那么，必要的纪律、必要的技能水平、沟通水平和必要的成熟度更有可能与敏捷宣言的精神背道而驰?