为什么敏捷既简单又复杂
谁会不同意 敏捷宣言 的四项核心原则——
- 流程和工具上的个人和交互
- 综合文档之上的工作软件
- 客户协作优于合同谈判
- 响应变化胜于遵循计划
– 不是源自将常识应用于严重问题吗？
这些原则的应用可能适用于解决许多组织功能障碍，并将容易出错和复杂的社会环境减少到可能只是一个复杂的环境？
采用敏捷有多种充分的理由，例如：
- 生产力低下，
- 士气低落，
- 在日益激烈的人才争夺战中招聘高级人才的问题，
- 预算限制（没有更多的资金可以浪费在瀑布项目上），或者
- 竞争高速推动创新，传统方法无法跟上创新步伐。
但事实也是，敏捷组织转型的范围常常被完全低估。敏捷并不是解决所有问题的快速解决方案。每个组织都有自己的一组功能障碍，因此处理它们的解决方案需要专门针对该组织量身定制。
敏捷失败模式
通过分析我过去的项目，我确定了以下跨组织模式，这些模式正在使敏捷过渡变得更加困难、效率低下且成本高得多：
组织层面的敏捷失败：
- 首先没有（产品）愿景：如果你不知道你要去哪里，任何道路都会带你去那里。
- “我们知道我们需要建造什么”的谬论。无需产品发现或假设测试，高级管理层可以定义与产品积压相关的内容。
- 管理层面的失控导致微观管理。
- 该组织在愿景和战略方面不透明，因此团队难以自组织。
- 没有失败的文化：因此，团队不会离开他们的舒适区，而是安全行事。
- 该组织并未针对快速构建-测试-学习文化进行优化，因此各部门的行动速度各不相同。由此产生的摩擦可能会抵消之前的敏捷收益。
- 高级管理层没有参与敏捷过程，例如冲刺演示，尽管他们是榜样。但他们确实希望有一种不同形式的（推送）报告。
- 不让组织缺陷可见：敏捷的好处在于它迟早会发现所有组织问题。 „当您将问题输入计算机时，方框会隐藏答案。问题必须是可见的！”美国肯塔基州埃尔兰格丰田生产系统支持中心前总裁 横井英志
- 产品管理不被视为组织内的“问题解决者和领域专家”，而是将需求转化为可交付成果的人，也就是“吉拉猴子”。
- 其他部门从一开始就没有涉及产品管理。大型组织中的一种典型行为是一种筒仓思维，其特点是不考虑整体公司战略的局部优化工作，通常由个人激励驱动，例如奖金。 （个人议程并不总是与公司战略保持一致。）
- 产品管理的核心职责由其他部门承担，例如跟踪，从而使产品依赖于其他部门进行数据驱动的决策。
- 如果产品管理团队的规模与工程团队的规模相比过大，则没有专门团队的产品经理可能会出现问题。
团队层面的敏捷失败：
- 工程团队中的初级工程师太多了。他们倾向于将微观管理作为培训的一部分。通常，他们没有或几乎没有敏捷方法的经验，因此他们很难实现流程，尤其是他们无法说“不”。
- 具有开源编码心态的工程师：一旦任务完成，就会在拉取请求中进行讨论，但不会在梳理或冲刺计划会议期间提前进行讨论。 （他们倾向于以分布式团队的心态运作。）
- 团队太小，因此不能跨职能。示例：一个团队只处理前端问题，缺乏后端能力。该团队将始终依赖于其他团队提供构建功能。
- 团队人员配备不足，例如 Scrum Master 职位空缺，产品负责人必须同时担任两个角色。
- 团队成员公开拒绝敏捷方法，因为他们不想被推出他们的舒适区。
- 团队不是自组织的。这将需要对团队的绩效承担责任，并对交付和价值创造有紧迫感。
- 更糟糕的是，团队成员悄悄地放弃了敏捷，认为它是一种迟早会消失的管理时尚。
- 伪敏捷 ：团队机械地遵循“敏捷规则”，而不理解为什么首先要定义这些规则。这种采用水平通常会导致一种称为“Peak Scrum”的现象：尽管严格遵守所有敏捷规则，但与之前的流程相比没有任何改进。甚至更糟的是：士气和生产力下降，因为最初的敏捷培训后的热情在战壕中迅速消退。
- 根据临时通知在团队之间调动人员。即使出于技术原因需要，这也会对团队的绩效和士气产生负面影响。
通过投票分享您自己的经验： 您目前面临的最重要的敏捷挑战是什么？
过程级别的敏捷失败：
- 只要看起来合适，敏捷过程就会被扭曲或忽略。缺乏流程纪律。
- 敏捷流程被调和，例如，Scrum 产品负责人角色被减少为项目经理角色。这通常是通过将积压所有权的任务分配给管理层的不同实体来实现的。 （“没有产品负责人的 Scrum”实际上是一个很棒的 Waterfall 2.0 流程。）
- 利益相关者正在绕过产品管理来完成事情，并在高级管理层的眼中侥幸逃脱，因为他们会表现出主动性。
- 该组织没有在团队沟通和研讨会上花费足够的时间来就要构建的内容达成共识。
设施级别的敏捷失败：
- 工作环境缺乏正式和——更重要的——非正式交流的场所：自助餐厅、茶室、沙发等。
- 工作环境缺少白板。实际上，办公室内每一面可用的墙上都没有白板应该值得怀疑，因为没有。
- 敏捷需要合适的办公室来进一步协作：宽敞、空气和光线充足。但它们不应该只是一个开放空间，这往往会变得过于嘈杂，尤其是当几个 Scrum 团队同时举行站立会议时。
你有什么看法？
您对敏捷方法论的失败有何经验？你观察到什么模式？