Skip to main content

敏捷咨询日记——消除浪费

waste

当我们追根溯源敏捷最先被发明的初期,可以发现,敏捷所消除的便是因为频繁业务需求改变带来的潜在浪费,而一切关于杜绝浪费话题到最后,都变成为对价值的纯粹追求。任何商业模式都基于创造新用户和挽留老用户,最终也被细化为为新用户提供不可替代的新价值和为老用户提供持续改进的旧价值(当然同样可为新价值)那么两件事情被认为是杜绝浪费最重要的两个方面:

  • 只给客户想要的;
  • 让客户简单地用到他们想要的;

简而言之,做了没用的和没用已经做了的是最普遍的两种浪费。二者间的关系是:做了没用的往往的结果是未使用,但未使用往往不止是因为没有用(也许你不够好)。

一个简单的对话可能会揭示这个道理。gigix在贴卡片的时候使用了没有ThoughtWorks logo那一面,我问:用反面的价值是什么?gigix说:我顺手写在了反面。我说:那你就把 logo marketing的价值浪费了。gigix便马上在正面重写。可以看出,在卡片的正面印上公司标志是一件具有市场推广和提高品牌认知价值的事情,我们也同意这种价值是实际需要,但是有50%的情况我们可能会忽略这个价值,于是,这个价值便被浪费了。

据说这个卡片的成本是两毛钱,而印刷logo的成本可能是1毛钱(印logo的唯一价值就是展示出来,于是不展示出来的浪费就是100%),每年全球范围内整个公司的卡片消耗量估计有51万张(一个人一年大概消耗300张,一年就是300X1700=510000张)于是理论上每年因为没有展示公司logo造成的浪费就是25500元。

解决这个办法有两个,长期的,如果每个TWer都有一种价值驱动的自然反应,把浪费扩展到日常生活中去,这个价值被浪费的几率可能减少;短期的,两面都印logo的成本理论上比一面印一面不印还要低,而当两面都有的时候,这种浪费便不可能发生,甚至成本更低。

这就是为什么用户体验被拔高到一个很高的地步,良好的用户体验可以更容易地把有用的价值传递到用户使用过程中,而很可能,往往被忽视,这是一个投入低于可能产生的价值浪费的过程。

敏捷当中关于杜绝浪费的阐述,绝对不应该只是个适用于软件开发(或精益制造)的概念,它应该贯彻到所有日常管理开发的过程中。有时候,我会刨根问底地询问某个内部管理表格上某行小字表述的意思,或者某个状态图中某个多余标签颜色的目的,甚至关于饮水机摆放位置的斟酌。

当各种询问进行之后,你会惊奇地发现,这样的价值最后一定被认为阻塞在一个更高级阶层人物的脑中,而所有人要做的只是忍受一次便接受这种浪费。而这样的现象成为一种奇特的人类自适应习性,特别是在一个具有组织结构的环境里,人们不加思索地游走忍受各种浪费,或者说有意识的拿出可能百分之一的生命作为浪费,而不去质问这个所谓深藏在高阶人士脑中的某个模式。而更神奇的是,这样的组织结构似乎就是为了种容忍浪费的习性提供养料,他们用权威语言(community language)描述这种可能产生浪费的活动,用意识形态的方式提高质问的门槛,他们用一种容忍浪费的高明手段来杜绝“浪费”,这种“浪费”被理解为更多的投入,或者改变,或者干脆就是自己权重更大的时间。

更深层次讨论这个问题这样的浪费被打造成一种十分有效的管理手段,因为我们的文化里,当你不懂我的时候,浅意识里我高过你,当你懂我的时候,你可能高过我,换言之,阻塞价值传递带来的心理慰籍多于价值广达于人。于是,如同状元可当驸马入赘皇族给天下清苦寒士打一针鸡血一样,这种“你不必懂,你只需做”的潜台词,成为底层工作者努力上进的“状元奖品”。同时,不可避免的是,各种浪费在这庞大的机器里不停被产生,讽刺地是,某种意义来说这样的浪费便成了机器运转的润滑剂,我们的发展不也是基于更庞大的物质浪费吗?

或许,我说到了最苦恼的地方,我努力尝试把敏捷方法跳出制造业(基于流程的软件业也是一种制造)而更多地作为一种现代企业管理方法论引入企业日常管理当中去,而似乎,敏捷原则的桎梏在于对人的依赖,以及是不是还有权威与非权威的概念,回到刚才的例子,如何保证所有质问的价值都是低于浪费本身的-万一大部分人的质问都是无理取闹?权威“不必问,只需做”的方式是不是本身也是一种杜绝浪费?

就此来看,敏捷方法还有很多值得思考的东西,但杜绝浪费初衷本身是值得肯定的。

本文转载自:

Share

You are not your job

agile-standup

受到光磊的系列文章——《Scrum:死马?》的启发,我也来谈谈Scrum中的元素之一——站会。


还记得经典Scrum站会上我们要问的三个问题吗?

  • 我昨天做了什么?
  • 我今天打算做什么?
  • 我遇到了什么障碍?

在初次接触Scrum的团队中,一般都会让团队成员去遵守“Scrum教义”中的做法,其中就包括了在站会上依次回答这三个问题。
一般我们会看到这样的情景:
张三说:我昨天把这个故事的代码写完了,今天打算自测一下,没遇到什么障碍。
李四说:我昨天被叫走解决某个紧急故障了,今天打算继续这个故事,遇到的障碍就是最近打断比较多。
……

如此往复,基本上几周之后,站会就变成一个人兴趣索然地说,其他人目光游离地听;不低头玩手机都已经算是给面子的了。

德鲁克在《卓有成效的管理者》中曾经写到过:

“在组织的内部,不会有成果出现,一切成果都存在于组织之外。举例来说,企业机构的成果,是通过顾客产生的,企业付出的成本和努力,必须通过顾客购买其产品或服务,才能转变为收入和利润。”

“在组织内部所发生的,只有人工和成本。”

这个说法不论在组织的任何层级都是奏效的:从企业的角度,只有不断创造价值去缩小人类理想和现实之间的鸿沟的公司才能做到基业长青;从团队的角度,只有持续对组织有所贡献的团队才算是高绩效团队。

同样,作为个体,只有你的劳动真正被别人承认并消费,你所做的事情才算得上是卓有成效。

只不过在历史上作为体力劳动者,员工的劳动基本上等同于创造的价值,因为他们创造的是有形的产品,不论是搬的砖、制造的零件还是放牧的羊群。而在今天作为知识工作者的代表,IT项目和从业者产出的都是无形的知识、创意或者信息,而这些无形的东西在被别人消费或者影响到别人之前,都不能产生任何价值。

所以我们回头检视一下刚才提到的三个问题,是不是能够从这个角度来提升一下我们站会的效率呢?我们能不能从外部的影响来重新考虑如何回答这三个问题呢?

  • 我昨天做的事情,对我们的项目产生了什么样的影响?今天谁可以来消费我昨天的工作成果?
  • 我今天打算做的事情,可能会使用谁的知识或者信息?
  • 我遇到的障碍会不会是我们项目中潜在的一个风险?

作为知识工作者,不光考虑自己所做的事情本身,多去考虑自己做的事情对于自己的伙伴、团队所造成的影响,就走上了“卓有成效”之路。

Share

为什么你的Scrum会失败?(二)

前文说了Scrum三种角色的错误姿势,现在来说一下四个会议。注意是乱序,先看showcase。

Sprint评审会议/Demo/Showcase

如何评价评审会议(或者叫Demo, Showcase)的效果? 我听过的答案有客户满意、或收集到了反馈等。这都不够,且不说客户满不满意本就不应是评审会议追求的东西,就是收集到了反馈,都不够。

那如何评价评审会议的效果? 唯一的评价标准是, 会后有没有对product backlog做出调整

如果每次showcase完product backlog都没发生变化,那恭喜我们,我们的计划和预见能力很完美,完全可以按瀑布的方式工作,没必要迭代交付了。客户或stakeholder需要了解, 他们对showcase负有给出反馈的责任和义务,找对真正关心产品或项目的人来参加showcase。

但往往团队倾向于show好的一面,直接点就是掩饰问题,这是本末倒置,会后皆大欢喜就是失败的会议,会后没有调整product backlog也是失败的会议。

Sprint计划会议: 实际上应该是分开的两个会

很多团队都会抱怨Sprint计划会议的冗长和低效。抛开开会的技巧不谈,根本原因在于Scrum把两个不同目的,需要不同参会角色的会议融为一体了。在它的官方指南里明确说了计划会议有两个topic: what 和 how。

IPM

对于what,即下个sprint要做什么,某种程度上是不需要开发团队参与的。PO应该根据stakholder的输入,从业务优先级上选出下个sprint的backlog。这个过程可称之为IPM, iteration planning meeting,应该在本sprint开始前进行,也就是推荐在上个sprint的末尾进行,开发团队的参与是可选的,PO完全可以一个人搞定或者跟业务方的stakeholder来商定, 具体如何取决于PO。

  • 你说还没估算呢,PO怎么知道要选多少? PO可以根据之前Sprint完成的story个数,多选几张,比如多出个20%的量。
  • 你说开发团队不参与的话,可能漏掉一些技术依赖项。我们还有下个会呢,开发团队有机会给出反馈。

说到底,估算和技术方面的依赖,不是决定优先级的很重要的因素,仅供优先级参考而已。

IPM结束后,PO手里有了一小堆下个Sprint要做的功能,可能比开发团队正常能完成的量多了一点。这堆功能将作为下个会议的输入,可以微调。

IKM

下个会议称之为IKM, iteration kickoff meeting,在本Sprint开始时进行,主要目的是PO和开发团队对这个Sprint的目标进行交互解释、答疑、达成共识。开发团队对优先级,验收条件的任何疑问都可以提出来,PO来解释或调整任务。对what没有疑问之后可以开始估算,如果你非要估算的话。估的时候就按优先级估,估到累积的工作量达到团队的capacity为止。

IKM的解释,答疑和共识,依然是what,而不是how。对于how,开发团队自组织讨论就可以了,不需要PO参与。开发团队也完全可以在领到任务开始做的那一刹那,由领到任务的一对pair自己讨论how就可以。

总结一下就是 PO自己搞定planning,PO和团队一起kick off,团队自己搞定how。IPM不占开发团队时间,IKM 2个小时足够,其它的讨论分散在开发过程中

每日站会: 关注接力棒, 而不是运动员

站会到最后是最流于形式的会议,没有之一。原因很多,而一个比较普遍的原因是大部分站会关注在了错误的点上,引不起团队成员共鸣。这个错误的点就是关注每个人都干了啥,今天要干啥。站会对于团队成员就成了一项考核,考核你工作量饱不饱满。每个人挖空心思表明自己没闲着,说完自己的就完事,也不管别人的。

那么站会正确的关注点是什么? 进度,障碍,新知,及是否要进行调整。关注接力棒,而不是运动员

每日站会是进度报告会吗? 你可能会说不是。我只能说: 当然是了! 开完会对当前进度是什么样子都不知道,这会也太浪费时间了,甭管是半小时还是仅有10分钟。 (你说我们有其它方式了解进度,站会关注在其它方面,那是另外一回事)

站会首先是进度报告会,区别在于是向谁报告,报告的目的是什么。站会是向整个团队报告进度,目的是寻求帮助,提供新知,为可能的任务调整提供真实的输入。站会是以天为周期的PDCA环中重要的一步,负责Check和提出Action。Check时检查点不在谁闲着谁没闲着,而在于过去这一天有哪些新的信息会影响到任务交付。

评价站会效果的唯一方式是,会后有没有根据会上的信息做出相应调整。不排除不需要调整的情况,但很少。换句话说,如果你站会后没有调整,那你的站会是极有可能没什么效果的。

Sprint回顾会议

没什么可说的。只要回顾会议有效果,其它问题再大都是小问题。当回顾会议没有效果的时候,问题就大了去了。其它问题都可以在技巧层面针对问题本身改进。但回顾会议没效果的话,改进回顾会议本身是没有用的。

评价一项活动,不是看它过程,甚至不是看它结果,要看它对其它事务的影响。站会/回顾/评审会议,都涉及调整。开完会没什么调整, 会就白开了。

Share

为什么你的Scrum会失败?(一)

Scrum失败的原因有很多,很普遍的一个是:忽视其众多前提而仅仅把现在的基层开发组织按照Scrum要求的那三种角色改了一下,就算是上马了。很快Scrum也就像它的音译那样,变成死马了,仅留一身马皮。我们来看一下为什么仅仅把基层开发组织改组为Scrum团队是不奏效的。

角色一, PO: PO的任职资格

在我所见过的Scrum团队中, 绝大部分PO是不具备PO的资格的。不是说能力,而是资格。PO从职责上讲拥有Product Backlog,负责决定哪些功能进、哪些功能不进、优先级是什么。换句话说:PO负责产品的方向。Product Owner这个词从字面上也赋予了PO这种职责,但与这种职责相伴的是对应的资格,是必须有资格能够负责产品的方向,你才能负责产品的方向。那么通常都是什么样的人有资格负责产品的方向呢?

  • 如果你是一个定制化开发项目、企业应用,毫无疑问,客户才有资格负责产品的方向
  • 如果你是一个产品项目,面向多个潜在客户,那么你们组织里面谁对产品的成败负首要责任,谁就是PO。

换句话讲, PO通常是资方而不是劳方的人,PO要么是给项目提供资金的人, 要么是他的代言人。通常出钱的人是老板,很忙,在大的组织里不太可能直接出任PO,但他必须把他的职责代理给某个人,而这个人是要对产品的成败负责的,出了事之后他要负主要责任。

如果PO不需要对产品的成败负首要/主要责任,那么他/她关于Backlog的范围和优先级的决定是不可信任的,不是说他/她这个人不可信任,人可能是好人,找你借钱你也愿意借给他/她,但由于他/她不需要负责,他/她的决定是没有权威性的。

在我见过的运行的比较好的Scrum团队中,担任PO的人都满足上面的任职资格,包括客户本人,包括从头到尾负责一个产品很多年的人等。而运行的不好的Scrum团队中,PO通常由原先开发团队中的业务分析师担任,仅具备一定的业务能力,而没有商业上的资格和权威。

角色二, Scrum Master: Scrum Master的悖论

在我所见过的Scrum团队中,绝大部分Scrum Master是没有认识到自己的使命的。Scrum Master的使命就是把自己做没,不是做媒,是做没。

Scrum Master这个角色深深反映了Scrum内在的不一致性。我们只需考虑这么一个问题:如何评价Scrum Master的工作成果? 如何证明一个人是合格的Scrum Master? 你会发现如果Scrum Master做的好, 他会把自己的大部分工作做没,变得越来越轻松。因为Scrum Master按照定义,从根本上来说就是一个教练的角色,教会团队自组织、教育PO、教育开发团队、教育组织里其它Stakeholder。评价教练的唯一标准就是被教授的人不再需要他/她了。

也就是长久来看,Scrum运行的好的话,对Scrum Master的需求会越来越少,这个职位甚至不再需要专职的人了,而这在Scrum的教义中是不推荐的。有的团队Scrum Master是兼职的,平时还有一部分开发的职责,不知道是不是认识到这一点之后未雨绸缪…

然而如果Scrum Master认识不到这一点的话,对团队的破坏将是巨大的。他/她会不由自主的为自己找事做,无形中破坏了团队的自组织。所谓自组织其实很简单,就是不去干预。如果团队在众多内部关于流程/活动/角色/职责等事情上需要Scrum Master的干预,则离自组织还很远。

那为什么球队永远都需要一位教练? 答案很简单,因为球队教练的职责是赢球,而不是教会球员自组织。如果他通过让球员在场上自组织来赢球,那球队确实对他的依赖会减少。

角色三, 开发团队: 开发团队自组织的假象

在我所见过的Scrum团队中,不是自组织,而是没组织。原先的Project Manager/Business Analyst/Developer/Tester的职责随风而去,现在统一称Team Member了。每个人在新的组织方式中无所适从,而Scrum Master经验不足、机械的、一厢情愿的抹平角色的差异,导致工作分配/领取出现众多状况,影响进度。

那么我们来回答一下这个问题:在Scrum的开发团队中, 还有PM/BA/Dev/Tester等分工吗?

答案是, 可以有。

什么,这难道不是在Scrum教义中被明文禁止的吗?

Scrum确实禁止了,但谁让它又开了个”自组织”的口子呢?如果团队自组织起来,开了个讨论会,觉得这个Sprint,谁谁谁,你去负责跟PO接口,搞清楚需求细节;谁谁谁,帮忙把CI环境弄稳定点;谁谁谁,把上个Sprint的功能没来及测的再测一下, 剩下的人都去做开发…这个会开完之后, 团队在这段时间内有了明确的分工甚至角色,只要团队觉得合适,团队觉得这样是在当前约束下完成工作最合适的方法,又有何不可呢?

本文原文来源于>>>>http://liguanglei.name/blogs/2015/05/04/why-your-scrum-failed/?from=timeline&isappinstalled=0

Share

敏捷咨询日记——沟通问题

强调沟通和杜绝浪费是敏捷最核心的东西,这两项基本是贯穿我这次咨询活动的主线-任何细微的活动都需要用心审视两个问题:我做这件事情的前提是传递价值给团队另一个人,那么价值的传递过程中有没有沟通的阻碍?价值的传递过程有没有什么东西导致了传递损耗既是浪费?从一对一沟通谈起,逻辑是你不可能消除所有的沟通壁垒,譬如你的口齿不够清楚,那么至少发现那些你可以消除的壁垒,消除它,并告知和提醒你的听众那些你不能消除的。往往人们犯的错误是:

  • 察觉不到那些可能成为沟通壁垒的微小细节;
  • 对自己不能消除的壁垒过分乐观;
  • 对自己的听众过分乐观;

很多微不足道的东西都可能称为沟通壁垒。传统上,邮件和文档理所当然称为阻隔沟通的最大障碍。文字的修辞不如口头表达直白有效;文字很难达到及时的确认反馈;超过一定数量的文字考验被交流者的耐心;绝大部分的文档撰稿人无法理解文档是一种用户界面的思想,我所看到的情况,大部分的文档达不到可读(readable)的标准。

未曾想到的是,某种不经意的细节也许也能成为沟通的障碍,譬如,某个不及时统一的术语运用,因为小,更容易被听者忽略或者不愿意直接打断;或者某个图省事的英文缩写;或者一个白板上随意的箭头;或者某个夹在在中文里的英文单词。归根结底,任何沟通的承载物都是一种界面(interface),界面设计种盛行的”Don’t make me think”完全应该引入到你的任何一次沟通中来。就跟蹦出个对话框说“对不起,请耐心等待上传结果”的意义跟“对不起,我的普通话不标准,如果有听不清楚的地方,请打断我”一样,都是一种降低使用者(被沟通者)预期的方法,目的都是达到更好的沟通效果。

当然,更重要的是提升自身的沟通技巧。这里面有几种技巧是可以提供帮助的:

学会察觉沟通者的身体语言

据说有60%的沟通依靠身体语言,熟悉几种常见的身体语言和它们背后的故事会有帮助。譬如,说反馈的话却不对着你说而是对别人笑,代表他不确定自己的观点是不是受人支持,希望找到这种支持;双手护胸代表对你的内容有抵触,他有更多自己不同的看法;双手叉腰,虎口对你代表疲倦,虎口对内代表急于表达自己的看法;看着茶杯喝水代表对你说的内容不感兴趣,看着你喝水代表对你说的极感兴趣;低头看你代表不信任,把某一边耳朵倾向你代表很关注你的内容,扬起下巴两指拖着代表关注并思考,等等。

会展现你的观点

画图是最好形成共识的工具,相当于一个美的用户界面。居我观察,A公司的专家没很少有能够干净准确表达自己观点的,共同的问题是,要么就不画,要画也是不知道如何画,最后的结果是白板上什么都不是。因为国人的教育偏究其理而轻表其象,也许这种技能是无法在短时间内获得,但是,根据大熊这个把Parking Lot画成熊猫的同志的经验,画的时候不要着急,画一点是一点,对自己要求严一点没画好的地方擦掉重画。

要持续确认

敏捷最美的地方在于任何活动都遵守敏捷原则,在沟通的过程中需要持续地把各自的理解与对方确认,可以说:我是不是可以这样理解…等等。

要鼓励对方进行沟通而不是制造障碍

譬如,很多人在一个阐述的结尾喜欢加:你明白我什么意思吗?或者,你能理解我的意思吗?等等,这样的话很容易让人在每个“吗”字后面不自觉地加一个“笨蛋”,认为这时候说不明白会有一种羞耻感,因此,更换成:我不知道我是不是表达得很清楚?或者,我会不会说得有点不太明白?会起到更好的效果。

要把已经达成一致的东西展示出来

看!这又是敏捷原则之一-阶段性的showcase,对于不再需要重复已经达成一致的观点,应该及时写出来,因为接下来的某些言论如果是基于一个已经达成一致的观点,风险会降低很多。你可以使用身边的纸笔,最好是白板纪录下这些内容。

(编者按:五年后再看这个会议沟通海报,据说已经变成了文物展出)

关于沟通的问题,也许还有更多的话题可以探讨,更重要的还是实践中的体验。作为ThoughtWorks的面试人员,沟通可是我的第一加分点,一个乐于或者善于沟通的人往往离成功不远,是我最欣赏的品质没有之一。

Share