敏捷教练-第三章

第三章引导变化

有时，你可能正在介绍新的敏捷实践，或者你正在帮助团队更好地前进。不管是哪种情况，你都需要引导团队进行改变。这可不像告诉人们他们需求做什么那么简单。人们在他们努力做这些事情前，需要了解什么驱动他们改变。

所以，怎样才能让他们接受新的改善呢？一开始要慢一点：在给他们压力去行动之前，给他们时间去思考变化。给他们机会去学习敏捷。然后，通过问一些问题，吸引他们去设计变化，然后在他们的思想中进行构建。

3.1 Introducing Change（介绍变化）

   开始将敏捷引入团队时，你很快就会发现，人们产生了厌恶感。甚至有很强烈的原因是需要改变的，很自然他们关心到了风险。要向他们保证，做的更敏捷是很安全的。给他们讲你共事过的其他敏捷团队的故事，可以使他们能增强信心。

向他们展示你信任团队改变的能力。你信任他们成功可以给他们走第一步的勇气。要说“当我们。。。”而不是“如果我们”，然后，确信他们了解你就在那里给他们提供支持，而且一直帮助他们前进。

要小心：不要让一个团队改变得过快。要允许有充分的时间来学习。在执行之前，团队需要时间去充分讨论改变。这个给团队计划去思考含义和去理解他们如何做才能去调整他们现在做的。

Rachel Says. . .

Agile Is Not a Religion （敏捷不是宗教）

当心不要成为敏捷偏执狂，因为这个会适得其反，使得人们远离敏捷。不要欺骗那些没有使用敏捷的人们，把他们看成傻子，他们只是需要看到敏捷的优点！这是无礼的，人们只是不想听你夸夸奇谈。

你需要构建一些途径，帮助人们看清楚这些新的定律是如何起作用的。你甚至可以请一些人热心人加入，一起帮助你找到你的提议中的问题。

No One Listens to Me（没有人听我的）

Richard是一个高级工程师，他在团队中建议了很多过程改进。但是只要他到了团队，它就告诉别人他的主意.他开始抱怨：我很多年前就建议过了！为什么没有一个人听我的。

他没有意识到的是：你必须得做更多的工作，除了去建议人们按照你的行动去做。你需要去解释为什么这个是重要的，然后展示如何开始这件事情。

另外的事情是：别人听你说，但是他最终按照自己的想法去做。需求让团队建立足够的支持来试验这个事情。

Show Them How（展示给他们如何做）

让团队信服需要进行改变，是不足够的。你需要向他们展示如何开始改变。假设你建议一个团队进行单元测试，将帮助他们减少缺陷。不要奇怪一个人点头同意，但是没有人开始写单元测试，他们需要有人支持去执行这个变化：使用PrOpER环 (Section 1.4, How to Start Coaching, on page 27)去完成这个问题。

Rachel Says. . .

Be Open

我们读到的一些敏捷引导技术被标注上了标签“巧妙的”。举个例子，你可能故意做错，然后让和你一起工作的人出来纠正它。我建议避免这样的手法，而是使用透明的你正在做什么。一个不同的鼓励人的做同样事情的方法是说：现在，我已经写完几个测试，下面轮到你了

下面是一些你可以采用的方法

培训团队：安排一次室内培训课程，使他们都能学会如何写单元测试

演示：和开发人员结对，演示如何写单元测试

使其更可见：和团队一起制定一个目标（一天他们将写多少用例），在白板上跟踪进度

Sell the Problem（推销问题）

作为一个教练，你将遇到很多提升的机会。在你共享你的主意之前，要准备推销驱动改变的问题。仔细考虑一下，如果团队不进行改变，很有可能会发生什么事情。举个例子，你可以说：现在，代码还得进行bug修改，这个导致发布延期。我们让客户失望了，我们错过了发布时间。他们已经受到了管理层的压力。如果我们及时完成了另一次发布，我们就庆祝一下。

也没有必要描述得过于困难，你不需要让问题听起来难以克服。你仅仅是希望每个人都清楚的了解，为什么不改变会是一个问题。

如果你可以指出支持的证据，你推销问题会更有说服力。前面的例子中，如果你可以共享一些数据（代码如何阻碍开发发布），你的预测会更强有力。然而。注意不要批评团队工作的方式。作为一个教练，你的重点是过程改进，不是个人性能

Leveraging Resistance（改变阻碍）

Dale Emery写过一个非常有名的论文：把阻力看做是资源。在这篇论文里面，他谈到了你可能遇到的阻力的类型，以及如何响应这些阻力。

Dale警告我们：不要把人们的反应作为阻力。相反的，把每个反应作为你可以学习的信息。

当人们产生不想改变的反对和原因时，仔细听他们是怎么说的。尽量去了解他们的观点。对于一些事情，你能同意他们的观点吗？确认他们的关心点：一个改变需要花费时间，花费钱、或者很难做到。解释一下为什么这样做，不管怎样，你要一直认为这是个好主意，然后受益超过价值。举个例子，在check-in之前重构代码意味着实现每一个用户故事讲花费更长的时间，但是这个也意味着代码长期以来更容易维护。

Building Ownership for Change（为改变确定责任人）

一旦你说出了问题，现在是时候关注解决办法了。鼓励团队成员去接受提高敏捷过程的积极的方法。通过谈论改变的优点和缺点来建立共享机制。

让他们了解你知道的观点，邀请他们共享他们的主意。他们愿意怎样工作呢？他们看到他们的职业前景和构建更好的产品了吗？当这个主意是他们自己想到的时候，他们更愿意去遵循。

一旦他们开始进行回顾会议时，过程改进交谈变成了团队生活的有规律的一部分。我们使用过采纳敏捷的一个方法是把回顾作为第一个敏捷实践介绍给团队。回顾给团队提供了讨论问题的论坛，这里面包含了几周内的变化。(find out more in Chapter 13, Driving Change with Retrospectives, on page 192).

Liz Says. . .

Pick Your Battles

理论上，你能看到成打的可以提升的问题和计划。但是如果你谈论所有你看到的问题，你将会被看做是消极的，人们很快就不会再听你的了。

你需要产生影响，让他们按照你的领导去做。Kent Beck是这样做的：从小的变化开始。现在就做一件事情，其他的以后做。所以，就选一个问题和团队一起工作，专注于去解决这一个问题。

Make Change an Experiment（把改变当做一次尝试）

当你遇到阻碍时，建议你把这些困难看做是一次尝试。把改变当做尝试，帮助让团队聚焦于受益，因为你需要讨论如何评价这个尝试是否是成功的。如果他们能度量这个提升，给了团队继续下去的理由。

你需要了解这样一个秘密：一旦一个团队全身心投入，努力去把这个变化当做了尝试，团队成员开始习惯这种新的工作方法。现在，回到原来的工作方法也是一种改变，他们会犹豫的。你将会注意到，他们采取的每一次改变都会减小下一次改变的阻力。因此，开始让团队远离一些小的改变，例如重新设计工作空间或者进行有规律的团队午餐，直接开始更大的改变吧、

3.2 Asking Questions（问问题）

你引导团队时，另外一种认为改变是简单的方法是问问题。当你问别人一个问题，你表现出你尊重他们的观点，并且对他的答案感兴趣。他们需要运转大脑来想答案。当他们这样做的时候，他们把你的需求连接到了团队如何工作上。一个能够引起思考的问题，甚至能够让他们跟上你的谈话并且采取行动。

下面是一些很有用的问题，你可以询问：

l  阻止下次发生这种问题，我们有什么办法呢？

l  我们怎样做，才能及时完成

l  我们如何做，才能更有效呢？

Challenge assumptions.

人们经常被自己强加的信任给阻碍。你可以使用问题去挑战他们的信任，关于组织是如何工作的，他们能做什么、不能做什么。是什么阻止他们不能做他们认为正确的事情？如果你得到这样的答案“管理者不让我们做”，那么再去获取更多的信息，谁是管理者？他们如何知道是管理者不让他们做？帮助他们了解，他们做了还没有被验证的假设。

Are Rules Really Rules?

by Rachel

有时一个团队调整，不是想试着进行改变，而是因为公司的政策。这个政策是否是个规则，这个是值得再去检查的。

我一起工作过的一个团队，有1个过程改进组，他们在另外一个办公室工作。过程改进组在公司内网提供了一套文档模板。团队相信他们必须使用这些模板，这个是他们不能开发新故事的原因。

我打电话给过程改进组，问他们使用这些模板是否是强制的。令人惊奇的答案是，模板只是另外一个工程提供的例子。没有需求说必须使用模板。

Ask open-ended questions.

你怎样问问题呢？不要问关闭式问题，这样的问题只有YES/NO答案或者基本信息

答案。相反，要问开放式的问题例如：“如何？”和“将发生什么？”，这样开阔谈话，然后邀请人们表达和共享观点。

小心，不要问“为什么”，因为当你没有这样打算做的时候，但听起来好像你在批评他们。举个例子，“为什么你做那个？”听起来像是指责，然而“你将打算做什么”听起来更友好？“为什么”趋向于是关心问题，而不是关心解决方法。关心提高比关心什么导致了错误更实用。

仅仅当你真的对答案感兴趣时，才问问题。如果你点头同意，这个表明你在找更特别的答案，这个看上去像是受了多大恩惠似的。所以，如果你在找更特别的答案，不要以问题作为会谈的开始。

What to Ask（问什么）

有很多类型的问题。下面是一些有用的问题，你可以来问

Ask for Help（寻求帮助）

一个吸引团队改变的方法是出来请他们帮助-不是正规的方法在团队会议上，而不是一对一在休闲时间。告诉他们一个你和他们面临的问题，寻求他们的帮助。他们可能会提供主意、支持、或者一些实践。大多数人喜欢帮忙，也很高兴你能请求他们帮忙。

Thinking Questions（思考性问题）

记住，必须是团队自己思考问题，不是你。你可以通过问思考性问题，来促进他们的思考。

在Quiet Leadership: Six Steps to Transforming Performance at Work中，David Rock声明：当你引导的人带着问题来问你，最有用的问题，如下：

l  你思考这个问题多久了？

l  你思考这个问题的频率是多少？

l  你满意你对这个问题的思考程度吗？

l  你能找到思考中的不足吗？

l  你有什么领悟吗？

思考问题鼓励人们去做思想上的改变，以战略的水平去思考问题。当你问一个思考性的问题时，帮助他们冲出问题的细节，从不同的角度来看这个问题。记住，然而，当人在压力下或者感情脆弱时，思考可能会锈住，因为他们思想不集中、会没有心思去想这个问题。

Reflective Questions（反射问题）

后面，要通过问问题，鼓励团队注意到更多的如何来进行工作的。假设你想提高他们对站会变化的意识，你后面可以问题他们在会议中注意到了什么，你可以简单的问题：今天的站会中你注意到了什么？或者你可以深入地问类似下面的问题：会议流程怎么样？有人更新白板上的任务吗？今天和昨天相比会议怎样？

共享你自己的观点，可以帮助他们理解你对那些事情感兴趣。举个例子，我注意到今天干扰很少，会议的流程看起来更好。我在想是不是因为Yuan从家里打电话，我们不得不用电话和她说话。看起来我们正在用电话作为谈话的语调。可能，在她回来之后，我们应该在站会上使用这种谈话的语调？

Five Whys

5个why是Taiichi Ohno介绍的一种技术，可以用来进行团队的根源分析。当使用5个为什么时，要确保你能够解释你在做什么：你在使用一个技术，而不是因为你对答案不满意而重复同样的问题、

开始的时候，问表面的问题。得到一个解决方法，然后通过问什么造成了这个表面问题来继续深入，什么造成这个问题，什么造成这个问题。到你问了5次why然后为止，你应该得到了造成系统问题的真正的问题-例如给顾客的不切实际的承诺或者没有投资培训团队。

下面是个例子

Why1：为什么昨天没有让软件运行？

我们有太多的需要讨论的错误

Why2：为什么我们有太多的需要讨论的错误

因为当测试人员发现他们的时候，他们就放入了bug跟踪软件，没有告诉开发人员

Why3：为什么测试人员不告诉开发人员？

因为开发人员正在忙于做其他事情

Why4：为什么开发人员和测试人员不一起工作？

因为测试人员不得不对所有团队所用，不仅仅是这个团队

哦！这个才是阻止团队前进的关键问题。这个过程需要改变的问题，如果团队有全部投入到团队的测试者，而不是整个公司的测试者，就会发现问题更快，修复问题更快，及时给他们一个前进的更好的机会吧。

Why5：为什么没有足够的测试人员，使得每一个团队都有自己的测试者？

因为我们不能负担起更多的测试人员

 

现在，我们找到了为什么团队昨天不能前进的原因之一，因为公司没有那么多的钱如雇佣更多的测试人员。

5个why是一个强大的技术，然而，他也能揭露出超过团队控制之外的问题，不得不把问题上升到组织级别

 

When Not to Ask Questions（什么时候不问问题）

当你实际上是想给指导的时候，记住不要问问题。如果你问一个问题，你不得不接受答案，即使你不同意这个，这个会使得你希望给的建议更加困难。举个 例子，如果你问：你们怎样能更容易的找到这个bug呢？他们回答：通过做更多的手动测试。这就更难指导他们去做自动化测试了，因为看起来是你在纠正他们。

如果你一直在问问题，那么看起来好像你在伸手去要东西，而不是共享你所知道的。这个会让人怀疑你的真诚，可能他们对你会不公开。记住，如果别人不相信你关心答案，问一个问题看起来好像是你在挑错。他们可能认为你在到处找不归你管的问题，然后拒不开口。

Feeling Manipulated by Liz

一次，我遇到这样一个项目经理，他不满意我做出的不去修复bug的决定。他不是站出来说他不满意我，他说：难道你不想人们认为这个项目更成功吗？他的问题让我很生气，因为他想控制我去做他想要的，而不是尽力去理解我的理论。如果他这样问我：你为什么不修复bug，我可能会更感激他

当你和一个人之间的信任不高时，问问题可能没有帮助。他们可能对任何问题都有防御，你不太可能从他们那里得到一个诚实的答案。如果你不能让他们放松、使他们相信你真的关心他们的观点，就别问问题，因为这可能会造成更多的伤害。相反，直接的公开的，共享你的建议，可以让工作更和谐。

 

3.3 Encouraging Learning（鼓励学习）

在采用敏捷实践之前，团队需要时间去学习。鼓励他们在计划中安排学习时间。举个例子，如果团队想实践敏捷实践例如TDD，他们需要在执行之前安排时间去学习如何来做、

没有必要滴注式给团队灌输敏捷经验。不是让团队依赖你作为敏捷学习的来源，而是鼓励他们自己主动地去学习。

Study Group

一个学习群组是一个非正式的有规律的会议，一小群人讨论一个问题或者一本书的一个章节。五到十个人每周开会。

可以在午餐时间、或者在工作后、如果公司支持甚至可以在工作时间，和团队一起开这个会。人们可以带自己的午餐来，或者你能说服管理者买三明治或者披萨。每周，会议的组织人员都要更换。典型的，她展示一本书的章节，然后整个团队讨论。会议很小，每个人都能参与讨论，而不是听从一个人演讲。

会议能够开得很好，有以下几个原因。没有老师或者专家出席，这个使得每一个人都积极地参与，然后得出自己的结论。人员通过阅读和讨论学习到更多，比一个人阅读学习到更多。

学习小组不仅仅是得到更多信息的一个方法。他能给人们提供更多的支持去实践已经讨论的实践。举个例子，在学习小组讨论过结对编程和建立自动化开发后，学习小组的人会被激励去试着做这些。不是通过孤立地读这些概念，他们知道他们被学习团队所支持。

Creating Learning Opportunities（建立学习的机会）

敏捷实践一直在进化，所以你和团队需要跟上现在的状态。有许多不同的方法学习敏捷。努力让人们学习到敏捷变得更容易。例如，建立wiki网页，创建书、论文、博客的有用链接。

在你希望看到别人也这样做之前，要先做好榜样。让团队看到你花时间学习，然后和他们谈论你学习到的新事物。

一个很有用的介绍新方法的方式是：安排组织中的人讨论敏捷经验。这个给你的同事创造了展示他们所学的机会。这个提高了他们在公司的地位、给他们在公共演讲中的机会。在工作中的讨论是在公开会议上讨论的第一步。

Tech Talks by Liz

我工作的一个公司进行“技术讨论”，这个是以大的技术开始的。团队把他们做的工作展示给更大的组织。后来谈论的话题变得更宽了，我们讨论我们所关心的销售部分、谈论CEO的愿景、谈论界面设计，等等

你可以通过邀请一个专家来做演讲来制造兴趣。如果你知道一个著名的人将要来你

所在的城市，不要害怕不去叫他。他们可能很感兴趣能扩展他们的人脉、很高兴来参加，特别是你在会后给他们提供啤酒或者晚餐。你可以从本地的敏捷组织中邀请一些人来，请他们讲一些敏捷在他们的组织中是如何起作用的。

你可以通过参加、预定会议室、发邀请、邀请讲演者、预定午餐等等，来支持团队参与学习团队和演讲。通知团队去出席，然后研究他们，特别是在讨论的时候。

Going Outside the Organization to Learn（到组织外去学习）

会议是一种让团队接受新方法的很好的方式。他给有同样问题的人们提供了机会，共享经验、得到支持。对于在组织中待了很久的人，出去参加会议可以扩展眼界。

把让人们意识到如何找到参加会议的资助作为你作用的一部分。当一个人参加了一个会议，鼓励他把在会议上学习到的和其他人分享。在他们去之前，就向他说明这个需求，这样他们就能密接留意可以回来向团队分享的好方法。

你的团队也可以在本地用户群组找到支持、学习到新的方法。不是仅仅让他们知道下一个敏捷会议室，你可以让他们知道你将去并且邀请他们一起去。

3.4 Facilitating Meetings

一旦团队打算试验一个机会，不要把他们扔进深渊，让他们自己挣扎。当引入一个新的实践时，给他们展示如何做。

首先团队试验一个敏捷会议，例如回顾会议或者计划会议，提供一些使会议召开得更顺利的方法，展示如何召开会议。在会议中，解释给团队这个过程，使得他们学习到如何让会议召开得更顺利。下次的时候，坐下来和其他人（将要开会的）一起计划这个会议，然后在会议中，作为后盾。如果会议偏离轨道，你要站出来，直到会议结束，要给你引导的反馈。

通过给予过程中的评论，告诉他们你的思考过程。你可能说：我注意到我们现在已经停在这里一个小时了，有点太沉闷了，休息一会吧。或者：Darren，你今天的想法可真多，可是我注意到Alison没有共享他的想法。Alison，你有什么要说的吗？

下面有一些提醒，可以让会议更有效

Choose a time(选择时间)：为整个团队建立一个会议时间，给他们足够的准备时间

Set up the space（准备空间）：考虑会议需要什么样的空间。避免会议室有很大的桌子，因为这个会让团队距离太远、不能看清楚桌子上的卡片。你需要一些东西记录笔记，例如图表或者白板。

Focus the meeting(聚焦会议)：开始时，要清晰地阐明会议的目的，对会议议程给予一个快速的介绍。提醒团队需要达成一致或者遵守会议的基本规则

Keep it flowing：会议中不要跑题，确保会议中的谈话不跑题，并且是有成效的。当你作为一个协调者，你的目标是使得会议开得更容易，就像发动机中的油一样。你让会议继续进行，聚焦于产生有用的输出。如果你没有参与到讨论中，跳出来站到中立的位置，这个很容易做到。如果你需要提供一个观点，那么明确地你要跳出协调者的角色

Encourage everyone to participate（鼓励每个人参与）：要确保每一个人的观点都被听到。这个意味着同一时间只能有一个人在谈话。当有人做更广的归纳时，需要帮助问更多的例子、询问更清楚的问题，来找到细节

Summarize key points（总结主要观点）：在你在白板上写下任何观点之前，通过重复你听到的，检查一下你是不是真的理解了这个观点，

Close the meeting:（关闭会议）：当你把会议关闭时，确认输出已经被适当地记录了。拍照片是一个很快的方式，去记录白板的草图和会议笔记

为了下次能有提高，需要对你协调组织的会议进行反馈。你可以在会议结束时，问每一个人的建议，也可以问别人看到你是怎样组织这个会议的，然后在会议结束以后，和团队讨论改进。

3.5 Hurdles

下面是一些你可能遇到的障碍

Some People Don’t Change（一些人不改变）

一些人喜欢首先尝试新东西或者拥有最新装配。其他人喜欢当完全有必要时，才最后尝试新东西。不要停止住劝说落后者。他们愿意最后采纳新的工作方法。当敏捷成为新的现状时，他们最终是会改变的。

Bumping into Company Politics（遇到公司政策）

当你引入改变时，你有时被认为是对已经存在的权利的威胁。这个使得你撞到了公司的政策。

不擅长工作的人很有可能被暴露出来、一些人，例如项目管理者或者架构成员，可能甚至相信他们的工作受到了威胁。小心这些误解，这些需要被暴露出来。

一个受人尊敬的技术领导或者管理者可能是团队更敏捷的阻碍者。如果你过渡地批评他们，对你是没有帮助的。在公共场合不同意他们会破坏他们的地位，使他们丢脸。相反，花些时间了解他们，这样你就能了解他的观点。然后通过让他知道你的计划，你去通过你的思考方式去赢取他们，最后你能获得支持。

你也要关注，你不能和技术领导或者管理者太过于紧密。如果你有更高的赞助人，特别小心，不要太支持这个人、加强他的喜好和不喜欢。这个人已经有权威。要清楚地了解，你不是管理者的间谍，你是为团队服务的。

Conflicting Agendas（矛盾的日程）

有时，当有人寻求帮助时，你很难保持你的关注点。举个例子，有人过来向你抱怨不允许他在墙上贴东西。你同意这是个问题，但是现在不是合适的时间来解决这个问题。

在公共场合，尽量保持中立，然后解释私底下说你在进行工作，这样做避免得到消极的声誉。解释这个问题你正在想解决办法，并且寻求他们的帮助。

然后，你可以和他们一起工作，制定一个引入变化的计划或者同意这是一个战斗（但你在这时不能和他们一起工作）

3.6 Checklist

贡献你对敏捷的热情，不是狂热。谈论他，展示他，主动帮助其他人用敏捷。鼓励和激励团队，敏捷是可以起作用的。

向团队推销你的问题。帮助他们看到为什么他们需要改变。待在现状会有什么样的长期的问题？也和团队成员分别来谈论。他们每个人从变化中得到了哪些好处？

当你遇到阻力，努力去理解阻力是从哪里来的。是问题本身还是你展示的方法？关于被提议的建议，有好的原因继续去坚持吗？他们仔细地听他们关心的内容了吗？

问问题来鼓励团队提高他们的敏捷过程。去寻求帮助来赢得支持，问思考性的问题获取反馈，使用五个why来进行根因分析。

鼓励不同的方法来学习敏捷：离开书本，在办公室里，共享你读到的博客、人们播客上的观点、组织报告会和学习群组，对组织中的其他团队公开。让别人了解即将到来的敏捷事件，带别人一起去当地的敏捷用户社区。

第一次帮助他们开会，使得新的会议变得更容易。给他们开会过程中的评论，这样他们就能听到你在运行会议时的思考过程。下次，帮助团队准备会议，会后给他们反馈。