4

Bob Jiang 敏捷培训 敏捷认证Scrum Master

 3 years ago
source link: https://www.bobjiang.com/powerful-question-scrum-master-coaching-tips/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Scrum Master角色和敏捷教练相关内容 - Scrum指南

最近我复习了一遍Ken Schwaber和Jeff Sutherlan共同开发和维护的 “Scrum指南”。 (其实我已经复习过很多遍了)而这次我集中于 Scrum Master的角色和涉及“教练”方面的内容,下面是我的一些发现:

Scrum Master服务于开发团队的方式:

  • 指导开发团队自组织和跨职能
  • 指导开发团队采纳与理解Scrum的组织环境

Scrum Master服务组织的方式:

  • 带领和指导组织采纳Scrum

关于敏捷教练和Scrum Master这两个角色的详细说明,在我之前的一篇博客中有描述。

敏捷团队中的提问

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

以下人名均为虚构,如有雷同,纯属巧合

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

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

在项目早期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团结在一起吗?
  • 如果再碰到类似的问题,我们会怎么做?
  • 你的项目碰到过类似问题吗?你的解决方法是什么?

提问的艺术:敏捷教练技巧

“提问的艺术:敏捷教练技巧”是我之前的一个演讲主题。我写这篇博客来分享我的演讲重点。

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

有效的提问包括有力的问题。我们可以学习到问问题的重要性或者提问的力量,爱因斯坦曾经说过 - “如果我有一个小时解决问题,我会先花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. 我们现在看到的可能性是多少?

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

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

如何构造有力的问题 - 提问的技巧

我们如何构造有力问题呢?我在读一篇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. 当探索最初的问题时,这个问题为新的不同问题留出余地了吗?

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

  1. 移除无力的问题
  2. 仔细查看检查表
  3. 体验提问的过程并改进

应用有力的问题过程中最大的敌人

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

提问的艺术总结 - 敏捷教练技巧

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

问题可以是不同类型。

  • 有些问题帮助我们开始一个对话。
  • 有些问题帮助我们探索。
  • 有时候我们问假设问题寻求答案。
  • 有些问题从本质上带来反思。

最后,为了结束对话我们问收尾的问题。 下面是几个例子:

    • 最近怎么样?
    • 今天我们要讨论什么?
    • 昨天和客户的会议怎么样?
    • 我们的项目你的关注点是什么?
    • 你能解释一下为什么这个工具很重要吗?
    • 我们第一次是什么时候看到这个现象的?
    • 观察结果是什么?
  • 创建:(创建一个假设的情况)

    • 如果我们有数据库专家,这能如何帮到我们的项目?
    • 你能排列出前三或者前五个问题吗,
    • 因此我们可以让团队帮助找到共同的解决方案?
    • 我们的行动计划是什么?
    • 我们的下一步是什么?
    • 什么时候你会和客户谈论这个?

所以通过本问题,你最大的收获是什么? 你会如何应用这些收获? 你会采取什么行动?

欢迎在下面留言提问与讨论。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK