1. LeSS案例集
  2. Agfa医疗

Agfa Healthcare

Agfa医疗

目录

Agfa医疗导入LeSS的第一步

背景

众所周知，大规模Scrum是丛林中一头难以驯服的野兽，它涉及到权力斗争，需要大量的洞察，经过多年才能有所结果。Agfa医疗的企业业务在2005年收购了GWI，2006年整合了新的组织，从此开始了他们的旅程。

这次收购使得Agfa医疗的企业业务可以提供一整套整合了多个产品和模块的企业级IT方案。解决方案用于提高病人护理的质量，快速完整地提供病人的医疗记录，包括各种图像，临床和行政数据。

这是欧洲最顶尖的医院医疗信息系统之一，在整个欧洲有将近950个组织用户和50万日常用户。

这次收购给组织带来了许多挑战，也带来了新的机会，规模化Scrum就是其中之一。那么敏捷和Scrum是怎么提出的呢？合并不同的组织单元会在不同维度上带来挑战：

处理许多不同的文化

  • 十年以上的遗留代码
  • 定制化的编程语言
  • 许多分析师在寻找方案
  • PMO办公室制定自己的用例
  • 26个团队分布在欧洲的5个地方
  • 400多研发人员
  • Rational套件
  • ……

一图胜千言，如下图。

product-stew.png

研发部门内部已经有了一些小的敏捷和Scrum的尝试，看起来还顺利，管理层了解了敏捷如何帮助解决他们的问题，从此踏上了至今仍然进行中的漫长旅程。

这个故事只讲述了导入LeSS的一些初始步骤，前方还有很长的路。比如，“窄范围”的组件团队可以涵盖的范围越来越广，虽然这减少了各种问题，但是创建的完整的端到端特性团队也寥寥无几。

精益 A3报告 (PDCA)

为了更好地理解我们渴望什么，我们创建了3份精益A3报告，用来指导LeSS导入，确保其是朝着实现组织价值的方向前进的。A3工作坊和追踪的启发是来自《学习型管理》这本书。许多读者可能听过A3分析，但是可能在他们熟悉的行业中没有见过真实的案例。所以我把这些A3分析的结果分享出来供大家学习。

A3-agile-transition.jpg

A3-r-and-d-can-not-deliver-promises.jpg

A3-r-and-d-delivers-bad-quality.jpg

通过培训来准备

有了清晰的LeSS导入目标，我们从对整个组织的一些Scrum培训开始，培训内容根据参训人员的背景进行了调整。包括

  • Scrum基础课程
  • Scrum Master课程
  • Scrum产品负责人课程
  • 敏捷管理课程
  • 技术课程

几乎所有的培训课程都是由外部培训师和Agfa内部教练一起来上的。每个课程有至少一个内部人员来助教，通过结对上课来提升组织整体能力。

价值流图

在通过培训提升组织内的意识和技能的同时，我们需要学习从客户提出需求到满足需求整个流程，这些信息散落在400多个部门筒仓里。我们有两个选择：

  1. 将现有流程文档当作“事实”，基于这些信息来工作
  2. 和大家一起重现现有流程，并以此工作

我们选择了第二种，举办了一个大型工作坊（作为2008年初始培训的一部分），来自各个部门的参与者一起从头画出组织的价值流。这类流程协作让大家互相讨论产生了不错的氛围和能量，有助于改进行动。

value-stream-mapping-1.png

我们坚信没有深入理解价值流图是没有办法管理一个精益敏捷组织的，因为价值流图把组织内的浪费清晰地展现出来，你可以发现瓶颈，长长的工作队列，输入间的冲突等等。

第一次做价值流图产生的一些改进点：

  • 将众多待办列表合并为一个主企业待办列表
  • 根据商业价值对这个企业待办列表排优先级
  • 团队在做的工作都必须来自于最重要的待办事项
  • 说服整个组织遵循流程

组织期望的未来状态

受到Bas Vodde和Craig Larman的启发（《精益和敏捷开发大型应用指南》），利用第一次价值流图工作坊的输入，讨论和输出，大家设计了组织的下一状态。需要注意下面几点：

  1. 定义团队工作的需求领域
  2. 为新的角色找到正确的人
  3. 培养自组织团队
  4. 组件团队转换为特性团队
  5. 建立先进的持续集成系统

敏捷教练团队

根据改进目标和想法，考虑到组织的大小，我们很快发现五个地方都缺少有经验的精益敏捷教练。

因此2009年底我们开始组建真正的精益敏捷教练团队，直接汇报给业务线领导。团队部分成员是内部员工（Philippe Launay, Sebastian Lang, Jürgen De Smet），还有外部教练（Yves Hanoulle, Deborah Hartmann Preuss, Ralph Miarka, Ilja Preuss）。这正好是《精益和敏捷开发大型应用实战》中提到的LeSS试验：内部教练和外部教练一起工作。

作为教练，我们意识到在欧洲的各个地方工作会使我们陷入各个站点特有的上下文中，从而与其他地方脱节。我们知道这样的脱节没有任何好处，我们组织了频繁的线上交流，持续的线上群组讨论，每两个月面对面的会议（每次在不同的地方，尽量在组织的五个地方平均分配）。即使我们知道这些风险，增加互相之间的沟通带宽来降低风险，我们依然发现难以保持畅通的沟通并朝着共同的目标努力。

企业待办列表，产品待办列表，需求领域和团队

在复杂环境中我们没法按部就班的开展工作。当教练团队还在组建，并逐步了解组织的过程中，Robin Dymond和Jürgen De Smet与管理团队已经工作在为400多名开发人员的业务线建立单一企业待办列表。

业务人员、产品负责人、产品经理和项目经理等一起为整体方案建立企业待办列表。列表有超过800条条目，业务线管理团队需要把它们排优先级。

好极了，但是还漏了些什么？你可能已经猜到了：“估算”。我们如何从整个组织获得估算呢？一些团队已经开始做Scrum，有的在做看板的，还有坚持在用瀑布方式的。与一夜革命不同，所有这些都是大型的递增式变革会有的现象。

问题一：我们估算用什么单位呢？不是故事点，将近一半的人完全不理解故事点，我们不知道如何很快得出靠谱的估算。所以我决定用人天来估算。这意味着Scrum团队得转换他们的故事点回人天，其他团队用他们的度量换算出“足够好的”估算。这样整个组织就能把企业待办列表的所有条目估算出来。

问题二：如何让大家有勇气给出有用的估算？（有用指能帮助排优先级）有些团队不习惯给出估算，有些团队以前因为给出“错误的估算”受到处罚。并不是所有地方的文化可以接受这么大的跃进。Boehm的”The Cone of Uncertainty”展现了估算随着时间的变化而变化，我们从其中受到了启发。我们在人天估算边上还加上了对估算的信心：“S”表示对估算很确定，“M”表示这个估算还行，“L”表示不太确定，“XL”表示估算是拍脑袋蒙的。根据信心，我们向管理层和内部客户展现了两种不同的预期。一种基于给出的估算，称为“乐观”预期或者“高风险”承诺，在Boeham看来这些估算很有可能无法实现。

enterprise-backlog-high-risk.png

另一种则用给出的估算值乘以信心程度的权重，权重是依据不确定性锥（XL=4倍；L=2倍；M=1.5倍；S=1.25倍）。这个预期我们称作“现实”预期或者“低风险”承诺。

enterprise-backlog-low-risk.png

我们推测真实情况应该在两种预期之间，而且与客户和利益干系人做了沟通，承担多少风险不是由团队决定的。

所有团队参与了整个企业待办列表800多条目的估算。他们被分为21个领域，分散在5个站点。估算花了3个星期。教练和团队代表进行了数小时的视频会议，超过100人参加。讨论固定时长，我们要求大家勇于发表意见。我们很认真地对待这耗费巨大精力的结果，而这结果成为沟通路线图和其他特性交付日期新的依据。

解决方案经理对企业待办列表排优先级，用于指导400多人进行开发。同时他们组织工作坊和客户以及团队代表一起深入理解需要满足的需求。事实上他们扮演着整个解决方案的产品经理的角色，帮助团队专注在正确的事情，并与重要客户的真正终端用户保持联系，或者参与客户顾问委员会工作坊。

建立好企业待办事项，产品负责人（LeSS中的领域产品负责人）把条目加到他们的产品待办列表（LeSS中的领域待办列表的变种）中。

每两周（领域）产品待办列表条目会根据团队的容量进行梳理和开发。最多5个Scrum团队共享一份产品待办列表。总共21个产品负责人从企业待办列表中获取条目放入21个产品待办列表中，共有400多研发人员工作在这些列表上。

是的，还是有项目经理存在。为什么？他们把内部工作翻译给外部，帮助生成符合ISO/FDA规定的文档。理论上，产品负责人可以完成这项工作，但是工作量太大，而且不是产品负责人的主要的关注点。组织项目经理用待办列表了解现在的进度以及什么时候可以交付，从而保持敏捷转型前的已有沟通。不同意计算出来的日期（基于团队估算和容量）时，他们立刻知道会有怎样的影响，其他项目经理会将内部信息翻译成外界可以理解的信息，因为外界还在用项目的视角来看工作。这就意味着项目经理团队会去找产品负责人，而非一个个项目经理。这样产品负责人面向900多客户和客户顾问委员会的工作会变得简单。

企业待办列表还有个好处是可以很容易地发现哪些条目带来的麻烦最多，我们可以在新的发布版本刚开始时就处理它们，或者从某次发布版本中移出。

此外，管理层可以看到哪些领域的团队工作不均衡，在它成为问题前就采取行动，要么增加人力，要么把一些人力从一个领域或团队调到另一个领域或团队。

有足够时间来决定如何采取行动可以产生大量的选项。但与之相反，我们常常惊讶地发现组织的管理层并没有太多选择，只能推迟一些事情并且/或者雇佣更多的人，但是这破坏了组织的平衡，使情况更复杂。

保持事情越小越好，越少越好，越好意味着最后是更多，更多的满意，更多的价值，更多的创新，更多的交互…

协调

同步的时间盒

整个组织会每两个星期从企业待办列表中获取工作，每一组都在同一时间开始和结束他们的迭代。这对处理团队间的约束至关重要，每个团队在迭代内拥有一致的目标：完成工作！没有理由团队们不能一起工作解决团队间的约束问题。

约束（或者依赖）是在需求领域级别的产品待办列表中，所以谁需要和谁谈谈来促成事情的解决是很清晰的。如果知道了团队间的约束，可以通过Scrum of Scrum（SoS）来处理，受影响的团队成员可以形成一个SoS节奏，以有效的方式来解决约束。这可以是每天，每周两次，甚至每周一次，只为了一个目标：解决约束，交付价值。

一般来说，SoS节奏是在迭代计划会议第一部分决定的，团队可以同步他们的需要和想法，讨论大体实现方式以及协调计划则在迭代计划会议第二部分和后续的迭代执行期间发生。我们认为通过SoS进行类似的协调是处理多团队约束的关键。但另一方面，如果需要SoS持续地发生，则可能意味着团队结构或领域结构有问题，需要重新调整组织结构来改进交付流程。

组织障碍列表

你可以想象大量问题冒出来，团队通过定期的回顾会议检视他们工作的方式并设计改善措施可以解决其中许多问题（并不是说大部分）。我们可以说在团队级别有个2周的改善周期可以解决团队交付过程的大部分问题。

越成熟的团队会越能感受组织结构带来的痛苦，这会阻碍他们更进一步改善。因此就有了实践社区（见后续章节），开放空间和一些跨团队回顾，这些活动产生的内容可以加入到组织障碍列表中，敏捷教练可以维护这份列表。这份列表是组织领导层改善系统的主要工具之一。每季度领导团队一起来评估列表，设定优先级并对高优先级项目采取行动。有时需要提供适当的人，有时需要提供资金，有时需要用到他们自己的政治手段……但是都是为来解决团队提出的问题。

集成与完成的定义

我们不得不面对大量的技术债和解决方案的复杂度，持续集成（CI）系统是必须品而非奢侈品！没有像样的CI系统，持续改进并保持较短的反馈周期是很困难的，CI系统对整个组织是十分有价值的，特别是大家使用同步的迭代（统一的起始时间），有的工作依赖于多个团队一起工作（因为还有组件团队）。

在同样时间内拥有同样的目标：完成工作，团队更需要互相支持来解决依赖问题。这会产生另一个问题：需要合适的环境和工具以及必要的技能来快速验证交付物。

我们还雇佣了技术教练 （Qwan.eu - Quality without a name）通过使用团队的代码来提供培训和教练辅导。大家可以学会处理遗留代码，隔离新的开发代码，编写单元测试。由于不同团队进度不同，我们发现一些团队通过使用Hudson，Maven，Fitness和其他简便易用的工具来做持续集成比较成功。有些团队甚至可以每个两周的迭代都能交付给他们的客户（医院）！考虑到软件不是部署在云上的，能做到这点非常厉害，因为客户的数据量非常巨大，进入生产环境的审查非常严格，而且需要遵循ISO和FDA的监管要求。

那么我们如何传播这样的知识呢？我们如何为整个组织的所有团队定义更一致的完成的定义（DoD）呢？

我们并没有强制推行一个“完成”的标准，而是列了一个清单，上面有团队现在能够做到的和团队现在距离“完成”（在迭代内发布到生产环境）没有做到的。一个对团队进行的调查帮助我们了解关于工具，技能以及哪里需要投资和外部帮助的信息。从这时起我们帮助能力较弱的团队和较强的团队建立连接，促成跨团队辅导，提升组织整体的DoD。持续提升团队的DoD带来更好的质量，更快的交付到市场，降低交付整体解决方案给客户的成本。

实践社区

除了建立CI系统的跨团队辅导外，架构的实践社区也开始了。这个社区的伙伴们来自整个组织，他们讨论技术的整体问题，为大家建立指南来解决跨团队的技术问题。与社区类似，指南是一份持续完善的文档，大家常常会拿出来讨论，不同的团队一起解决一些大的架构和技术问题的时候甚至会删除文档。

技术社区效果不错，类似地，我们发起了（甚至更好，我们指导其他人）分享和关注产品负责人问题的社区活动，关注Scrum Master问题的社区活动等等。有些社区坚持了下来，有些社区只活跃了几个月。所有社区都是源自于多团队的共性问题，没有继续的社区都是因为没有新问题冒出来，或者大家没有动力继续下去。

另外，我们还发起了内部知识交接（IKT），最终也悄无声息了，但是我们在不同的实践社区中借鉴了许多，分享大家学到以及感兴趣的内容。每两周的周五有一个预留的时间段，所有地方的办公室都为实践社区预订了会议室，建立了WebEx视频会议。话题会事先发布，大家可以参加自己感兴趣的并对活动和内容提供反馈，从而进一步改善。

开放空间

我们需要处理的最大问题之一是在研发部门（教练辅导范围内）内整合业务部门（教练辅导范围外），这个问题在产品负责人实践社区活动中经常被提出来讨论。这似乎解决的不是很好，开放空间被认为是可以推进的方式之一。我们曾经在小范围（一个办公室）使用过开放空间，但这次不一样（所有地方的办公室都参与了，50到80人甚至更多人参加了）。

整个教练团队都参与进来了，发现让管理层接受开放空间并不容易！你不知道要讨论什么是什么意思？！你要各个办公室的人都飞过来？！你知道这要耗费多少成本？！你预期的结果是什么？！除了可以计算成本外，很多问题我们都回答不了，但我们还是成功说服了管理层。第一个问题解决了，接下来……

我们已经得到了管理层和产品负责人社区的支持，但是不意味着我们获得了整个组织的支持。我们需要令人十分信服的邀请大家，这样我们的目标受众才能十分有动力参加开放空间（和其他的会议一样），而不是强制参加的，也不会有人抱怨谁没来。我们调研了一下大家在多大程度上可以自己做决定，因为知道自己可以做决定对大家是个很大的激励；还有促使他们来参加的问题都有哪些；需要发邀请给哪些人……澄清了这些信息后，我们就有了下面的邀请函。

open-space-invite.png

最后有63名参与者来到了波恩（德国），有些是波恩本地的，还有些来自特里尔（德国），维也纳（奥地利），波尔多（法国）和根特（比利时）。他们建立了自己的日程（下面第二张图），这一天大家很开心，也在一些非常复杂的问题上花费了很多精力，结束时（如下图示）大家分享了一天的收获。

open-space-marketplace-2.png

open-space-opening-the-space.png

2周后管理层得到了一份报告，其中阐述了大家从各地来参加开放空间的价值（考虑到这是时间和钱上的一笔大投资）。下面是些可见的结果，大家投入许多时间和精力来呈现并关联到举办开放空间的初衷。

open-space-statistics.png

当管理层愿意并敢于信任大家做正确的决定，你会发现许多有意思的事情发生！困扰了大家多年的多维度多站点问题在很多方面拥有了明显且持续的结果，这是组织最振奋的时刻之一！推荐其他组织都尝试使用开放空间来解决他们的问题。在Agfa各个业务线这项技术得到了广泛的使用，甚至还邀请了客户。

组件团队，跨职能团队和特性团队

你可能注意到在这个案例中，一开始组织是有组件团队的。这导致了许多精益视角中的浪费。当团队扩展他们的DoD，测试技能进入了团队，他们也成为了跨职能团队。少数情况下，团队扩展能力是通过增加（测试）人员达到的。大多数时候增加测试技能是让现有团队成员在测试社区（其他团队拥有测试技能的人）帮助下来学习。

这曾是（现在依旧是）一个非常大的组织。这种情况下，LeSS不推荐来一次翻天覆地的变化，把组件团队变成特性团队，而更推荐递增式的方式，比如一次一个领域。

但即使这样，说总是比做容易！这里有非常强的依赖关系，大量的技术债和许多其他因素阻碍我们说服组织开始变化。我记得我们只有2个团队以他们的工作方式贡献给平台团队。如同许多开源项目中的贡献一样，应用团队（交付到最终用户的团队）成员可以贡献平台代码，平台团队成员会评审并提交代码。这是一项巨大的改进，即使还不是完美的特性团队。但这正如LeSS书中所描述的，是扩展组件团队代码到更大“开发领域”的重要一步。

但是罗马不是一天建成的，这是朝着团队可以工作在更广范围代码的坚实一步。

C级别管理层变化与更多的教育

当敏捷的思维方式和实践在组织中成长的时候，其它东西并不会停止。2010年我们不得不调整组织结构，这是由新的CEO和她的团队发起的。众所周知，新的管理层 = 新的规则！新的管理层并不会接管之前管理层发起的所有事情。这是我们最害怕发生的事，但是我们获得了新的机会！

重新调整组织架构后，与新的领导团队多次沟通敏捷的愿景，我们得到了一个机会来教育整个领导团队，介绍我们做了什么，怎么做的以及为什么做。我们接受了挑战！整个敏捷教练团队一起工作在这件事情上，在这个与高管团队2天的课程/工作坊中，每个人都贡献一己之力。

与整个领导团队干了些什么呢？！想要在2天内带领一个多元的团队学习敏捷价值观，原则和流程，并让他们接受敏捷的思维方式几乎是不可能的……所以到底做了些什么？

我们选择让高管团队自己变成为一个团队，并分享精益和敏捷在一个企业内意味着什么。第一天我们从自我介绍，每个人的经历和一些促进信任的练习开始，然后简短介绍了精益和敏捷的实践。

第二天我们带着他们一起来玩瓶颈游戏，体会用约束理论来管理，并延伸到大家在组织中的角色如何更加融入到一个自组织的公司里（换句话说就是：更少的层级，更少的管理者，更少的经常性开支，更少的……）。这2天非常的艰难，但是十分值得，因为这2天让我们的工作更容易，可以继续解决障碍并持续交付客户价值。

半途（对于这份报告来说是尾声）

我（Jurgen）在2011年离职去寻找更多的辅导经验。那时，这个400多人的组织还处在导入大规模Scrum的早期阶段，但绝对是朝着正确的方向。

2011年底，又举办了一次价值流图的工作坊，因为经过几年，很多东西发生了变化。下面是新的改进行动。

value-stream-mapping-2.png

agfa-process-poster.png

这算成功了吗？是……也不是……取决于你如何理解成功。

但是……

“我们收获了很多！”

参考文献

视频

书籍

文章

演讲