激进产品创新中Scrum实施：不匹配还是误用？

### 激进产品创新中Scrum实施：不匹配还是误用？ 在当今竞争激烈的市场环境中，企业常常寻求创新方法来推动产品的激进创新。Scrum作为一种敏捷开发方法，被许多企业视为实现创新的有效途径。然而，在实际应用中，Scrum的实施可能会面临各种挑战。以下将通过对一家软件公司的案例分析，探讨Scrum在激进产品创新中的实施情况。 #### 1. 观察结果 通过对该公司的研究，得出了五个关键观察结果，这些结果与Leavitt钻石模型中的关系相关，具体如下： - **观察1：员工能力与激进产品创新及掌握Scrum所需能力不匹配** - 这一观察涉及Leavitt钻石模型中的任务 - 参与者和技术 - 参与者关系。 - 该公司在2005年经历了重大的业务转型，从主要从事已知技术的软件开发项目，转向开发激进创新的手机。新的开发项目任务事先不明确，且经常变化，这要求开发团队具备主动、创新、自律和自信的能力。 - 同时，公司决定实施Scrum作为新的开发方法，约20人获得了Scrum Master或产品负责人的认证，但并非所有开发者、Scrum Master和产品负责人都觉得自己接受了足够的培训来正确实施Scrum。 - 实证数据表明，开发者和管理者在应对这些变化方面的能力不足。 - **观察2：管理层仅依赖Scrum作为创新的推动者** - 此观察与Leavitt钻石模型中的技术 - 任务关系有关。 - 为了应对创新的新重点，管理层决定采用Scrum作为新的软件开发方法。Scrum的一些优势，如更注重产品输出、能够灵活调整方向以及促进开发者的承诺和责任感，似乎与产品创新的任务相关。 - 然而，Scrum并没有具体涉及创新的内容，例如如何产生、选择、细化创意，并将其转化为产品待办事项列表中的任务。 - **观察3：实施Scrum导致职能经理、Scrum Master和产品负责人之间的权力结构不明确且不稳定** - 这一观察涉及Leavitt钻石模型中的技术 - 结构关系。 - 在实施Scrum之前，公司是传统的矩阵组织，职能部门由职能经理管理，职能经理负责分配人员到项目中，并对开发者进行进一步的教育。 - 引入Scrum后，重点从职能部门转向了Scrum项目，产品负责人和Scrum Master的权力增加，职能经理的权力和权威下降。职能部门有可能沦为Scrum项目的专业知识供应商，甚至可能变得几乎过时或仅作为虚拟部门存在。 - **观察4：未实施团队共地办公，但开发者和Scrum Master希望实施** - 此观察同样涉及Leavitt钻石模型中的技术 - 结构关系。 - 在实施Scrum时，公司试图将Scrum的所有原则融入现有实践，但共地办公这一核心方面未得到实施。 - 原因包括办公空间不足，现有的大而开放的办公空间不适合Scrum所建议的小团队独立工作；多个Scrum团队在一个房间工作会违反公司的安全规定；此外，共地办公还可能与观察3中权力斗争有关，因为共地办公会使职能部门和职能经理的必要性降低。 - 产品负责人、Scru