大规模敏捷的 7 个容易被误解的真相

简介: 大规模敏捷的 7 个容易被误解的真相

大规模敏捷不只是将敏捷实践从团队扩展到组织,而是需要改变思维和组织架构,将以管理为主的组织观念转变为以人为中心的组织观念,将组织改造为简化、自治的团队,实现可持续的价值交付。原文: The Uncomfortable Truth of Scaling 'Agile'


敏捷转型(将敏捷从团队级别扩展到整个组织),不仅仅是实现像 SAFe®这样的框架,而是需要从僵化的、自上而下的管理转变为灵活的、以人为中心的操作,这些操作植根于简化的架构、自治的团队和频繁、可持续的价值交付,而不是承诺更快、更便宜的结果。


大规模敏捷背景

任何敏捷转型都超越了采用 SAFe 这样的框架,而是要挑战传统的自上而下的泰勒式管理风格。敏捷转型需要完全不同的方法,而不是简单推出一个由咨询公司策划的计划。敏捷转型从来不是过程驱动,而要依赖于文化和思维的转变。


因此,成功的敏捷转型需要简化组织架构、培养自治团队,并将焦点从规定流程转移到以人为中心的交互上。应该鼓励灵活性以适应特定的组织环境,而不是严格遵循 Scrum 或看板等实践。最后,重要的是要记住,敏捷并不承诺更快、更便宜的结果,而是强调频繁、可持续、高质量的价值交付。


以下是大规模敏捷的七个常见问题:


  1. SAFe 并不能解决问题: 规模化敏捷框架(SAFe)通常被视为围绕敏捷交付并帮助大规模组织保持一致的解决方案。然而,重要的是要明白,仅仅实现 SAFe 或任何其他扩展框架并不能自动解决由于渴望变得敏捷而出现的问题。它要求组织采用敏捷思维,改变其文化和组织架构,同时理解从团队到高管的所有层次的原则和价值观。
  2. 泰勒主义不能解决复杂的适应性问题: 弗雷德里克·温斯洛·泰勒的科学管理原则,即泰勒主义,侧重于通过自上而下的方法来优化单个任务,以提高效率。这个概念适用于简单、重复的任务,但在处理当今常见的复杂适应性问题时就不那么管用了。促进团队自治、自我管理、跨功能、迭代和增量开发以及客户协作的敏捷实践不仅更适合,而且不可或缺。20 世纪 20 年代通用汽车的成功之道不再是成功之道。
  3. 前进方向是缩小组织规模: 虽然"大规模敏捷实践"得到了很多关注,但对许多组织来说,缩小组织规模可能是一种更有效的策略。缩小规模包括简化架构和流程、消除官僚障碍、促进精益原则。这些策略增强了团队能力、减少了浪费、提高了速度,并能培养持续学习和改进的文化,最终带来更高的客户价值。由于许多利益相关者的既得利益,也会引发许多阻力。
  4. 前进方向是授权团队解决客户问题: 赋能、自主的团队是敏捷的核心。敏捷团队不受指挥和微观管理,而是享有自组织、决策和解决问题的自主权。这种方法增加了员工积极性和工作满意度,并提供了更快、更创新的解决方案,而不是规定团队应该做什么。考虑一下"自治、掌控、目标"。
  5. 避免规定流程和工具: 虽然流程和工具自有其位置,但在敏捷环境中应该是次要的。敏捷宣言更倾向于个人和交互,而不是流程和工具。因此,与其规定一种放之四海而皆准的方法,组织应该培养一种赋予个人权力、促进协作和拥抱变化的文化。
  6. Scrum、看板 —— 长远来看没啥关系: Scrum、看板和其他敏捷实践只是工具,它们能提供指导,但本身并不是目的。组织不应拘泥于单一实践或框架,而应采用结合各种概念的灵活方法。最终目的是找到最能满足组织独特环境和需求的工作方式,并向客户提供最高价值。
  7. 敏捷意味着更快和更便宜: 虽然敏捷可以更快交付客户价值,但并不一定意味着工作将以更快速度或更低成本完成。敏捷强调质量、可持续的工作节奏和频繁的价值交付,而不是匆忙完成任务或偷工减料。与普遍看法相反,"敏捷"并不是"事半功倍的艺术"。

结论

如果没有敏捷思维的转变,仅仅采用几个框架,将敏捷从团队层面扩展到整个组织,是无法解决敏捷问题的。要想在当今复杂的问题中取得成功,需要调整架构,减少官僚主义,并授权团队自治,从而克服过时的泰勒主义原则。




你好,我是俞凡,在 Motorola 做过研发,现在在 Mavenir 做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。微信公众号:DeepNoMind

目录
相关文章
|
2月前
|
机器学习/深度学习 人工智能 监控
提升软件质量的关键路径:高效测试策略与实践在软件开发的宇宙中,每一行代码都如同星辰般璀璨,而将这些星辰编织成星系的过程,则依赖于严谨而高效的测试策略。本文将引领读者探索软件测试的奥秘,揭示如何通过精心设计的测试方案,不仅提升软件的性能与稳定性,还能加速产品上市的步伐,最终实现质量与效率的双重飞跃。
在软件工程的浩瀚星海中,测试不仅是发现缺陷的放大镜,更是保障软件质量的坚固防线。本文旨在探讨一种高效且创新的软件测试策略框架,它融合了传统方法的精髓与现代技术的突破,旨在为软件开发团队提供一套系统化、可执行性强的测试指引。我们将从测试规划的起点出发,沿着测试设计、执行、反馈再到持续优化的轨迹,逐步展开论述。每一步都强调实用性与前瞻性相结合,确保测试活动能够紧跟软件开发的步伐,及时适应变化,有效应对各种挑战。
|
7月前
|
人工智能 自然语言处理 文字识别
飞天技术观丨大模型如何真正在应用环节产生价值
大模型揭开了智能时代的序幕,其技术发展日新月异,创新成果不断涌现。可即便如此,最终不可避免地要回答一个问题:大模型如何真正实现商业化应用落地?
飞天技术观丨大模型如何真正在应用环节产生价值
|
人工智能 供应链 Cloud Native
智库观察|大模型时代,AIGA将大规模解放生产力
“小模型+AI+智能化底座”的模式,让AI应用适配不同数字化阶段的企业,这将成为企业级应用的不可逆趋势。
230 0
|
数据采集 存储 编解码
在架构师的角度去看大型网站架构面临的挑战:技术架构的基本思路
技术架构的基本思路 技术架构既要清晰地划分功能模块或子系统,又要对整个网站系统的技术逻辑有清晰的认知。庞大的技术架构确实会让人望而却步,架构设计也变得无从入手。 如果把一个庞大的技术架构分成独立的几部分,然后再逐一深入的话,那么一个庞大的技术架构也不是不可理解的
|
Unix 程序员 Apache
当开源遇见 KPI,全球化 VS 本土化,开源的理想与现实该如何和解?
最近几年,开源在全球蓬勃发展:一方面,越来越多人投身于开源生态中,除了开发者,不懂代码的人也能为开源社区做贡献;另一方面,开源贡献的形式更多元,不再拘泥于写代码,文档贡献、开源布道也是建设开源生态的重要动作。
265 0
|
人工智能 监控 安全
IT必须拥有业务思维以超越传统的业务伙伴关系
通过将其思维模式从支持核心技术转变为更紧密地与业务目标和客户需求相协调,Oshkosh公司的IT部门正在更加关注并理解那些能够最终改变人们生活的解决方案。
288 0
|
机器学习/深度学习 人工智能 自然语言处理
现实需求巨大,技术尚未成熟,学界与业界思维大碰撞
作为人工智能皇冠上的明珠,自然语言理解不断吸引着学术界与产业界的目光。然而,在这个极具挑战性领域,若干理论问题和技术难题尚未得到根本解决,而现实生活和社会中又面临着巨大的应用需求。如何通过学术界和产业界的共同努力,让其在实际应用中发挥更大的作用,在研究与应用的相互反馈中共同进步呢
3425 0
|
程序员
老程序员的巨大优势——积累起来的经验——打破30/35岁的魔咒!
  最近找了一份工作,在工作中体验到了以前积累的工作经验的巨大优势。     需求很简单,就是做一个网站,展示一下要出售的商品,再加上一个资讯作为陪衬。当然还要有一个会员管理,会员分类,会员购物车、订单、网银接口等,还有SEO的注意事项,再加上URL重写,还有就是业务员和会员的关系。
1029 0
|
运维 架构师 测试技术
从架构理解价值-我的软件世界观(转载)
程序员的迷茫-找寻不到价值 在浩大的软件世界里,作为一名普通程序员,显得十分渺小,甚至会感到迷茫。我们内心崇拜技术,却也对日新月异的技术抱有深深的恐惧。技术市场就像这喜怒不定的老天爷,今天下个大数据雨,明天挂个人工智能风,面对琳琅满目的技术浪潮的冲击,程序员难免深感无力,深怕错过了技术潮流从而失去了职场竞争力。
1246 0
下一篇
DataWorks