询问的力量(ScrumMasters与敏捷教练)

举报
Bob Jiang 发表于 2020/07/13 15:45:48 2020/07/13
【摘要】 很多天之前, 我复习了一遍Ken Schwaber和Jeff Sutherlan共同开发和维护的“Scrum指南”。 我集中于ScrumMaster角色涉及“教练”方面的内容,下面是我的一些发现:Scrum Master服务开发团队的几种方式,包括:指导开发团队自组织和跨职能指导开发团队没有完全采纳与理解Scrum的组织环境Scrum Master服务组织的几种方式,包括带领和指导组织采纳S...

很多天之前, 我复习了一遍Ken Schwaber和Jeff Sutherlan共同开发和维护的“Scrum指南”。 我集中于ScrumMaster角色涉及“教练”方面的内容,下面是我的一些发现:

Scrum Master服务开发团队的几种方式,包括:

  • 指导开发团队自组织和跨职能

  • 指导开发团队没有完全采纳与理解Scrum的组织环境

  • Scrum Master服务组织的几种方式,包括

  • 带领和指导组织采纳Scrum

为了弄清这几点,我开始回忆过去十年的事件。那个时候对于敏捷方法我们都是新手。在印度Scrum还不是很流行。我们正在学习迭代开发并尝试理解与跟随敏捷原则。XP那时很流行。

我们团队不是完全自组织的。Jim,组织中一个高级项目经理负责建立项目团队,与团队一起工作并确保交付日期。之前他有一些RUP的经验。Jim是个优秀的人、经验丰富的经理、求知学者与导师。

对我而言,Jim的角色有点像ScrumMaster。

在项目早期Jim注意到Sailesh,团队中的一员总是迟到(1小时或2小时甚至有时候3小时),完成任务后就回家。Jim思想很开放。他主张弹性工作时间。Jim没有冲动做出任何判断只要Sailesh可以交付并完成他的承诺。Sailesh是个非常优秀的程序员,他写的代码质量非常高也负责一些复杂的特性。

一个月左右,Jim发现有个团队成员需要Sailesh的帮助解决技术问题。但Sailesh不在。和往常一样,他那天迟到了然后开始他自己的工作。很明显,每天Sailesh有足够的时间完成自己的工作。他的日常计划包含协作或者帮助别人或者互相帮助了吗?Sailesh有点自负因为他的技能和经验。他不需要其他团队成员的帮助。也许你猜到了,他没有任何协作的态度。

这里有问题。观察到类似Sailesh的这个事情后,Jim有点担忧并在第二天上午九点召集一个会议。Jim想要我和他们一起开会。因为在接下来几个月Jim准备让我接班。

第二天早上Sailesh又迟到了。他9:40走进会议室,随口说,“Hi Jim,我刚刚到,我们可以开始了吗?”。已经迟到了40分钟。

Jim忍无可忍,回答,“Sailesh,现在9:40!你怎么来晚了?”。

“我凌晨一点睡觉,也起晚了!”

“我们昨天计划好的会议。你接受了并准时下班。因此今天早上我很惊奇你为什么不在9点之前赶到。”

“是的。但是通常我来的有点晚。今天没想到车胎漏气了!对不起。”

我一直在听着他们的对话。我很震惊。毫无疑问,Sailesh没有组织概念。他只关心他自己的任务。他没有重视同事的时间。

会议又开了10分钟,最后Jim严厉地说,“Sailesh,你必须按照公司规定时间每天准时上班。如果你偶尔迟到30分钟或者一小时是可以的,但你一直这样,我们都知道你可以准时。我们是一个团队,不是一盘散沙。”

Sailesh离开了会议室。Jim找我聊了一会儿。我们谈到两个选择。第一个是找Sailesh谈谈,辅导帮助他理解他的强项与可改进的地方。第二个是,当然如果第一个不奏效,让他离开项目再进一步商议。

最后,过了几个月Sailesh辞职了。看起来他想要继续作为软件架构的个人专家。我不确信他个人是否可以成功因为他缺少合作精神。

回想一下,Jim和我是否可以有不同的处理方式。我们没有错吗?早期我们没有注意到或者把Sailesh团结在一起吗?如果再碰到类似的问题,我们会怎么做?

你的项目碰到过类似问题吗?你的解决方法是什么?

备注:为了保密,故事里的采用的是化名。


第一部分

“询问的力量:敏捷教练小提示”是我在印度金奈2012敏捷之旅的keynote演讲主题。我写这篇博客分享我的演讲重点。

我们先看看“询问”这个词。询问意思是探索、探查、调查、检查、分析、审查或者询问。它是关于搜索某事的信息或者做正式的研究。询问时教练辅导有力方式之一。敏捷教练与ScrumMasters可以通过理解询问的力量获得对团队正向的影响。

有效的询问包括有力的问题。我们可以学习到问问题的重要性或者询问的力量,爱因斯坦曾经说过-“如果我有一个小时解决问题,我的人生就依赖于解决方案,我会先花55分钟确定恰当的问题,因为一旦我知道了正确的问题,我会在五分钟内解决问题。”

在Dorothy Leeds的书《The 7 Powers of Questions》中说到,“问题 1)需要答案,2)激发思考,3)让我们可控,4)使人们开创,5)给出有价值的信息,6)引导有质量的聆听,7)使人们说服自己。”

这个情境下,我分享话题的日程。日程包含一整套问题!

  1. 为什么问有力的问题?

  2. 什么是有力的问题?

  3. 怎么样问有力的问题

  4. 如何保持带走的知识,保持联系,并分享辅导经验?

为什么问有力的问题?有力的问题

  1. 发起反思与富有成效的会话

  2. 使假设浮现

  3. 产生热情与活力

  4. 集中注意力与询问

  5. 包含更多的问题。

无力的问题正好相反!不会引发沉思与富有成效的会话,隐藏假设,活力衰竭,使人们消极。

我们可以区分有力的问题与无力的问题。下面的问题你怎么看?哪些是有力的?哪些是无力的?

  1. 我们这个迭代做的好吗?

  2. 你在做哪个用户故事?

  3. 你做单元测试了吗?

  4. 给测试人员提供高质量的交付物意味着什么?

  5. 还有什么风险我们没有想到?

  6. 我们现在看到的可能性是多少?

前两个问题明显是无力的。假设你是ScrumMaster或者敏捷教练。你想知道项目中正在做什么。参加每日站会!尽管这样,你问前两个问题吗?或者你试图继续有力问题的对话使你得到想要的答案。

第三个问题是封闭问题(是、否)。我们都知道最后三个问题是高质量的问题,有力的问题。这些问题使你思考、参与并找到答案。


第二部分

我们如何构造有力问题呢?我在读一篇Eric E. Vogt、 Juanita Brown 和 David Isaacs写的白皮书,有关“有力问题的艺术:催化深思,创新与行动”在2003年,这篇论文提到用“Which”开始的问题是无力的,封闭问题也是如此,或者答案为“是/否”的问题。Who, when, where比which有力一些,然而why how what帮助我们构造有力的问题!在所有一般情况下它们很有帮助。

注意!有时why, how what问题是有害的。下面有几个例子。

  1. 为什么我们还有没完成的故事?

  2. 什么让我们的员工总是在用即时聊天?

  3. 我们怎么能想到这么差的设计?

项目中总是有起伏。我们碰到客户报告的代码质量问题。客户发邮件给我们的项目经理。项目经理想要马上开会,指出问题并找到解决方案。

如果你是这个项目经理,你会问下面哪些问题?

  1. 我们对交付的代码质量满意吗?

  2. 我们什么时候对我们的交付最满意?我们如何做到的?

  3. 你最满意的写代码的方式是什么?

  4. 为什么我们的代码质量反馈总是起伏不定?

或者当你想要询问某个程序员这个问题时,你会选择哪个?

  1. 作为团队成员你是如何编写高质量代码,从而我们可以达到取悦客户的目标?或者

  2. 以你编写高质量代码的经验,我们如何能让团队编写相似的高质量代码?

顺便问一下,你认为Jim可能成为一个更好的教练吗(连接)?难道你不认为Jim可以问Sachin第二个问题,并让Sachin理解他自己真正的问题吗?

可以很肯定你的工作和项目中也有相关的例子。你有想过问题的范围与潜在的假设吗?是的。每个问题都有一个隐含或者显式的范围,也还有潜在的假设。


第三部分

当问问题的时候,我们透露了范围。每个问题都有一个背景,有一个隐式的或者显式的范围。为什么问题的范围重要?范围确实很重要因为它可以使问题适应背景,它澄清了目的,从而给问题增加更多的能量或者分量。下面做三个测试。

  1. 我们如何才能教组织里的每个人写出高质量代码?

  2. 为什么你不把“代码质量”当做我们业务单元的积极行动呢?

  3. 作为团队成员你是如何写出高质量代码,从而我们可以达到取悦客户的目的?

依赖于背景,问题的范围必须做出适当改变。否则,可能会导致令人震惊的体验。例如第一个和第二个问题不适合那些挣扎着确保项目质量代码的人。

在问题中也包含我们的假设。清晰的、有力的问题,假设也表露在外面。下面几个例子。

  1. 我们可以做些什么来产生高质量代码吗?(假设团队中没人写过高质量代码)

  2. 我们如何可以从其他项目团队学习关系编写单元测试与使用TDD?(假设你的项目中没人有相关经验)

  3. 为什么不工作了?为什么崩溃了?

  4. 你可以帮我推断这个情况吗?

问题暴露团队精神与目的。下面两个问题哪个更好?为什么?

  1. 为什么我们收到这些客户抱怨?谁负责的?我们哪儿做错了?有人可以解释一下吗?

  2. 我们可以从客户的邮件与现在的情形里学习到什么?什么是我们有的可能的方案?我们如何可以互相帮助以更好的服务我们的客户?有点子吗?

这些怎么样?

  1. 我们如何提高质量并比其他团队做的更快?

  2. 我们如何与其他团队协作并理解哪些实践我们可以采用并可以受益?

第一个问题包含竞争,而第二个问题鼓励协作。

变成协作的教练:变成协作的教练的第一步是真诚。问诚恳的问题,也是有力的问题。当诚恳的问题有力的时候,它们就带来诚恳的答案。 这是一个良性循环!我们再重复一遍!

  1. 诚恳的问题可以鼓励协作。

  2. 诚恳的问题,当有力的时候,会带来诚恳的答案。

  3. 这是良性循环!

构成有力问题的检查表:

  1. 这个问题相关吗?

  2. 问题诚恳吗?

  3. 我们想要从问题中获得什么答案?当我们问问题的时候可以触发什么类型的问题、对话或者感情?

  4. 这个问题有新鲜的思想、感觉吗?

  5. 背后隐藏什么信仰和假设?

  6. 这个问题会让我们关注于问题和缺点嘛?或者这个问题会产生希望、承诺、协作、行动和新的可能吗?

  7. 当探索最初的问题时,这个问题为新的不同问题留出余地了吗? 改编自Sally Ann Roth 1998年的公开演讲


第四部分

问有力问题的小提示:下面有几个提示关于开始并掌握问有力问题的艺术。

  1. 准备问题

  2. 移除无力的问题

  3. 预演

  4. 仔细查看检查表

  5. 应用

  6. 体验询问的过程并改进


最大的敌人:我们许多人用“我知道怎么做”的态度管理工作(也包含个人生活)。这个态度很好,也不好。当我们准备从多个来源学习时,这个态度是好的,检视并适应。当我们充满幻想时,这个态度就不好。我们最大的敌人就是幻想。当我们停止学习,问题可能保持破坏。这个时候经理变成破坏专家。他们的问题直接、挑剔的、有攻击性的、尖刻的和恶意的。我们不能忍受生活在知识幻觉中。你不同意吗?

对话与问题:问问题与回答问题是我们日常对话的重要部分。在 Part-1我们讨论过,因为这个原因,我们问问题。

问题可以是不同类型。有些问题帮助我们开始一个对话。有些问题帮助我们探索。有时候我们问假设问题寻求答案。有些问题从本质上带来反思。最后,为了结束对话我们问收尾的问题。 下面是几个例子问题。

开始:最近怎么样?今天我们要讨论什么?昨天和客户的会议怎么样?我们的项目你的关注点是什么?

探索:你能解释一下为什么这个工具很重要吗?我们第一次是什么时候看到这个现象的?观察结果是什么?

创建:(创建一个假设的情况)如果我们有数据库专家,这能如何帮到我们的项目?

反思:你能排列出前三或者前五个问题吗,因此我们可以让团队帮助找到共同的解决方案?

收尾:我们的行动计划是什么?我们的下一步是什么?什么时候你会和客户谈论这个?

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

评论(0

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

全部回复

上滑加载中

设置昵称

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

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

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