交付转型到敏捷的最大错误解释

随着公司将软件解决方案从本地迁移到云端,他们经常为自己设定一个变得更加“敏捷”的目标。 这通常应该理想地适用于跨公司层面的所有事情。 当然,同时在任何地方。

至少在理论上,流程的转变是很容易实现的。 您可以定义 Scrum 仪式并将人员重新分配给新角色(例如 Scrum 管理员、产品负责人、交付经理和 Scrum 团队)。

您可以携带 Jira、Azure ADO 和 Miro 板等工具,并强制使用它们。 但是将工具连接在一起的过程又如何呢? 改变人们的思想、行为和工作方式怎么样? 很明显,这些转变不会顺利,也不会很快完成。 现在,让我们观察一下原因。

什么是交付转型计划以及公司为何要这样做?

如今,很大一部分公司仍然按照瀑布交付模式工作。 这意味着:

  • 首先,计划你想要做什么作为最终结果/产品,以及它的大致成本是多少。
  • 开始需求收集过程,在此过程中,您彻底讨论最终产品的所有细节,反对,质疑,同意,再次讨论,最后确认。
  • 评估整个事情并确认预算预期。
  • 设计解决方案。 与利益相关者举行多次会议。 创建各种文件并让利益相关者审查它们。 确认并批准最终的功能和技术设计。
  • 根据设计实施解决方案。 这是您开发完整最终产品的地方。
  • 进入测试阶段并执行各种测试:单元测试、系统测试、功能测试、集成测试、性能测试、回归测试、用户验收测试以及可能的更多测试(取决于公司文化)。 记录一切并让利益相关者审查和批准。
  • 将解决方案部署到生产环境。 这是目标用户开始使用最终完整产品的地方。
  • 安排一些支持阶段,在此期间开发团队纠正解决方案的潜在错误。
  • 整个过程可能需要几个月到几年的时间,正如您所看到的,用户只有在该过程结束时才会看到结果。 因此,经过漫长的等待,关键时刻(或失败时刻)到来了。

    如果在这么长的时间内发生了变化并且最终产品看起来有点不同,这种情况称为变更请求。 设计必须重新开放、返工和重新批准。 它使整个时间表又延长了一部分。

    显然,这无论如何都不是敏捷的。 每一次改变都需要重新启动之前的整个流程。

    转向敏捷

    那么,我们如何摆脱这种情况并改变它变得敏捷呢? 人们在瀑布装置中工作了许多年甚至几个世纪。 他们有自己熟悉的角色和责任,并且不想改变现状。 主要原因是,进行这一改变最终意味着他们将失去一些迄今为止拥有的权力。

    这就是为什么这种改变会引起你可能创造的人们最强烈的抵制的主要原因。

    #1. 团队重组

    第一个也是相对最简单的做法是将人员重组为 Scrum 团队。 根据功能区域或任何其他有意义的逻辑划分来划分它们。

    分裂通常会顺利进行; 当你意识到人们仍然受到原始结构的束缚时,问题就开始了。 即使他们已经是新 Scrum 团队的一部分,但实际上他们还不是。 他们仍然在旧的设置上工作,因为他们仍然有责任没有随着团队重组过程一起结束(因为为什么会这样——领导层不太关心需要完成什么,但主要关心必须开始什么)。

    因此,实际上,您最终得到的 Scrum 团队并不是完全敬业的 Scrum 团队。 这群人现在只是有更多的工作要做。 Scrum 团队内部的工作时间并没有管理层预期的那么多。

    同时,期望人们能够完成他们原来的活动以及 Scrum 团队内部的这一新期望。 这是一个从一开始就注定会失败的设置。

    #2. 安排 Scrum 仪式

    命令团队安排几次定期电话会议(冲刺仪式)很容易定义和启动。 至少,假设您的 Scrum 团队不由来自 3 个以上时区的人员组成(通常是这种情况)。

    当人们不定期参加仪式时,问题就开始了。 根据失踪人员和失踪频率,这可能会演变成各种问题。 例如:

    • 如果产品负责人不参加规划和完善仪式,团队就没有新的故事可做。 或者故事的描述太差,以至于团队的其他成员无法开始处理它们。
    • 如果 Scrum Master 不在电话中,团队就会缺少基本的 Scrum 编排,并且随着时间的推移最终可能会迷失方向。
    • 如果开发团队的团队成员经常缺失,彼此之间无法同步,团队内部的沟通就困难得多。 此外,需要召开更多会议来跟上进度,这又占用了团队的时间。

    最终,错过仪式并不一定是人们的错。 只是设置不允许他们参与通话(请参阅上面关于并行先前分配的信息)。

    #3。 团队稳定性

    你可能有一个有结构和仪式的 Scrum 团队,但如果这个团队在较长一段时间内不稳定——假设至少半年,理想情况下,一年的稳定将是我个人的最低要求——那么这样的团队可以并没有真正发展和改进。

    接下来,您可能永远不会建立一个完全独立的 Scrum 团队来照常处理冲刺。 最后,您需要不断地教育和学习团队内部的人员,以了解 Scrum 思维方式和流程。 这是一个令人筋疲力尽的问题。

    这是一个被严重低估的问题,尤其是公司的领导层或管理层。 将人员团队称为“资源”并按季度规划他们的“利用”是一条通往地狱的道路。

    #4。 同一个人的新角色

    另一个需要克服的障碍是将现有人员重新分配到不同的新角色。 例如,那些以前拥有最终权力的团队管理人员现在可能成为产品负责人。 这是 Scrum 团队中的一个强势角色,但与现有设置相比,它可以被视为较弱的角色。

    突然之间,产品负责人必须与 Scrum Master 或项目经理同步。 他们仍然对内容负责,但对交付过程不那么负责。 这种情况需要人们放弃一些以前承担的责任,因此难以接受。

    #5。 工作方式

    这很有趣,我经常听到——我们需要学习新的工作方式,以便在不断变化的市场中占据一席之地,而敏捷性是基本期望。 但这些工作方式到底意味着什么?

    如果你问我,我很清楚管理层的意思——在更短的时间内取得(更多)更多的成果。 建立 Scrum 团队后,期望每个团队成员都会突然实现一些记录在案的日常增量结果。 如果情况并非如此,领导层将开始询问为什么敏捷流程运行不佳。

    突然间,领导层期望每一个小时都很重要,并且 Scrum 团队基本上没有空闲时间,只是因为可以说没有空间来容纳所有 Scrum 流程。 简而言之,这就是从领导力角度对“新工作方式”的定义。

    当然,这种期望并不是建立在现实检验的基础上的。 仅仅因为一些日常流程会发生变化,就期望公司员​​工在同一时期内开始更多地工作,这是不切实际的。 我的意思是,其中一些人可以,即使只是少数。 然而,即使是这个群体,也会因为同时处理更多任务而进一步减少。

    目标与现实之间的差异

    毫无疑问,对最终目标的描述通常是好的,而且很有意义。 它遵循以下原则:

    • 稳定的 Scrum 团队致力于独立的积压工作,并具有明确的 KPI 和 OKR。
    • 产品所有者建立可靠的路线图并规划优先内容,以根据具体时间表交付。
    • 在工作开始之前,已定义积压内容以及相关功能的详细信息。
    • 可靠的测试流程与常规冲刺开发工作一起执行。
    • 定期发布到生产环境——至少每月一次,但最好是在每次冲刺完成后。
    • 不同 Scrum 团队之间存在依赖关系时进行风险和问题跟踪和沟通。

    那么,到了现实中,我可以说,以上几点都不是容易实现的。

    • 您组建了 Scrum 团队,但他们在不断变化(每个季度)。 你投入时间向团队传授 Scrum 流程,一旦他们最终开始接受并改变他们的工作方式,你就可以在下一个时期重新组织团队。 路线图被修改、转移或取消。
    • 产品负责人对路线图细节没有真正的了解,并且(只是因为他们以前有这样的习惯)他们会将构建积压内容的任务直接分配给团队。 因此,团队没有时间开发内容,因为他们首先需要弄清楚要开发什么。
    • 测试过程仅是手动的,需要大量的子步骤和批准以及复杂的流程。 这意味着测试不可能在与开发相同的冲刺内完成。
    • 因此,发布到生产环境落后了几个冲刺。
    • 不同 Scrum 团队之间的沟通混乱且低效,因为每个团队的每个 sprint 都有很多活动需要完成。 事实上,产品负责人倾向于在每个冲刺中为团队分配过多的内容。 团队不可能完成这一切,因此他们一直面临着最后期限的压力。

    纠正错误

    凭借一些敏捷转型项目的经验,我想总结一下我所经历的一些最大的错误,并就可能克服这些错误提出一些主观意见。

    #1. 正确的职责对应正确的角色

    如果您试图扭曲定义并以任何其他方式分配责任,而不是按照 scrum/敏捷应有的方式,那么您就会使整个计划失败。

    • 产品所有者应拥有内容并维护积压工作。 他们负责积压的故事,如果积压的故事没有明确定义,则由他们采取行动并修复它。 另一方面,他们不应该对 Scrum 团队人员分配或项目预算决策产生任何影响。
    • Scrum master 不对待办事项内容承担任何责任。 他们在团队中负责精心策划仪式并以敏捷的工作方式教育团队。 他们不应该成为产品负责人的秘书。 相反,他们应保护开发团队免受产品所有者和外部利益相关者的影响。
    • 每个 Scrum 团队都应指定一名交付负责人。 此人将把 PO、SM 和开发团队连接到可行的设置中,定义交付流程,并解决团队可能存在的任何潜在风险、问题或冲突。 交付负责人是决定项目人员配置和预算问题的合适人选。 此人应努力为团队营造一个每个人都能发挥最佳水平的环境。
    • 开发团队的职责是根据待办事项开发故事。 他们可以帮助 PO 为某些故事构建内容(主要是那些技术性太强的故事),但他们不负责甚至不负责构建路线图内容创建的故事。

    #2. 稳定的团队

    投资团队的敏捷教育很重要,而且必须是一个快速的过程。 每隔几个月就让这些知识消失对每个人来说都是浪费时间。

    您可以将前五个冲刺用作团队的学习曲线,以了解和练习基本的 Scrum 活动。 一旦整个团队都清楚了这些,Scrum 团队的持续改进过程就可以开始。 但如果团队内部的人员定期更换,你会发现自己处于知识转移和教育的不断循环之中。

    这样的团队可能永远无法充分发挥绩效潜力,领导团队将继续想知道为什么以前(敏捷转型之前)比现在看起来更高效。

    因此,建立团队,投入知识,一旦团队对新流程充满信心,就保持现状并进一步发展。 从这里开始,不断走向完美的道路将开始。

    #3。 RACI矩阵

    在真正的工作开始之前,在所有团队之间建立并商定 RACI 矩阵(负责、负责、咨询、知情)是一个很好的做法。 这可能会在一开始就消除很多混乱。

    这非常重要,尤其是在转型举措的早期阶段。 否则,人们会开始提出关于谁应该在什么情况下做什么的问题,尤其是那些团队沟通中没有明确解决的问题。

    下面是一些职责的 RACI 矩阵的示例。 您的项目可以有不同的集合。 捕获相关的内容很重要。

    任务请求者交付主管产品所有者Scrum Master开发团队冲刺计划会议C/ICA/IRC/I交付增量N/AIA/IC/IRS冲刺评审C/IIRICS冲刺回顾IIA/IRC/I细化积压工作IA/IRAC/I

    结论

    仍然有很多东西可以写,因为敏捷转型在很多方面、很多地方都可能导致偏离轨道。 目的是指出一些我认为经常重复出现的问题。

    该倡议本身就是一个好主意。 然而,如果您遵守一些基本规则,它很快就会成为所有参与者的噩梦。 我强调了其中的一些,但只要使用常识,你就会没事的。 🙂

    接下来,查看有关敏捷认证的优秀学习资源。