在 Lean Kanban Benelux 2015会议上,Jeroen Molenaar分享了其作为敏捷教练与荷兰太阳能汽车团队一起工作赢得澳大利亚世界太阳能汽车挑战赛的经验。
\\InfoQ有幸对其进行了采访,主要关于他是如何指导团队的、和团队如何应用 Scrum、指导太阳能团队与指导软件开发团队的差异和相同点、以及他从指导学生团队中学到的经验。
\\InfoQ:您能简要介绍一下您是如何指导 Nuon太阳能团队的?
\\\\\Molenaar:团队每隔一年就会制造一辆新车。加入项目的学生每年都会发生变化。他们走出官方学习机构,花费一年的时间将比赛团队作为一个公司运营。在一年时间内运营公司同时学习整个频谱带来了很多挑战。并且同时他们还需要创造一辆车。因此,他们需要面临很多挑战。
\\我们是这样处理它的:在年初我们开始对敏捷和精益原则进行简短的培训。培训包含一些理论,然后我们对过程进行裁剪,使他们能够在第二天就从实践和原则开始。
\\我每隔一周跟他们一起工作,以改进和促进过程和协作的提升。我使用回顾,帮助他们构建团队(反馈和合作协议)。我还能帮助他们如何将知识传递到下一个陷入困境的团队。我发现,学生们有点偏于理论,因此我的指导更侧重于尝试/试验,而不是计算。
\
InfoQ:您能举例说明团队如何应用 Scrum开发太阳能汽车?
\\\\\Molenaar:Scrum和敏捷对他们而言是非常重要的工具。他们非常依赖前期计划,并且对成员职责规划非常不透明,因此缺乏团队支持。我们创建的是一种敏捷和 Scrum的工作方法,其中应用了大量的可视化管理。他们有子团队,并在每个子团队中使用了 Scrum板和站立会议。他们进行周 Sprint并以成功的内部演示结束,内部演示则通过回顾形式进行。对他们而言,在整个团队内分享结果具有启发性。其中最有效的信息之一是本周子团队赢得了多少比赛分钟。
\\回顾以每隔一周分别对团队和个人进行回顾的形式交替。这样每周他们不仅要关注团队还要关注个人。好处是每隔一周团队成员就能从团队中获得反馈。这就避免了一个问题明明存在,但大家却视而不见,集体回避它;每个人都能看到暴露出来的问题,但是团队还没做好在回顾中处理的准备。
\\我在其中加入了整体规划板,我们称之为组合墙。对创造汽车非常重要的里程碑进行了强调(比在软件里更重要)。显然软件的法律截止日期很重要,但是到达截止日期我们可以交付已经完成的。而一辆没有车身的汽车却不可能在比赛中驾驶。所以汽车中的截止日期显然比软件开发团队中的更不具备灵活性。
\
InfoQ:指导太阳能团队和指导软件开发团队有什么不同?又有什么相似之处?
\\\\\Molenaar:当指导这些家伙时,你会发现工程师也是一群相似的群体;有点内向,有点“二(binary)”。这使得指导他们成为一项非常有趣的工作。所不同的是领域知识。你必须明白硬件不是软件。你必须学习一些在他们的世界里非常重要的新事物;计算、预测、零部件的名称。因为相同的概念都不适用,所以尤其是软件团队的敏捷指导的技术方面是不一样的。
\
InfoQ:您能分享一些经验和教训吗?
\\\\\Molenaar: 作为一名敏捷教练我从中学到了什么?顺便说一下,结果不具有科学性:)
\\
- 比赛中的年轻人和工程师往往加倍的顽固;假设你自己缺乏真实生活中的工作经验;加入这些非凡的、聪明能干的家伙中,你应该能够想象具体情境。\\t
- 据我所知,他们的学习速度也是软件团队的5倍。因为我知道软件团队总是要处理遗留问题;这会降低他们的速度。这些家伙面对的是对他们而言可以无视历史完全未开发的领域。当然这给保持真实性带来了挑战。\\t
- 硬件不是软件\\t
- 你需要适应聪明地测试;你不能仅仅简单地测试一百万欧元的碳化纤维车身是否能在事故中不解体。\\t\t
- 你需要适应聪明地试验:发生事故后你不能简单地制造一个新的车身。使用反复试验法前提是要有东西可以测试。你只能在正在行使中的汽车上测试故障这种假设似乎不符合事实。这就是为什么他们创造了一个测试车,通过在测试车上增加新部件,这样他们就能尽快测试。\\t
- 实用性和敏捷无处不在,比如上面的案例。协作(重于特长)难以实现。因此以优胜模式组建团队,在关键时刻让团队成员接手似乎很困难(电子家伙负责结构工作)\
AI无处不在,这对我对团队都是非常深刻的体验。我建议每位敏捷/精益教练每年帮助一个比赛团队走出困境。尽管你从中学到的难以表述,但是这对于在其它敏捷组织中重新使用非常有帮助。
\
InfoQ:您对应用 Scrum的非软件开发团队有什么建议吗?
\\\\\Molenaar:我的建议是(尤其是那些拥有软件领域经验团队):清楚了解它们之间的差异;讲他们的语言,不要过分依赖你的软件经验。我主要和最重要的秘诀其实是:只管去做!
\