敏捷的十二种死法(一)

敏捷小智 发表于 2021/10/09 14:45:06 2021/10/09
【摘要】 最近和一个同事聊起某业务部门的敏捷实践,很惊讶的是该部门在10多年前就已经开始敏捷转型了,然而现在居然感觉不到任何敏捷的存在。最近正好读完Gartner的同名文章,结合自己的经验和思考,来说说为什么有那么多名存实亡的敏捷,已经可以做哪些努力来避免重蹈覆辙。同时也欢迎诸君发表自己的看法。业界敏捷现状无论出于什么原因或目的,许多组织都在尝试第二、三次敏捷转型;可能有50% - 75%敏捷转型失败...

最近和一个同事聊起某业务部门的敏捷实践,很惊讶的是该部门在10多年前就已经开始敏捷转型了,然而现在居然感觉不到任何敏捷的存在。
最近正好读完Gartner的同名文章,结合自己的经验和思考,来说说为什么有那么多名存实亡的敏捷,已经可以做哪些努力来避免重蹈覆辙。同时也欢迎诸君发表自己的看法。


业界敏捷现状

  • 无论出于什么原因或目的,许多组织都在尝试第二、三次敏捷转型;
  • 可能有50% - 75%敏捷转型失败或没有达到预期效果
  • 有外部专家参与的敏捷转型,在外部专家撤离后,敏捷转型的成果几乎难以持续
  • 敏捷转型时,大部分企业只是简单的将敏捷框架叠加到现有的流程和组织。此举往往增加复杂度和工作量,导致转型失败
  • 大多数敏捷转型中,开发者只是被动的接受,而没有机会了解转型完整的背景
  • 实施转型是,决策层往往会认为敏捷只与开发有关

成熟敏捷观点

成功的敏捷转型需要组织各层级共同参与、努力。不仅包括开发者团队,也包括管理团队、企业高层,通常需要自上而下的进行思维、文化、组织上的转变,而不是简单照搬官方的敏捷指导或业界实践。在转型过程中,需通过工具和实践进行初步的实施,然后通过学习、反馈和创新进一步完善转型实践,以确保转型的可持续,最终满足多样化和不断变化的业务需求。

根据大量敏捷转型失败的案例,业界总结了导致敏捷失败的十二种错误行为。通过深入了解、思考这些行为产生的原因,为当前计划或正在进行的敏捷转型提供参考,以确保转型能够成功实施。


行为1:汉堡式敏捷

汉堡式敏捷属于典型的部分敏捷,将敏捷实践夹杂到当前重型的瀑布流程中。在传统V模型中,每一个阶段都需要1-2个月,甚至更多,而仅在其中编码阶段引入迭代式交付。

具体表现为:

  • 仍按传统思维,需要对需求尽量的收集完整、彻底的分析和设计,确保每个环节没有问题,并且每个环节都需要层层审批,以此来确保“降低风险,成功交付”
  • 汉堡式敏捷不一定是“敏捷开发”,其他环节都可能单独“敏捷”,如敏捷测试、敏捷构建;但敏捷阶段前后皆是重型的阶段。
  • 每个阶段仍是等待前一阶段一次性大量的输入,并一次性大量输出给下一阶段。

思考:

  • 此种行为可能是最常见的行为之一。公司高层往往认为交付仅是开发者的事,或某一环节的事。此时,虽然实施了敏捷,但结果没有任何不同;
  • Scrum Master和PO被限制在某一环节,无法为整体质量负责。
  • 一次性大批量交付无疑会导致问题的集中爆发,从而导致下游甚至全阶段都手忙脚乱,难以应对。
  • 层层审批并不能提高交付质量,降低风险
  • 重型分析、设计结果虽有参考,但仍是以“假设”为前提,而不是以“事实”为依据

预防或纠正措施:

  • Scrum Master和PO有理由去向公司高层普及必要的敏捷思想和基础,必要时引入外部专家————通常外来和尚好念经。
  • 由高层驱动各个环节的整体转变会容易的多,但Scrum Master和PO首先需对敏捷有深刻的理解,再次需确保高层能理解到位。
  • 树立PO是产品交付的核心总指挥、Scrum Master是军师和指导员的地位;
  • 将大V改为小V,将瀑布嵌入到敏捷迭代,而不是敏捷嵌入到瀑布阶段;
  • 通过观念转变、数据洞察、技术分析或流程改进手段减少审批环节


行为2:有名无实

有名无实的敏捷实践仅在交付团队中套用了敏捷流程框架,而没有进行思维、文化上所需的转变,仍以过程为中心,而非交付价值为中心。

具体表现为:

  • 虽然按照敏捷框架进行组织变革,但各团队仍以孤岛形式存在。在团队与团队之间传递信息仍以文件、邮件、会议为主。
  • 虽然也有迭代计划,但按迭代发布几乎没有,仍是原来一月甚至几个月一个版本。
  • PO或Scrum Master对其角色定位模式,没有承担相应的职责
  • 身兼多职情况比比皆是,无法完全专注于业务交付

思考:

  • 敏捷法则要求打破信息孤岛,要求团队是一个全功能团队,所有成员需共同工作
  • PO或Scrum Master是敏捷团队运作成功的核心,如果对角色职责不清晰,就无法保证工作顺利开展
  • 按迭代交付版本其价值不仅仅是快速交付给客户,更重要是的说明团队对产品理解到位、对需求拆分到位、架构和设计合理;
  • 专注是高效工作的前提之一
  • 自认为没问题,那么请和过往进行比较,如果没有变化,或变化不大,那么肯定走错了路

预防或纠正措施:

  • 团队所有角色需重复学习敏捷思想、宣言和机制管,而不是停留在字面和照搬,尤其是掌舵了Scrum Master,必要时可解决外部力量,如顾问、敏捷教练;
  • 全功能团队中角色虽有侧重,但需要全员参与,因此不仅组织上需要是一个团队,物理位置、沟通渠道、信息分享同样是一个团队;
  • 坚持没迭代一个交付,即便开始无法达成,也要不断的学习,纠正。实际上敏捷无止境,持续学习和改进才是敏捷核心
  • 和其他团队交流敏捷实施心得。


行为3:脆弱敏捷

组织通过强大且冗余的组织架构、复杂的多级流程、完备的风险规避措施来确保业务上的成功;甚至在实施敏捷时依旧试图通过各种框架和规则来确保敏捷的成果。这种内在的冲突不仅不利于敏捷的转变,反而会让敏捷僵化,会产生一个僵化的,无法适应不断变化业务的脆弱研发模式。

具体表现为:

  • 在企业内部把敏捷过程标准化为通用的企业标准,明确角色和上下文分工。每个环节做好本职工作,不用也无需问为什么,也不能越界。
  • 由上层定义每个阶段的完成或就绪标准,而不是根据业务特点。交付团队只能被动接收,而无法改变。
  • 横向组织负责所有决策,并提供统一的配置;交付团队不能个性化配置;
  • 对交付进行回顾总结时往往采用“如何规避”的方法,而不是“从根本上”解决;
  • 交付服从指令进度,技术服从业务,优化服从功能开发,技术债务高筑

思考:

  • 当各种流程和框架叠加与敏捷时,交付团队的交付过程将束手束脚,无法敏捷
  • 流程和规则应该是团队敏捷的有力帮手,而不是重重障碍
  • 符合各种规章制度、规范与灵活满足业务个性化并不矛盾,可以同时满足
  • 长远利益需与近期利益达成一致,而不是退让

预防或纠正措施:

  • 通过知识传递和技术分享,与高层达成一致,建立信任,并赋予交付团队更多自主权;
  • 通过先进技术的引入来弱化各种流程和强管控,提供个性化能力,给予交付团队更多的自由度;
  • 利用业界共识以及试点,获取高层支持,达成长远利益与近期利益双赢

系列文章

  • 敏捷的十二种死法(一)
  • 敏捷的十二种死法(二)
  • 敏捷的十二种死法(三)
  • 敏捷的十二种死法(四)
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区),文章链接,文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:cloudbbs@huaweicloud.com进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。