Hybrid Delivery Is Winning. That Doesn’t Mean You’re Doing It Right.

混合交付模式正在胜出，但这并不意味着你做对了。

The organizations embracing hybrid agile models aren’t making a principled methodological choice — most of them are just formalizing the mess they were already living in. 拥抱混合敏捷模型的组织并非在做出原则性的方法论选择——他们中的大多数只是在将自己原本就身处其中的混乱局面“正规化”而已。

Picture a delivery team at a mid-sized European bank. They run two-week Scrum sprints — daily standups, sprint reviews, the whole ceremony. They use Jira boards. They call themselves agile. And then, every quarter, a Release Approval Board convenes to review a 47-page change documentation package before anything goes to production. The sprints are agile theater. The real schedule is a Gantt chart that lives in somebody’s SharePoint. Nobody says this out loud in the all-hands. They don’t need to. 想象一下一家欧洲中型银行的交付团队。他们运行为期两周的 Scrum 冲刺——每日站会、冲刺评审，整套仪式感十足。他们使用 Jira 看板，自称是敏捷团队。然而，每个季度，发布审批委员会都会召开会议，在任何产品上线前审查一份 47 页的变更文档包。这些冲刺不过是“敏捷表演”。真正的进度表是存在某人 SharePoint 里的甘特图。在全员大会上，没人会大声说出这一点，因为没必要。

This scenario — the sprint-shaped container wrapped around predictive, gate-controlled delivery — has quietly become the dominant operating model in software delivery. According to the 18th State of Agile Report, 74% of organizations now report using hybrid or homegrown models, mixing and matching agile with whatever else their org chart demands. The consulting firms have a polished name for it: hybrid delivery. The people living it often have a less flattering one. 这种场景——以冲刺为外壳，包裹着预测性、门禁式交付的内核——已悄然成为软件交付领域的主流运营模式。根据第 18 份《敏捷状态报告》，74% 的组织目前报告称正在使用混合或自研模型，将敏捷与组织架构要求的其他任何流程进行混搭。咨询公司给它起了一个好听的名字：混合交付。而身处其中的人们往往有更难听的称呼。

Here’s the uncomfortable argument worth making: the rise of hybrid agile isn’t evidence that organizations have matured past ideological purity. For many of them, it’s evidence that they never committed to anything in the first place — and now have a framework-shaped fig leaf to cover that fact. The hybrid model is legitimate. Claiming you’ve adopted one when you’ve actually just left the org chart untouched while duct-taping Scrum on top? That’s a different animal entirely. 这里有一个值得提出的、令人不安的观点：混合敏捷的兴起并非证明组织已经成熟到超越了意识形态的纯粹性。对于许多组织而言，这恰恰证明了他们从一开始就从未真正投入过任何东西——现在，他们只是用一个框架形状的“遮羞布”来掩盖这一事实。混合模型本身是合理的，但如果你只是在保持组织架构不变的情况下，用胶带把 Scrum 强行粘在上面，却声称自己采用了混合模型？那完全是两码事。

How We Got Here

我们是如何走到这一步的

The path from “pure agile” to hybrid wasn’t a straight line. It started with a real problem. As organizations tried to scale agile beyond small teams, limitations became visible — among them, agile’s tendency to underweight documentation and its friction with physical product iteration cycles, both of which created compliance and maintenance headaches in regulated environments. 从“纯敏捷”到混合模式的道路并非直线。它始于一个现实问题。当组织试图将敏捷扩展到小团队之外时，局限性显现了出来——其中包括敏捷倾向于轻视文档，以及它与物理产品迭代周期的摩擦，这两者在受监管的环境中造成了合规和维护方面的头痛问题。

The honest answer was that the Agile Manifesto was written by a group of people solving a specific problem: bloated, bureaucratic software projects that took three years to deliver something nobody wanted anymore. It was never a universal prescription for every industry, company size, or regulatory context. Industries like healthcare and finance need flexibility, yes — but they also require structured documentation and compliance that pure agile simply doesn’t provide out of the box. 诚实地说，《敏捷宣言》是由一群人为了解决特定问题而编写的：那些臃肿、官僚的软件项目，耗时三年交付出来的东西却已无人需要。它从来都不是适用于所有行业、公司规模或监管环境的通用处方。医疗和金融等行业确实需要灵活性，但它们同时也需要纯敏捷无法直接提供的结构化文档和合规性。

So practitioners started improvising. The research literature is notably candid that hybrid combinations “are often not the result of deliberate planning but instead evolve organically based on practical experience, project needs, client demands, and regulatory requirements.” In other words: hybrid happened to teams before anyone named it. The HELENA study — a large-scale survey of European software developers — found even more plainly that hybrid development approaches are “barely planned or defined in advance.” That’s less a methodology and more a symptom. 于是，从业者开始即兴发挥。研究文献坦率地指出，混合组合“往往不是深思熟虑规划的结果，而是基于实践经验、项目需求、客户要求和监管要求有机演变而来的”。换句话说：在有人给它命名之前，混合模式就已经在团队中发生了。HELENA 研究（一项针对欧洲软件开发人员的大规模调查）更直白地发现，混合开发方法“几乎没有经过预先规划或定义”。这与其说是一种方法论，不如说是一种症状。

The Legitimate Cases

合理的案例

To be fair, there are organizations using hybrid delivery because their actual product reality demands it, not because their management layer resisted change. These cases are instructive. Complex mechatronic projects — where machine functionality depends on substantial embedded software tightly coordinated with hardware — create a genuine dilemma: agile methods don’t emphasize the forward planning that synchronized hardware/software delivery schedules require, while the uncertainty of defining software scope in advance challenges the fixed-scope assumptions that Stage-Gate processes rely on. 平心而论，确实有些组织使用混合交付是因为其产品现实的需求，而不是因为管理层抵制变革。这些案例具有启发性。复杂的机电一体化项目——其机器功能依赖于与硬件紧密协调的大量嵌入式软件——创造了一个真正的困境：敏捷方法不强调硬件/软件同步交付进度所需的预先规划，而预先定义软件范围的不确定性又挑战了阶段门（Stage-Gate）流程所依赖的固定范围假设。

The answer there isn’t to pick a winner. It’s to engineer an interface between the two disciplines and be explicit about where each one applies. MIT’s research on industrial delivery systems found three independently operating project teams that each spent more than a decade weaving agile software development into classic Stage-Gate approaches to build workable hybrid management systems. A decade. Not a six-month transformation program. Not a consultant engagement. A decade of actual context-specific learning. 解决之道不是二选一，而是为这两个学科设计一个接口，并明确各自的适用范围。麻省理工学院对工业交付系统的研究发现，有三个独立运作的项目团队，各自花费了十多年时间将敏捷软件开发融入经典的阶段门方法中，从而构建出可行的混合管理系统。十年。不是六个月的转型计划，也不是咨询顾问的介入，而是十年基于具体情境的实际学习。

Pharmaceutical development is another credible case. Researchers have proposed agile adaptations of the pharmaceutical Quality by Design approach — regulatory-mandated frameworks for understanding and controlling products through development — that bring sprint-style iterations to what was previously a slow, waterfall-oriented process, while remaining within regulatory bounds. That’s a genuine hybrid design: not “we bolted a Scrum board onto our compliance process,” but an actual rethinking of how iterative practices can coexist with the structure that regulators mandate. 药物开发是另一个可信的案例。研究人员提出了针对制药行业“质量源于设计”（Quality by Design）方法的敏捷适配方案——这是一种监管部门强制要求的框架，用于在开发过程中理解和控制产品——将冲刺式的迭代引入了以往缓慢的瀑布式流程中，同时保持在监管范围内。这才是真正的混合设计：不是“我们在合规流程上钉了一个 Scrum 看板”，而是对迭代实践如何与监管机构要求的结构共存进行了真正的重新思考。

IBM’s “Agile with Discipline” model takes a comparable approach, balancing adaptability with traditional, structured documentation and planning to meet enterprise clients’ needs. The model acknowledges the tension explicitly and engineers for it, rather than pretending it doesn’t exist. IBM 的“有纪律的敏捷”（Agile with Discipline）模型采取了类似的方法，在适应性与传统的结构化文档和规划之间取得平衡，以满足企业客户的需求。该模型明确承认这种张力并针对其进行工程化设计，而不是假装它不存在。

The Problem Isn’t Hybrid. It’s Costumery.

问题不在于混合，而在于“装扮”。

At a December 2025 practitioner gathering organized by the Agile Alliance in the Netherlands, attendees described a creeping feeling that something had stalled — that agile practices were widespread and certifications abundant, yet many organizations seemed to be experiencing more control with less learning, and growing fatigue rather than adaptability. That’s a precise description of hybrid done badly: the overhead of two systems, the autonomy of neither. 在 2025 年 12 月由荷兰敏捷联盟组织的从业者聚会上，与会者描述了一种逐渐蔓延的感觉：某些东西停滞不前了——敏捷实践虽然广泛，认证也很多，但许多组织似乎在经历着更多的控制、更少的学习，以及日益增长的疲劳感而非适应性。这正是糟糕的混合模式的精确写照：背负着两套系统的开销，却两者的自主性都没得到。

The failure mode has a clear pattern. Scaling frameworks tend to standardize the enterprise to fit the model — business units get redesigned to map against value streams, governance rebuilt around a prescribed cadence. It looks clean on paper, but rarely sticks in practice. And when it doesn’t stick, organizations often retreat to what they know: predictive planning, approval gates, documentation chains — while keeping… 这种失败模式有着清晰的规律。扩展框架倾向于将企业标准化以适应模型——业务单元被重新设计以映射价值流，治理结构围绕预设的节奏重建。这在纸面上看起来很整洁，但在实践中却很难持久。而当它无法持久时，组织往往会退回到他们熟悉的老路：预测性规划、审批门禁、文档链——同时保留……