Scrum和假说驱动的开发

响应变化的机遇和后果从未如此之高。组织曾经多年应对竞争,环境或社会/政治压力已经几个月或周内作出回应。组织必须从深思熟虑,小心集体对那些能以极快的速度反应。和回应的方式并不引入大量的风险或减少顾客感知质量和价值。

Scrum是建立更好的风险管理和交付价值通过专注于检查和鼓舞人心的适应。它使用实证方法结合自组织,使团队有效地工作在复杂的问题。阅读之后杰夫Gothelf的年代,杰克来自的书”感知和响应:成功的组织如何倾听客户,不断创造新的产品”,我意识到,世界充满了复杂的问题。这让我想到Scrum和现代组织主之间的关系朝着能够感知和响应。所以,我决定问杰夫Gothelf…这是一个浓缩版的我们的谈话。

戴夫:嗨,杰夫,你是著名的精益UX和设计,那么是什么让你写一本关于组织如何感知和响应?

杰夫:在近5年精益UX出来,我们已经收到了大量的反馈。如果我有总之,这将是这样的:几乎每个人都读过这本书同意它倡导的原则和策略。然而,几乎所有的人的反应一样,“我想这样但是我公司工作/老板不会让我。“这似乎是一个机会。如果团队急于改善他们工作方式,但周围的环境,文化,激励,经理——不支持这一变化,我们可以说服他们考虑吗?

感知和响应正是这试图改变管理者的心灵和思想,行政人员和有抱负的经理的职务。是,首先,任何业务的规模或寻求规模软件业务。我们分享一系列引人注目的案例研究来说明这是真的在几乎每一个行业。然后我们继续这本书的第二部分,我们将讨论如何管理一个基于软件的业务是不同的。我们涵盖文化、流程、人员安排、计划、预算和奖励。改变必须是全面的。

戴夫:如你所知,Scrum是检验通过透明加上自组织和适应,授权团队。那听起来像是某种意义上的完美模型和响应组织。Scrum的挑战,建立一个反应是什么组织?

杰夫:根据我的经验,许多组织正在建设和扩大他们的意义的能力。他们投资于DevOps,分析,定性研究等学习活动。他们挣扎是使用这种见解在实时能力和应对他们所学习的。这就是利用Scrum建立响应组织的冲突出现。尽管Scrum提供的韵律和机遇及时应对新见解,大多数组织不奖励这种行为。事实上,它通常被视为一个职业限制移动。这是因为“响应”是一个明确的招生团队,团队领导或行政,他们错了的事。犯错不是组织庆祝。这是他们努力最小化。然而,尤其是在软件企业为基础,我们要经常是错的。 The sooner we can find that out and, even more importantly, respond to what we’re learning the sooner we can course-correct.

戴夫:哇,这是一个大问题。你描述的是奖励团队学习,最终向客户提供更多的价值。但是你不是说团队的目标应该是失败,而是他们需要他们的工作分解成小块的“东西”,为最终的学习提供了最低的风险。例如你不会想要测试一个新的起搏器在某人的胸部,但你要逐步构建知识的起搏器提供利益相关者和获得反馈。

你描述的是所有权的挑战。产品负责人(PO)是Scrum框架的角色授权决策,当事情是什么产品。但无助感是一个真正的问题在大多数组织中,与他们的POs没有做决定的权力。这是你看到的某个东西时,引入感知和响应的构想呢?

杰夫:有一个著名的,20岁的他从布拉德·霍洛维茨称产品经理的“CEO他们的产品。“这不能远离真理。首席执行官有能力做出最终决定,雇佣和解雇的选择,最终形成一个组织的战略和愿景或提供。产品经理(老板)没有。他们可以期待,在理想的情况下,是能够引导产品相关战略和战术成功部署。一旦你感觉到引入到一个组织提供的团队,和他们的产品负责人,信息可能反驳的理由他们正在做的工作。应对这种观点把阿宝在一个具有挑战性的位置经常不得不证明航向修正的组织承诺发现他们的团队冲突的感觉。阿宝好可以洞察他们的传感和把它翻译成引人注目的故事写在他们试图说服人的语言,希望最终交付客户价值。

戴夫:好,你谈到了团队,参与。Scrum要求团队包括每个人都需要交付所需的结果。你会如何员工其中一个团队?对于更复杂的情况下,如何获得所有必要的技能?

杰夫:跨职能协作是成功的关键在任何感知和响应团队。在最基本的层面上,核心团队由产品、设计和工程。我们增强团队主题专家、技术专家或其他交付产品所需的各项技能。然而,这是不够的。没有产品上线没有法律批准,财务预算和运维同意部署和维护它。这些人不属于核心团队。这不是一种好利用他们的时间。然而,他们仍然需要参与这个过程通常每三个月一次。在这种情况下,考虑使用“轨道模型”的反思与这些支持学科核心团队的交互。这个模型要求每个团队形成一个特定的服务水平协议与法律、金融等要求少量的定期支持。 For example, the core team gets 2 hours of a lawyer’s time every 2 weeks. This allows both sides to discuss the current project, debate any legal concerns and move forward in the most compliant way based on current knowledge. This hedges any concerns about running into a series of regulatory, financial or other roadblocks as the team gets closer to full deployment.

戴夫:这听起来完美,它本质上是让这些领域“服务”的团队。不过你不觉得整体的行为释放软件许多组织来说真的很难?

杰夫:也许一度,但这些天几乎所有和我一起工作组织释放一些软件相对迅速。在最坏的情况下,我看到每季度发布。

戴夫:例如大型银行有这样复杂的系统对一个团队来说几乎是不可能理解这些系统足以独自释放客户价值。有一些遗留环境中感知和响应不工作吗?你必须有一个环境,允许small-ish团队的人能够快速发布软件?

杰夫:连续性质的软件让我们感觉尽快可以得到到用户手中。组织需要努力抬高自己的速度学习。船的速度也就越快,他们可以学习越快。小团队移动得更快,所以他们学习得更快。如果有依赖于其他球队,他们可以减轻通过更好地理解什么是“客户价值”在这些团队的依赖。如果我们可以集中依赖团队向相同的客户价值衡量,他们开始更有效地一起工作——通过协作、知识共享、主动解决问题等,让组织更迅速和同样重要的是,做出回应。

戴夫:好吧,假设你能做到这一点,对高管计划什么看起来像在这个新的世界吗?许多高管挑战Scrum因为我们赋予Scrum团队决策护栏内的愿景。他们说“Scrum团队可以做他们想做的事没有任何治理。“当然我们柜台,你仍然需要提供方向,措施和参加Sprint审查看到发生了什么和提供重要的反馈。比瀑布Scrum提供了更多的控制,但是他们仍然不喜欢它. .人们倾向于喜欢详细的项目计划,他们可以测量活动,而不是输出。感知和响应计划看起来像什么?

杰夫:计划是建立一个成功的感知和响应的关键活动实践。与管理的挑战,结果是它改变团队的注意力从功能——轻松地绘制在一个时间表或路线图——客户行为的变化。团队,配备洞察力收集通过感知活动,需要调整课程(“变得敏捷”),因为他们学习这些新事物。这些变化方向与线性路线图实践冲突。支持这一点,管理者需要问问团队是透明他们学习和它是如何影响他们的工作。他们应该问问,看看团队跟踪交付客户价值和跳当团队开始偏离战略课程或者一些重大改变了公司的优先级。

戴夫:这一切很好理解为“新”产品,但许多人构建软件实际上是维护它。添加一些特性和修复bug。也许他们做一系列的变化由法律或监管。这种方法适用于他们吗?这种方法仅适用于创新?

杰夫:我听到这个论点。我相信团队致力于现有系统实际上是在* *职位工作这种方式比团队致力于品牌新举措。现有系统已经有用户。他们使用模式。他们有分析。他们的反馈。所有现有的洞察力让团队更知情的角度优化的地方。他们可以磨练速度远远超过“新倡议”团队的工作最大的客户价值。他们还可以更快地开始评估的影响他们的工作,因为他们已经有用户。

总是会有事情的情况下只需要得到建立。法律和合规是两个伟大的例子。在这些,低风险,低不确定性情况下一个更直接的执行通常是必要的。也就是说,仅仅因为一个功能必须包括合规原因并不意味着只有一个方法来实现它。团队经常会发现有什么实际的灵活性如何实现这些(实际)要求有更多成功和更少的分散注意力的整体用户体验。发现你会消耗水平在这些特性是较小的但它不应该完全抛弃这些特性还需要弄成一个整体的工作流程。

戴夫:Scrum和感知和响应似乎完美地组合在一起。感知和响应将鼓励Scrum团队专注于转变观念和建筑积压问问题的结果,而不是描述解决方案和活动。这不仅会鼓励大家想想他们试图做的,而且也说明了如何衡量它。时间度量添加到你的“完成”的定义:-)