BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Renee Troughton访谈:领导力的敏捷模式

| 作者 Shane Hastie 关注 11 他的粉丝 , Hugo Messer 关注 0 他的粉丝 ,译者 王强 关注 0 他的粉丝 发布于 2017年6月15日. 估计阅读时间: 12 分钟 | QCon北京2018全面起航:开启与Netflix、微软、ThoughtWorks等公司的技术创新之路!

亲爱的读者:我们最近添加了一些个人消息定制功能,您只需选择感兴趣的技术主题,即可获取重要资讯的邮件和网页通知

Renee Troughton是南半球经验最丰富的企业敏捷转型教练之一。她的工作经历遍及小型到大型组织,涉及金融、保险、养老基金、政府及电信企业等多个领域。她著有《Agile Forest》一书,也是《Who is Agile Austrailia and New Zealand》的作者之一。她在博客敏捷森林上发表大量内容,并共同主持全球一流的敏捷播客。Troughton擅长企业变革、看板、大规模敏捷与非软件开发领域的敏捷实现。

她将在印度尼西亚敏捷大会上发言。她接受了InfoQ采访,谈论使用系统思维和关键的领导力模式进行组织变革的话题。

InfoQ:请再多介绍下自己,Renee是什么样的人?

Renee Troughton:我是充满热情的博学家。我想寻找新的工作方式并同他人分享成果,从而使世界变得更美好。我觉得自己不仅是敏捷教练;我使用很多不同的方法和手段,注重科学方式,关心切实可行的方案。我做培训和指导、直观地促进各类事务、主持播客、写书(包括非敏捷类书籍),尤其是与人们共同工作以推动变革。

InfoQ:你正在撰写一本书,名为《Agile Forest》。标题很吸引人,能讲讲这本书的主要内容吗?

Renee Troughton:本书(尚未完成)是为完全不了解敏捷的人所写,书中用一个故事讲述了敏捷的含义,故事里没有使用任何常见的专业术语。它有点像《谁动了我的奶酪》或《凤凰计划》,都是用寓言故事来阐明道理。

《Agile Forest》讲的是一群面临威胁的澳大利亚有袋动物,以及它们应对危机使用的技巧和原则。

InfoQ:大家知道规模化是你擅长的内容之一,也是敏捷领域的热门主题。在印尼,规模化这一话题还不算热门。能否多谈一下什么是规模化,有哪些最佳实践和框架?

Troughton:我在博客上写了一组系列文章,名为大规模敏捷技巧。这些文章就我在规模化方面的一些最佳实践进行了深入探讨。相关内容包括领导力细胞理论(支持规模化交付团队的人员的角色与仪式)、团队有丝分裂、流水线管理方法与经济的团队架构方式。这些是在博客中提及的部分重要的规模化敏捷概念。而在大规模敏捷过程中,我要强调的终极原则有:

  1. 减少阶段移交与依赖

  2. 增强工作流程

  3. 更好地让事务走上正轨,并做正确的事情

  4. 融合敏捷、精益与设计思维

基于这些原则,我不太会使用某个特定的框架(因为它们都不符合第四条原则),更多地会关注在一个特定组织的背景下该进行哪些实验,并给出一系列实践工具和技巧,从而挑选出合适的工具来解决相应的问题。只用一种框架的话,就像握着一把锤子并想象所有东西都是钉子一样。

InfoQ:看来敏捷领域有很多锤子,它们大都由商业利益推动。有一种模式没有什么商业推广的意向,就是Spotify的“模式”。你对调整这一“模式”有什么看法?

Troughton:这要看你怎么定义模式。我觉得这种模式更像是一种方法,Spotify自己说它是动态的形式,而且只考虑了他们自己的情况。不过如果你想复制这一模式也没什么问题。

我有一次做教练时用到了公会(guild)、部落(tribe)和分部(chapter)。在实践中应用它们是一件非常具有挑战性的事情。不过当然,我们最终实现的模式并不是只有这些内容。

要有效应用公会与分部的挑战在于,需要花时间找出并处理有助于公会和分部的事务。通常团队要做的交付工作非常多,任务排得很满,很难抽出空余的时间。结果就成了一句话:“我们没时间变得更敏捷”。

有一些方法可以用来克服这些困难。例如9/10日程,其中系统专门空出时间不做交付工作,或者让有余力的志愿者对接各个公会,辅助繁重的迁移工作。不幸的是,多数组织引入公会时并不会使用上述方法,结果就会质疑为什么公会没能实现预期的成果。

组织面临双重需求约束时可以应用公会与分部技巧。这里约束指的是:团队的结构为交付端到端价值而充分优化,但成员通常具备很高水平的专业技能。此外,因为有多个团队为同一系统或频道工作,组织需要某种程度的协作:包括经验、视野、感受和可维护性的协调一致。这些是团队外围的约束或需求。另外还会有潜在的更多约束,例如管理层要求与系统或频道之外的内容保持协调。这种情况下的技巧在于,不要把公会和分部作为应对约束的唯一解决方案,而是在组织的系统层面审视约束,并明确所有可选的解决方案的代价、风险和问题。然后选择一种方法,测试并研究其是否有效,但不要依赖它,而是思考怎样在早期阶段判断其是否有效,并选择是接受它还是转向另一个方案。相比公会和分部,这一授权、调整、审查和转型的流程才是Spotify成功的关键。

InfoQ:在印尼,多数公司还没开始考虑规模化或应用像Spotify之类的方法。很多公司刚开始应用Scrum。你对看板也有很多经验。对你而言Scrum和看板主要的区别是什么,公司怎样选择适合自己的框架?

Renee Troughton:Scrum和看板的关键区别可能就是它们的基础方法。在Scrum中,团队会看到新流程取代已有的开发流程:其实就是彻底抛弃过去的方法并开始迭代。有些情况下Scrum难以解决问题,团队此时的反应就能看出上述做法的影响:他们不知道怎样处理一般性的问题,还认为自己不该回去做以前的工作,却苦于寻找问题的对策。有些教练就会说,使用Scrum时并不是要彻底推倒重来,对于“其他事项”还是要按以前的方式处理。但从我的经验来看,这种困惑在前期的适应阶段是非常普遍的。

在看板方法中,转型是从现有的工作开始入手,并加入一些新的实践和原则。从这个角度来说,看板是一种改进方法而非替代方法,所以前期的困惑就不那么严重。

除了开始的适应阶段,第二个关键的区别在于时间盒。Scrum有着清晰和规范的时间盒,而看板更注重持续和可管理的工作流。

两者都有“承诺”的概念,不过更合适的术语是“经规划的意图”。Scrum在迭代计划会议中定义意图,而看板中意图是由服务周期时间的级别定义的(不过企业服务规划现在也会使用规范的承诺时间表)。

Scrum和看板都鼓励持续审查和调整,都关注测量输出指标,使用输出结果更有效地转型(但我认为看板有更好的机制来进行这一过程)。

在Scrum中规划目标时会进行估计,而看板中没有这个要求(看板使用实际结果作为预测的机制)。

Scrum倾向于使用非常简单的可视化管理方式,工作被分解为任务,而任务分为“要做”、“在做”和“完成”三个阶段。看板中工作不会被分解为任务,相比Scrum的可视化管理,看板使用服务级别作为工作流的代理。工作不是分成任务,而是以看板上工作流的形式来完成。

至于组织应该使用哪种方法,答案可能还是“取决于具体情况”。如果团队需要在一周时间内有条不紊地持续改变业务范围(对于一两周的交付周期来说延迟一周的代价过于沉重),那么我会推荐看板。除此之外,如果工作跨越漫长的周期,有着核心的目标,那么可能更适合使用Scrum。

个人来说,我喜欢让团队在一开始使用两种方法的优势结合体(称为Scrumban),然后当规模化团队外部的约束更偏向工作流时,逐渐让他们过渡到纯粹的看板方法。

我很喜欢企业服务规划中的一些变动,觉得这是对一些长期存在的批判看板的观点的回应。

InfoQ:你还谈到了合弄制。有的人还不了解这个概念,能否概括介绍一下?合弄制对公司有什么帮助?

Toughton:合弄制的发明者Brian Roberston大概会将它说成是一种用于组织中自我管理的操作系统。多数人头一次听说合弄制时会这样想:“哦,这是一种不需要经理管理的方法”,某种层面上这种说法也没错,但实在是低估了合弄制的作用。

当组织迁移到合弄结构,或者设置相应的规则,他们就传达出了强烈的承诺变革信号。第一步是下放权力。本质上来说,并不是要解雇经理人,而是要取消经理这一角色。经理的主要职责会重新分配给组织成员。这可能意味着原来的职位现在拆分成五种新角色。这五种新角色可能还是由原来的那个人员负责,也可能分配给几名成员。

人们说敏捷是一种方法,用来审查和调整产品的开发过程。我觉得合弄制这种方法可以用来审查并调整组织的角色与职责。

就像敏捷为审查和改造制订了仪式一样,合弄制也有自己的仪式,名为管制会议(Governance Meeting)。通过管制会议可以创造新的角色,可以改变职责和预期,也可以移除角色。相比敏捷仪式,管制会议的安排更加精准,所以每次会议都会处理一个特定的矛盾。这可能意味着某一角色在同一次会议上可能会多次改变。

这一方法的一些明显的好处有:

  • 对个体角色与职责的明确授权

  • 矛盾浮现时快速调整职责

  • 决策权限和政策有明确的职责分配

  • 无需花费时间建立共识、取得认同以进行变革

作为教练,我工作的一大块内容就是加强授权、明确职责,下放决策权限并建立变革的共识。合弄制能大大减轻我日常活动的负担。

InfoQ:你在2017印尼敏捷大会上的演讲的主题将是:敏捷仪式只占5%的内容。听众能从演讲中收获什么?

Troughton:从社区角度我们主要关注提升能力以进行迭代计划、每日Scrum会议、回顾会议和案例演示。虽然这些内容对交付产品很重要,但它们并不是团队使用的系统的全部。

从系统思维的观点看,当你用轻量、简化的方法取代已有的繁文缛节流程时,Scrum能起到一些作用。然而长久来看,组织会重新扩张政策、增加约束。成功实现敏捷面临的挑战并不是让团队开始敏捷或Scrum,而是在于抢在系统重建政策和约束之前快速改造它们。

我的演讲主题是关于如何在敏捷变革的同时进行系统变革。

InfoQ:感谢Renee清晰易懂的解说!

想进一步了解Troughton,请查阅她的资料或听取她在印尼敏捷大会的演讲。

查看英文原文Q&A with Renee Throughton on Leadership Patterns for Agility


感谢薛命灯对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT