当组织进行规模化敏捷,并想把看板作为一种敏捷方法应用的时候,问题就来了,可否规模化看板?Klaus Leopold在 中欧2014精益看板大会 上演讲的 规模化看板 中进行了这样的解释:看板本身就具有规模化的能力,所以从严格意义上来说,这一问题的答案不可能是“否”,因为规模化看板仅仅是当前状态的一步改进。规模化看板意味着运行更多真正的看板,产生更多的改进。
在敏捷组织中,所有的团队都应该使用敏捷方法,这是一个误解。有许多不同的方法可以使用,团队必须应用对团队有效的方法,并且根据他们的情况进行调整。Klaus表示,组织就是一个活生生的社会系统。团队在组织中并不是孤立的,他们互相连接,并通过交互产生价值。
InfoQ采访了Klaus,谈论了用看板管理项目集,在团队和项目集层面部署和连接看板板,在完整的交付周期中管理进行中的工作,以及看板带来的好处。
InfoQ:您谈到应当不断适应现实的工作环境,而不是去适应一个蓝图,您可否举一些例子呢?
Klaus: 在《爱丽丝梦游仙境》中有一个场景,兔子说,“为了能够站住,你必须跑的非常快。”我认为这个例子很好地解释了今天的商业现实。如果你不能不断地调整工作环境来适应一直变化的环境,那么这个世界就会把你遗忘。不幸的是,我没有那么聪明,可以提供一个包括多种实践的蓝图,能够适用于大千世界的所有组织,并让他们在市场上获得成功。我深深地相信,每一个组织必须自己找到答案。
这方面最好的一个例子可能就是日本丰田汽车,他们允许竞争对手进入他们的工厂,并演示给他们如何生产汽车。可以参看如Mike Rother编写的《 丰田套路 》一书。尽管很多公司照搬丰田公司的实践,但没有一家公司能够像丰田那样成功。所以,这完全不是采用别人的最佳实践和解决方案就可以成功的,实践仅仅是对包含多个改善步骤的学习循环的表现。如果你采用别人的解决方案来解决你的问题,那么这个解决方案不能解决你的问题也就不奇怪了。
InfoQ:在中欧精益看板大会上,你谈到在某个软件开发项目中使用了看板,他们为什么决定用看板?
Klaus : 我谈到的这个组织几乎在复杂的世界里迷失了。在这个项目中有大约200个人,他们想要完成共同的目标,但他们完全不知道该怎么做,也不知道他们的现状如何,以及他们是否可以达到目标。他们想保持尽可能的最小且无痛苦的变革,因为人们只是厌倦了正在进行的组织变革浪潮,这种浪潮冲击了他们的头脑。他们的想法就是保持团队的正常工作,并且不在变革方面对他们产生太多干扰。所以第一步我们只是想更好地协调团队意见,确保他们在正确的时间做正确的事情。
你可以把公司比喻成一个键盘,每一个按键代表了一个团队。如果你要给客户写一封信,你不会想对团队的有效性进行优化,从而让键盘上的按键按得更快。这几乎不会带来任何更多的产出。当在写一封信的时候,更重要的是你在正确的时间按下正确的按键。当你的公司创建的价值依赖于多个团队的时候是同样的道理。
当你在这个飞行水平(Flight Level)开始你的改进之旅时(参见 看板和它的飞行水平 和 为什么看板飞行水平 ),团队不需要在他们的工作方式上进行很大的改变。实际上,团队是用看板还是Scrum,或是其他的方法都没关系。跨团队基本的建立流程是确保每个人在正确的时间做正确的事情。
InfoQ:您可否详细阐述一下看板是如何引入到这个项目中的?
Klaus : 这是一个很大的问题。我来尝试概括最重要的事情:在开始的时候,我们组建了一个跨功能和层级桥梁的变革团队,由他们引领变革。他们是有关变革疑问的主要联系人,并且主导引入变革的所有活动。变革团队所做的第一件事情就是 识别干系人并理解真正的问题在哪里 。有了这些信息,我们就可以准备系统设计的工作坊。团队提名代表来 设计看板系统 。
在开始的时候,我们整个团队只有一个用于协调的看板系统。后来,越来越多的团队决定在团队层面使用看板。这是非常棒的,因为是团队拉动了变革 -- 没有人告诉他们必须要用看板!当然,我们完全支持他们的决定。
InfoQ:为什么团队建立自己的看板板很重要,而不是建立一个标准板?
Klaus: 我认为很大一点原因是主人翁意识。当我建立了 我的 系统,我会理解它的意图以及如何工作。所以,如果有些地方没有预计那样有效果的时候,我就会有种内在的动机来改善 我的 系统。然而,如果一个聪明的人提出了一个板,然后告诉我这样工作应该最有效,那么我的目标就是告诉这个聪明的人他错了!如果人们不是自己设计这个系统,他们试图规避这个系统的概率就会变大,而不是出于对他们有利而使用他们。
InfoQ:在您的讲演中,您曾提到在团队中协调用项目站立会议,您可否解释一下是怎么做的吗?
Klaus : 那其实不是什么大问题。团队派出代表参加一周两次的协调会议。目的是协调跨团队的工作 – 谁需要谁的信息,谁可以帮助谁解决工作上的阻碍、我们有什么依赖等等。我真正喜欢的是团队轮流派代表的原则:每周有一名不同的人代表他的团队。相比于自己的小团队花园,这种方式对于理解整个项目的情况真是非常有帮助。情况就不再会是“只有我们团队的这几个家伙是很好的,而其他的人都是累赘。”, 而很可能是“ 我们 可以一起做什么让项目成功?”另外,这也培养了团队之间的领导力。我并不是高地人原则(Highlander Principle)“无敌模式”的铁粉,我认为我们需要在不同层面上有更多的领导,而不是单点故障方式,就像看板Master等。
InfoQ:您曾给出过一个例子,描述了在完整的交付周期将看板板与管理在制品数量(WIP)连接起来,您可否解释一下它是怎么工作的吗?
Klaus : 连接系统是规模化看板的一种方式。然而,在看板的上下文中讨论规模化却有点困难,因为在规模化时,你真正所做的仅仅就是解决一个问题。我在现实中遇到过两种典型的问题,而规模化是一个解决方案:
(1)聚合服务
我经常看到一种模式:服务A始终依赖于服务B。例如看板系统中,前端开发的服务始终等待后端开发的服务,如下图所示:
(点击图像以放大)
这种依赖性必然会增加了大量的周期时间(Lead Time)。我看到的方案通常是只把这两个服务合并成一个服务,例如“前端和后端开发”。我曾看到过很多这样的实现。最简单的就是把两个团队合并成一个更大的团队。但是,这种方式只有在人数有限的情况下才是有意义的。我还经常看到的一种方式是,团队并不合并,但他们用共同的看板系统来进行协调工作。
(2)连接服务
连接也类似。同样有两个服务彼此依赖,但现在的情况是,服务B要用服务A的输出作为输入。例如:想象一下有一个开发服务和一个整合服务。当开发完成的时候,他们把工作转给整合。当这两个服务不连接时,他们就把工作项放入到无限缓冲区中,例如“准备2整合”,这基本上就是这个板的完成栏。从开发的角度看这个工作可能已经完成了。然而,在客户的角度上这一任务并没有完成,因为它必须与整个系统整合并且还需要发布等等。看板在很大程度上就是通过客户的眼睛来看整个世界,因此把两个服务连接起来就变的有意义了。另外,减少无限缓冲意味着你有一个可预见的工作流。
(点击图像以放大)
为了解决这个问题,你只要把这两个服务连接起来,然后在“准备2整合”栏写上在制品数量限制。你实际要做的是,你通过下图中的方式连接两个单独的服务,以一种面向服务的方式实现规模化。这就是一个真正的SAFE(规模化敏捷的一种方法)方式。规模化看板意思就是做更多的看板。你不需要用一个蓝图去做,因为这只是常识 – 这只是你的组织怎么工作的。你可以从 “ 看板规模化 ”这篇博客文章中查看更多内容。
(点击图像以放大)
InfoQ:您可否阐述一下应用看板给该项目带来的一些好处吗?
Klaus : 最大的好处肯定是,为了达到共同的目标:项目的成功,所有团队互相协调他们的工作。在开始的时候,让大家都关注在工作流上而不是使用上是非常困难的。不开始新的工作并不合适,因为我们已经达到了在线制品数量限制,并且还要专注于改进系统。然而,它完全得到了回报:仅仅两个星期之后,史诗(Epics)的周期时间减半,另一方面,我们看到了产出在上升,团队也减轻了很多压力。结果就是,我们能够做到在短期内交付更多的东西,团队成员们也会感到更加快乐。
关于被采访人
Klaus Leopold 是一位具有多年经验的计算机科学家,帮助不同行业的组织用精益和看板开展他们的改进之旅。他是《 德国IT的看板 》(2012年由Hanser Verlag 在德国发布)的合著者,也是《 看板改变领导 》(将于2015年5月由Wiley发布)英文翻译的合译者。Klaus是第一批全球精益看板的培训师和教练。他在2014年旧金山的看板社区得到了名为“杰出成就和领导”的Brickell Key奖。Klaus还是Stoos管理网络的创始人之一。他主要的兴趣是在团队之上的敏捷性,尤其是针对30到500人规模的项目。他经常在自己的博客 www.klausleopold.com 中发表各种最新的见解,你也可以关注他的Twitter帐号 @klausleopold 。
查看英文原文: Can You Scale Kanban?
感谢邵思华对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ,@丁晓昀)关注我们,并与我们的编辑和其他读者朋友交流。