专注要事、把手弄脏、高效优雅是对抗规模化焦虑的好办法--读Getting Real(达成现实)和 Rework(重塑工作)

飞机上读完了来自著名敏捷产品开发小公司–37signals的两本书,Getting Real《达成现实》和 Rework 《重塑工作》,后一本是前一半的升级版。作者是大名鼎鼎的Jason Fried / David Heinemeier Hansson / Matthew Linderman。讲述在VUCA(乌卡)互联网时代,用聪明、快速、容易的方式构建一个成功的产品。

最能够引起共鸣的,第一个是专注,专注于问题的关键,专注于客户价值,专注于要事,分清轻重缓急,敢于说“不”。第二个是“动手,别吵吵”,把手弄脏同时拥抱变化,迅速决定下一个小目标,然后完成它,从成功的成就感和经验中迭代前行。第三个是高效的适量工作远好于过量的低效工作,轻松优雅地平衡好生活与工作,在路上要不时地抬头望望天。

正巧在看到一篇文章,关于今日头条旗下悟空问答高薪挖角快手和知乎社区大V(即头部作者和活跃答主)。这些有价值的知识内容是日积月累,彼此启发而慢慢产生的。“但对于估值已经超过200亿美元的今日头条,规模化焦虑正变得越来越强烈,以至于它根本没有耐心花数年时间去经营一个可以源源不断长出优质内容的社区或者生态。他需要所有能让用户沉迷的东西,而不是真正有价值的东西,在尽可能短的时间内聚集到自家平台上来。在别人建造的森林里,寻找最粗最壮的大树,砍倒,拖走,插到自家的花园里,然后就可以骄傲地宣称:我们拥有一片最牛逼的森林,这里没有树苗,没有小树,甚至没有生长过程,每一棵树生来就是最牛逼的参天大树。”

这像极了现在火爆的敏捷培训和咨询市场,特别传统大型咨询公司,也想来分一杯羹,试图快速复制一套商业模式结合手上的客户资源,来帮助那些同样传统的大型公司来进行组织规模化敏捷转型,甚至所谓创新。可行吗?不知道,反正已经有一头大象失败了,但是还有更多的大象会想试试,我们冷眼旁观,继续做好自己的事情就好了。

回到这两本书,不论是思维还是实践,都和我们现在这个打造中的小而美的“海豹突击队”很像,也坚定了继续前行的决心,不管是领导力和敏捷教练、精益创新产品咨询、Scrum认证培训、Design Thinking等等。我们这个团队不会拒绝长大,但绝不会急于拔苗助长。踏实地开创一项生意,而不是一个臃肿复杂的怪物。多少初创团队急于扩展规模、接受投资,只会沦为傀儡,忘了初心。

读书笔记

继续阅读 More

硬件产品增量分拆于规模化敏捷Scrum研发中

如何分拆硬件研发中的产品增量?

这个例子来自德国纽伦堡的某个硬件产品团队,他们在5年前开始导入LeSS(大规模敏捷)。

产品领域是电信硬件和软件,其中关键是cross connect board(某种PCB电路板),包含电源、FPGA–现场可编程门阵列(其中一些最终融入到ASIC–专用集成电路中)、设备驱动等。

一个架构要点是,容错是非常重要的;一块PCB电路板经常具备另一块“B计划即故障切换(failover)板子(想象该cross connect board”方案具有A板和B板),即使在单块板子上也会有容错处理(例如:从外接电源切换到电池)

继续阅读 More

以社交活动的方式做计划-乐高公司的规模化敏捷

Henrik Kniberg & Eik Thyrsted Brandsgård

2016年12月

原文授权链接: http://blog.crisp.se/2016/12/30/henrikkniberg/agile-lego

翻译&审校:
李洁(Jerry Li) 何强 龚正 姚宇宏(Ella Yao) 陈婧(Elina Chen) 申健(Jacky Shen)

统筹&出品:申健(Jacky Shen)

2017年1月

中译文链接:http://www.jackyshen.com/2017/01/31/planning-as-a-social-event-scaling-agile-at-lego/

— “什么?一个150人的团队会议只要(2天)1天?”

— “对啊!每两个月一次。运行得非常好。”

— “但是为什么这样?怎么做到的?”

背景

乐高数字解决方案部门(DS)由20个左右的团队组成,负责处理孩子和家长手中各种设备- 普通电脑,平板电脑,各种app应用,可穿戴设备,虚拟现实设备等等进行通讯。我们同时也在展望未来的产品开发,如何去拥抱新的技术,如何将传统的玩法与酷炫技术,例如增强现实结合起来,或者找一种能够将一个物理模型“扫描”进游戏的方法。绝大部分的团队在丹麦的比隆,但是我们在印度也有一部分团队。

继续阅读 More

Spotify的敏捷工程文化

Spotify是继Pandora之后,国外第二大音乐媒体网站。上一篇
Spotify的新型敏捷矩阵组织:部落、分队、分会和协会出了以后,很多人对Spotify的敏捷组织形式非常感兴趣。这里@申导 抢鲜给大家带来第二部分,关于Spotify的敏捷工程文化

第一部分主要提到基于敏捷原则,将人按照小分队Squad的方式来组织,松耦合但紧密联盟(Align)。通过内部代码开源,鼓励“异花传粉”。通过架构解耦、特性开关等手段来做到频密的小规模发布。借助自助的发布和部署服务,减少人们之间的任务交接。所有一切都关于“人”,因此组织更加要关注激励、信任与社区文化,而非等级结构或控制。

第二部分讲的是关于失败,用Spotify的创始人Daniel的话说就是,“我们要比其它人更快地犯错误”。因为失败意味着学习,因此更快地失败就意味着更快地学习,更快地改进。

继续阅读 More

J.P.摩根运用LeSS框架实施大规模敏捷

顶尖金融服务企业中的大型组织是如何采用大规模Scrum框架(LeSS)的?

背景

J.P.摩根的全球核心处理技术集团由Simon Cooper领导,是一个遍布全球的3000多人的组织。2013年集团决定要改变为(真正的)Scrum,并采用Large-Scale Scrum(LeSS)框架,这意味着在组织设计要做出相应改变。

之前他们曾零散地采用了”Scrum-But”及各种敏捷工程技术,主要是在开发团队中,但现有的权力和组织结构并无显著改变,与业务的交互也是一样——仍然是“合同谈判”而非“客户协作”。仍然存在负责交付“合同”的研发项目经理、团队主管、单一职能的专家角色,以及单独的组件团队和职能团队(比如测试团队)。

年初Craig与Simon Cooper及其直接下属的经理做了一次有力的对话,随后他们就决定将组织设计转变为基于LeSS的Scrum框架。

这次领导力对话认清了组织中目前“合同游戏”的动态,它阻碍了组织提高敏捷性和改善以客户为中心的特性交付。

这次领导力对话也针对真正的特性团队进行了探讨——跨组件和跨职能团队,它可以端到端地交付客户特性,不存在移交、依赖或延迟。这需要消除组织内的藩篱,比如职能部门和组件团队,以及相应的经理角色。


继续阅读 More

Spotify的新型敏捷矩阵组织:部落、分队、分会和协会

组织导入敏捷往往更加关注形式和标准化,然后却发现不同团队的接受程度不同。 这里介绍了Spotify 的大规模敏捷之路。Spotify是继Pandora之后,国外第二大音乐媒体网站,在从6个人扩张到1200人的过程中,它使用一种了新型的矩阵组织来扩展:部落、分队、分会和协会。

继续阅读 More