More Related Content
More from AHAConference (12)
翻转组织
- 14. 14
GE Title or job number
5/5/2015
第二个故事:成长的烦恼
码农翻身做主人后,速率腰斩!!!
成年礼让团队站了起来,但团队还需要时间学习走路
- 15. 15
GE Title or job number
5/5/2015
成年团队学步三部曲
第一步:迈出“扛事儿”的前
脚—勇担当、善担当
第二步:跟上“能力”的后
脚—先功能、后联盟
不断前进:互激励,共前行
- 16. 16
GE Title or job number
5/5/2015
第一步:迈出“扛事儿”的前脚—勇担当,善担
当
通过引导,把项目经理管理 ,转变为团队自己管理
团队为自己制定的目标后成年礼
挑战:团队需要学习如何自己管理进度、质量和发展方向
- 17. 17
GE Title or job number
5/5/2015
第二步:跟上“能力”的后脚—先功能
“群狼”workshop
结对编程2.0—男女结对,干活不累
!
打造功能纵队的关键是促进团队内部有效的学习
功能纵队
挑战:团队中对功能熟的只有一两个人,其他队员无法发挥
- 18. 18
GE Title or job number
5/5/2015
第二步:跟上“能力”的后脚—后联盟
组件设计联盟:关注组件设计,提升内在质量
测试验证联盟:关注验证技能,提升验证有效性
打造横向联盟的关键是守望,抓住机会,建立机制
挑战:团队专注在功能团队的目标上,忽略了横向协作
- 19. 19
GE Title or job number
5/5/2015
不断前进:互激励,共前行
各团队的Sprint Report & 互赞结
果
团队之间相互感谢
互激励:通过营造“比、学、赶、帮”的氛围,促进团队不断成长
挑战:团队持续前进的动力在哪?
- 20. 20
GE Title or job number
5/5/2015
团队成长三字经
文化
组织
• 成人礼,始自立。
引导
• 学前行,重引导。
自管理
• 勇担当,善担当。
学习
协作
• 先功能,后联盟。
自激励
• 互激励,共前行。
成长
• 积跬步,至千里!
- 21. 21
GE Title or job number
5/5/2015
大象起舞:敏捷传染病
软件敏捷带动了整个研发部进入了敏捷节奏
敏捷
Planning Daily meeting
Daily CollaborationReview
Editor's Notes
- 医疗背景介绍
上一个项目情况
这个项目情况
引出变化。
我们是来自GE医疗外科软件团队的的XX,XX,还有我们的敏捷Coach Daniel.今天要分享的题目是,翻转组织,说得是在敏捷实践中关于团队和人的那些事.
为什么想分享这个题目呢?因为我们觉得我们团队的经历,对那些采用传统的软件开发方法,还没接触敏捷实践和刚接触敏捷实践不久的团队和人来说,还是有一定代表性的,可能带给大家带来一些敏捷实践中的启发和思考。大家可能有所了解,GE医疗是一家传统的大型工业公司,在医疗设备的研发,生产,销售中有非常深厚的基础和悠久的历史。而且,在医疗设备制造领域,还面临着各种各样法规与机构的监管与约束,这也导致项目的研发面临很多困难与挑战。我们团队是做外科手术中使用的成像设备,这种医疗成设备。在我们上一个产品的开发中项目,历时两年多,软件团队的开发方法采用的是RUP,那时候还没有采用敏捷的方法和实践思想,在项目的后期软件测出了很多bug,软件开发工作从开始到结束一直是项目的瓶颈,最后项目结束时比之前的计划延期了半年。在这一个项目开始前,软件团队开始尝试去做一些改变,期望能够改善一些不好的情况。从目前的观察来看,这个项目还算进展的很顺利.说来也巧,就在今年,公司需要我们当前正在开发的项目能够满足客户需要,早日上市,为了实现这一目标,经过多方讨论与评估,,软件团队的多个角色人员都发挥了作用,为达成这一目标作出了贡献,最后得出需要通过调整项目的部分scope来才能达成目标。调整scope的工作进展的非常顺利,没有对当前的工作造成任何影响。同时也已完成的工作也没有因为调整scope而产生浪费。所有已完成的功能都是项目调整范围之内的。工作都是有价值的。这件事情如果发生在上一个项目,是很难想象的。那么,在这中变化背后,我们的团队到底发生了什么样的变化呢,我们对我们过去一段时间的变化进行了整理,并在此分享给大家,希望能能对大家有所帮助。
背景放一个Carm
- 上一个项目的反思
反思后的尝试
Coach的观察
Manager与coach的讨论
引出成年礼
在上个项目结束后,我们软件团队的manager,组织大家对上一个项目进行了总结和反思,总结后,开始推动团队解决之前的主要问题:问题暴露得太晚。于是开始了一些敏捷实践的尝试。最初的尝试过程中,我们的manager 带领着团队中较资深的工程师讨论并定义了team的组建,以及敏捷开发过程的的步骤与方法。在今年年初时,敏捷教练团队(也就是Daniel他们)来到我们团队,经过几天的观察和评估后,敏捷教练团队就跟我们的manager指出我们当时主要存在的问题有团队之间的依赖比较严重;团队更像technical team, 不像feature team;每个team都维护一份PB,影响了从business的优先级角度去计划和完成feature.要解决这些问题,需要对组织架构作一个调整。Manager非常认同coach的这些观察和总结,然后在manager的强烈支持和大力推动下,决定对整个team进行一次组织架构的调整。下面我们请Daniel描述一下当时manager在于coach进行相关的沟通后做出进行组织架构调整的。(介绍coach与manager的交互及为何要通过自组织设计).
决定要调整组织架构之后,接下来便须要考虑如何进行组织架构的调整了。首先需要定义的组织架构的框架。即整个软件Team到底要分成几个scrum团队,每个团队几个人。谁担任PO,Scrum master有几名,Architect如何定义。整个组织架构的框架是在manger综合考虑多方因素后定义下来的。接下来的问题是scrum 团队如何产生,SM如何产生。仍然是在Manager的大力支持下,采纳了coach的建议,决定采用自组建的方式产生各个scrum团队和SM。
那么为什么要采用自组建的方式来产生scrum团队和SM呢,我们请Daniel给大家解释一下他们当时的所思所想.
当我们得知要自组建团队的消息后,很多人都对这种自主建团队的方式感觉到很好奇和担心,一方面是没想到经理会这么放心的让大家自己做决定,另一方面也担心,这样出来的结果能行吗,会不会对整个Team带来不好的结果。通过这个过程我们可以看出,所有这些变化的开展和推动,我们的manager在其中发挥了关键的作用。
- 上一个项目的反思
反思后的尝试
Coach的观察
Manager与coach的讨论
引出成年礼
在上个项目结束后,我们软件团队的manager,组织大家对上一个项目进行了总结和反思,总结后,开始推动团队解决之前的主要问题:问题暴露得太晚。于是开始了一些敏捷实践的尝试。最初的尝试过程中,我们的manager 带领着团队中较资深的工程师讨论并定义了team的组建,以及敏捷开发过程的的步骤与方法。在今年年初时,敏捷教练团队(也就是Daniel他们)来到我们团队,经过几天的观察和评估后,敏捷教练团队就跟我们的manager指出我们当时主要存在的问题有团队之间的依赖比较严重;团队更像technical team, 不像feature team;每个team都维护一份PB,影响了从business的优先级角度去计划和完成feature.要解决这些问题,需要对组织架构作一个调整。Manager非常认同coach的这些观察和总结,然后在manager的强烈支持和大力推动下,决定对整个team进行一次组织架构的调整。下面我们请Daniel描述一下当时manager在于coach进行相关的沟通后做出进行组织架构调整的。(介绍coach与manager的交互及为何要通过自组织设计).
决定要调整组织架构之后,接下来便须要考虑如何进行组织架构的调整了。首先需要定义的组织架构的框架。即整个软件Team到底要分成几个scrum团队,每个团队几个人。谁担任PO,Scrum master有几名,Architect如何定义。整个组织架构的框架是在manger综合考虑多方因素后定义下来的。接下来的问题是scrum 团队如何产生,SM如何产生。仍然是在Manager的大力支持下,采纳了coach的建议,决定采用自组建的方式产生各个scrum团队和SM。
那么为什么要采用自组建的方式来产生scrum团队和SM呢,我们请Daniel给大家解释一下他们当时的所思所想.
当我们得知要自组建团队的消息后,很多人都对这种自主建团队的方式感觉到很好奇和担心,一方面是没想到经理会这么放心的让大家自己做决定,另一方面也担心,这样出来的结果能行吗,会不会对整个Team带来不好的结果。通过这个过程我们可以看出,所有这些变化的开展和推动,我们的manager在其中发挥了关键的作用。
- 上一个项目的反思
反思后的尝试
Coach的观察
Manager与coach的讨论
引出成年礼
在上个项目结束后,我们软件团队的manager,组织大家对上一个项目进行了总结和反思,总结后,开始推动团队解决之前的主要问题:问题暴露得太晚。于是开始了一些敏捷实践的尝试。最初的尝试过程中,我们的manager 带领着团队中较资深的工程师讨论并定义了team的组建,以及敏捷开发过程的的步骤与方法。在今年年初时,敏捷教练团队(也就是Daniel他们)来到我们团队,经过几天的观察和评估后,敏捷教练团队就跟我们的manager指出我们当时主要存在的问题有团队之间的依赖比较严重;团队更像technical team, 不像feature team;每个team都维护一份PB,影响了从business的优先级角度去计划和完成feature.要解决这些问题,需要对组织架构作一个调整。Manager非常认同coach的这些观察和总结,然后在manager的强烈支持和大力推动下,决定对整个team进行一次组织架构的调整。下面我们请Daniel描述一下当时manager在于coach进行相关的沟通后做出进行组织架构调整的。(介绍coach与manager的交互及为何要通过自组织设计).
决定要调整组织架构之后,接下来便须要考虑如何进行组织架构的调整了。首先需要定义的组织架构的框架。即整个软件Team到底要分成几个scrum团队,每个团队几个人。谁担任PO,Scrum master有几名,Architect如何定义。整个组织架构的框架是在manger综合考虑多方因素后定义下来的。接下来的问题是scrum 团队如何产生,SM如何产生。仍然是在Manager的大力支持下,采纳了coach的建议,决定采用自组建的方式产生各个scrum团队和SM。
那么为什么要采用自组建的方式来产生scrum团队和SM呢,我们请Daniel给大家解释一下他们当时的所思所想.
当我们得知要自组建团队的消息后,很多人都对这种自主建团队的方式感觉到很好奇和担心,一方面是没想到经理会这么放心的让大家自己做决定,另一方面也担心,这样出来的结果能行吗,会不会对整个Team带来不好的结果。通过这个过程我们可以看出,所有这些变化的开展和推动,我们的manager在其中发挥了关键的作用。
- 成年礼的几部分内容
内容背后的逻辑
在决定了进行组织架构的调整后,在coach的引导和帮助下,我们整个团队便举行了成年的仪式---成年礼,也就是我们的团队自设计过程。
那么成年礼要怎么怎么帮助大家走向成年呢?组织架构中还有两大部分内容没有确定,一是团队成员,而是Scrum master。
考虑到Scrum master这角色是为team 服务,是team的仆人?这就决定担任这个角色需要考虑本人的意愿并team的认可。因此决定SM 采用竞选的方式产生。
确定了产生方式后,在竞选开始的前两天,coach也提前在团队的微型群放风出,让大家提前准备。我当时还挺担心竞选会不会因为缺少竞选者冷场,当时共需要选出2个sM,在Coach的忽悠与引导下,结果共8名竞选者参与竞选,大家的热情非常高涨,竞争空前激烈。
SM候选人倒是产生了,但是SM的主人还没有产生,主人还没有,仆人当然还不能确定下来。因此,接下来需要组建出team。我们总共需要产生4个team。那么到底要组建出什么样的呢?怎么组建这4个team呢。为了让所有成员明白这个问题。在coach的引导下,大家给出了很多组建team的规则和点子。大家给出了很多很好的点子,像全功能团队内,像男女搭配,能力高低搭配。加班能力搭配等。在确定出大家都认可的这样一些规则后,就开始按照这些规则,开始第一轮的组合与调配,形成了4个team的初始版本。初始版后,大家再一起按照已确定的规则一个team一个team的review,并指出每个team不满足规则的bug.然后进行第二轮的改bug,调整。形成最终版的team。
事后,4个团队及manager对大家自发组织形成的团队结果非常满意.manager表示这一结果超出了预期,甚至比Manager自己带领着团队中几个资深工程师讨论定义出的团队结构更合理。
- SM选举情况场景介绍
- 介绍与细节的展示。
- 有了
- 有了
- 有了
-
欢天喜的的码农翻身做了主人后。。。。
速率减半
认领任务时,只考虑团队的学习,不考虑项目
功能团队运作不畅(功能团队)
保证了交付,内部质量堪忧(虚拟团队)
- 小孩子走路
- 将团队的目标和项目目标、部门目标进行对齐。
团队目标大会。(后成年礼)
- 侧重说功能团队
- 两步走起后,剩下的
团队之间相互激励
每个Sprint在SOS retrospect上,团队秀出进展
经理和PO给出反馈
团队互相点赞
赞数最多的团队分享好的做法
- (撬动文化,翻转组织)
(坚定信念,耐心引导)
(变被管理,为自管理)
(加强学习,促进协作)
(变被激励,为自激励)
(循序渐进,逐步成长)