Kanban Change Leadership作者访谈

在 Klaus Leopold和 Sigi Kaltenecker合著的 Kanban Change Leadership书中，他们研究了如何在组织内部署 Kanban以完成变革，和建立持续改进的文化。

InfoQ读者在 Wiley上订购 Kanban Change Leadership时，可以使用优惠码 VBJ24享受25%的折扣。该优惠码仅限2015年使用。

InfoQ有幸采访了 Klaus Leopold和 Sigi Kaltenecker，主要关于循序渐进地实施变革、解决问题、从使用限制在制品中获得的优势、Kanban中服务的优先级和级别，使用 Kanban约束理论，和使用 Kanban变革方法获得成果。

InfoQ：您为什么写这本书，本书的受众是哪些？

Kaltenecker：我们希望通过组合 Kanban的技术知识（实践和工具）和动态变化的心理洞察力（演化变化管理原则）提供一套领导力的整体方法和系统观念。同时，我们尝试让它尽可能地像一本食谱。这就是为什么我们提供了大量的工具兼有案例研究，用来举例说明在你的日常业务中这些实现看上去像什么。

因此，我们的目标受众是 Kanban初学者以及寻求进一步改进的从业者。此外，本书为忙于组织变革的人提供了新的冲动。

InfoQ：Kanban建议循序渐进地实施变革，并专注让这些变革步伐取得成功。您能解释一下为什么？

Leopold：我认为变革步伐的大小完全取决组织的主观情况。只有 Kanban的第一条实践“可视化工作”可能对某个组织而言是巨大的一步，对另一个组织而言可能什么都不是。更不要说限制在制品、流程和反馈环。我认为当涉及到变革时，这正是关键所在：并非所有的机构都是一样的。Kanan尊重组织现状，你可以独立地决定你的变革步伐应该多大。这就是变革的艺术——找到正确的剂量。我自己不喜欢引入过多的变革，这会导致组织过度紧张，我想 Sigi对此看法是一样的。

Kaltenecker：基本上，与大型变革相比，小步伐的变革压力更小，并且更加可能成功——这是一个值得的权衡取舍。这是一种实验研究法，为了尽可能快地学到经验教训而尝试的小试验。如果实际数据表明我们的试验是有回报的，我们将会进行更大范围的相同试验。如果不是，我们尝试一些新的试验。这种精益方法有个令人欢迎的副作用：整合新信息的机会不断地出现。我们绝对不希望将我们的变革努力建立在大规模的先行设计和计划驱动实现之上。

InfoQ：您怎么保证未来这些小步伐会将你们带到目的地？

Kaltenecker：依托快速反馈环系统。当然，持续改进依赖定期检验和基于实际数据的调整周期以及开放性交谈。谁又知道两个月或者三个月后我们的现状是什么？此外，生活在如此一个动荡的世界里，我们又如何保证我们未来的现状？不如跟随较小的步伐迈向更短的变革周期，并在开始新的变革前完成它们。

InfoQ：在书中您建议“在开始新的工作之前，先解决问题”。这听起来合乎逻辑，但是我看到人们很难做到这一点。您看到的是否一样？

Kaltenecker：是的。这些天我看到为了完成某些东西，面临很多压力，——通常是不惜代价，甚至没有意识到为了支持权变措施和症状治疗，我们在基于根本原因分析的对策上浪费了多少时间、金钱和动机。毫无疑问，我们谈论的也是文化问题，因为许多组织的 DNA几乎仍然是由推动（push）原则驱动。

Leopold：同意。这种习惯很难建立。不过，我有一些好的经验可以用来量化这些问题的影响。如果人们看到你经常关注的问题产生经济影响。这里有一个强大的技术：拦截器集群（Blocker clustering）。Troy Magennis和我就这一技术写了一篇InfoQ文章：Using Blocker Clustering, Defect Clustering, and Prioritization for Process Improvement。

InfoQ：您有什么建议，可以使其成为解决问题的一种习惯？

Kaltenecker：根据我的经验，定期培训是实现这一目标的唯一途径。正如运动员经常做的：为了成为优秀的运动员，他们一遍又一遍的练习相同的习惯。他们在经验丰富的教练的指导下练习，教练根据数据给他们提供精确反馈和改进思路。有了这个反馈的帮助，运动员最终才能建立正确的运动习惯。我认为在知识工作方面我们也应该这么做——正如我在新书 Leading Self-Organising Teams中提倡的口号“领导力就是一场团队运动”。

Leopold：让我来引证 Sigi：“运动员与管理者之间的区别是运动员大量的锻炼仅仅是为了为数不多的竞争比赛，而管理者总是处在竞争之中，却从来不实践”。

InfoQ：您能详细说明团队能够从限制在制品中获得的优势？

Leopold：哇哦，这是一个很难回答的问题。让我们来做一个简短的经济考虑：如果你有10个项目，但是只完成了10%，那么你就不能为你的客户创造任何价值。但是如果你有一个项目，已经完了100%，你就创造了价值。我想“开始新工作前完成老工作”（stop starting, start finishing）的口号就是一个很好的总结。Sigi，发挥你快速总结的特长。

Kaltenecker：为什么限制在制品？这是我在10秒内想到的最好答案列表：限制任务切换可以减少压力；更好地专注将要完成的任务；更快的工作业绩；更好的工作流程和协作；更好的产品和/或服务质量和更多的工作满意度。这是你可以从一些排队规则中获得的优势，我认为还不算太坏。

Leopold：并且，还有两个有关限制在制品更重要的事实：（1）限制工作项目可以为你的客户创造价值，和（2）总是试图限制更大型的项目。Ad 1：Kanban并不是拥有限制在制品功能的任务板。你应该希望通过你的系统追逐价值而不是任务。Ad 2：如果在你的系统内拥有无限的项目，那么限制史诗有什么意义呢？如果在你的系统内拥有无限的史诗，那么限制用户故事又有什么意义呢？等等……限制更大的！我知道这更加的困难，但是这更加的有意义。

InfoQ：您能详细说明服务的优先级和级别之间的区别？

Leopold：正如书中所描述的，服务级别的想法是为了对工作项目的紧迫性和影响做一个陈述。这个想法是这样的，Kanban系统的利益相关者就业务影响找出一个共识，当影响发生时，有了这个共识，就能够更加容易地决定继续哪些项目。这一主题在本书中只有非常简短的概述，因为本书的重点放在了“开始做某件事”方面。不过，好消息是，目前我正在准备我的下一本新书，新书中我对工作系统的风险因素投入了更多的关注。

InfoQ：您有使用 Kanban约束理论（TOC）的案例吗？

Leopold：我喜欢用 TOC作为一种思维模式。我认为这是有用的工具，可以用来了解瓶颈，理解信息——充分利用可能不是管理知识工作最明智的方式。每一个系统都有自己的瓶颈，在瓶颈处理之前，开始更多的工作是没有意义的。可能当我们6岁的时候，我们就已经接触过瓶颈了，那时我们尝试将沙子倒进漏斗。“哦哦哦哦哦……它溢出来了，”可能是我们当时的惊讶反映。是的，它溢出来了！正如我们所知，系统的生产能力是由其瓶颈决定的。这在这个星球的每一处都是正确的——当它涉及到我们的工作系统时，我们才对它产生质疑。但是，这也适用我们的工作系统！这是没用的……

• 分析更多比你能开发的东西；
• 开发更多比你能测试的东西；
• 测试更多比你能交付的东西；
• 等等。

我觉得 TOC能够帮助理解这些信息。所以，这不是将 TOC应用到知识工作中——更多的是理解基本原则。在知识工作中，我们必须处理移动的瓶颈或者专业化的瓶颈。我不确定在这些情况下，TOC是否是摆脱瓶颈最好的工具。然而，它仍然有助于理解基本原则，因为瓶颈就是瓶颈，不管它是固定的还是移动的，不管它是由容量限制、非现实可用、或者专业化引起的。如何处理瓶颈的行动可能会有所不同。

InfoQ：在书中您解释说，当开始 Kanban计划时，需要更深入地理解目前存在的问题，你必须为你的组织设计 Kanban系统。您还提到 Kanban就是以循序渐进、有价值的步奏实施演化改进。您是如何平衡这一点的，并确保非常快地从使用 Kanban中获得成果，从而让人们留下参与这一计划？

Kaltenecker：一旦你理解引入 Kanban意味着开始一个变革计划，而不是一些技术的适应性改造，你就可以使用21世界所有可用的好的模式。例如，建立一个变革团队作为一个指导性联盟，探索利益相关者示意图是什么样子，与最重要的利益相关者沟通，与他们运行一些简短的回顾性访谈并提供你获得的经验教训的反馈。从我们与不同客户接触的经验看来，你不需要花费数月的准备时间，因为这些可以在几周内完成——定制系统所需的一切可以很快获得。

然而，最好的事情是你循序渐进地创造价值，因为每一次单独对话都是改进你和利益相关者之间关系的手段。你可以建立更多的信任，共享知识，确保更好的理解等等。另外，价值的透明保证了每个参与的人都非常清楚怎么回事。

InfoQ：让我们假设组织希望能够更快速地交付软件解决方案。您能给出 Kanban是如何帮助他们快速提交软件解决方案的案例吗？

Leopold：对于这个问题，我认为没有常规答案，因为 Kanban不是一个革命性方法，它不会告诉你如何正确地做。Kanban方法能够使现状更明朗，鼓励你根据精益指导自己思索。Kanban是疗方，不是药品。

然而，当然，当涉及到更快速交付软件解决方案时，也有一种模式。目录中第一个主题其中一个就是，让等待时间可视化。人们会看到大多数工作项目（比如特性、用户故事等等）的交付周期都是等待时间。这意味着在你的系统的大部分时间里，没有人在从事工作项目，而是无所事事等待更好的时间。所以当我们讨论更快速地交付软件时，通常说的不是更快地工作——那只是一个很小的控制杆。我们说的是消除工作项目的等待时间。

如果我们假设，我们在企业的软件开发部门开始我们的 Kanban旅程，下一步很可能就是将其扩展到上游部门，因为通常上游部门又会再次有很多的等待时间，因此，有巨大的潜力可以加快交付软件解决方案。至于扩展 Kanban，我建议大家参考另一篇InfoQ文章：Can you Scale Kanban?

关于受访者

Klaus Leopold是一名计算机科学家，拥有帮助不同行业组织使用精益和 Kanban改进的多年经验。他是 Kanban改变领导力的合作者（由 Wiley于2015年出版）。Klaus是全球范围内第一批精益 kanban培训师和教练。他在 Kanban社区内被授予2014年 Brickell Key Award for outstanding achievement and leadership。Klaus还是 management network Stoos的创办会员。他的主要兴趣是团队层面外的敏捷，尤其是大型项目和30到500人的程序集。他在 他的博客上发布了他目前的想法，你可以在Twitter通过@klausleopold关注他。

Sigi Kaltenecker是 Loop Consultancy in Vienna的联合总经理，帮助个人、团队和组织成功地征服他们的职业挑战。他是经过认证的 Scrum Master，Kanban教练，和 PAM合作编辑。Sigi撰写了“Leading Self-Organising Teams”，这本书于2015年在英国出版。你可以通过@sigikaltenecker联系到他。

查看英文原文：Q&A on Kanban Change Leadership