扫码阅读
手机扫码阅读

更高的目标: 自我管理(Self-Managing)团队的下一步

205 2023-08-23

没吃过猪肉,也要见过猪跑


今天,我们就来见识一下“自我管理”团队的下一步长啥样?


2017年我在辅导各种团队的过程中, 发现组建Scrum team有几个困扰经理们的典型问题:

1. 到底按照feature还是component?

2. Scrum Master还必须要coding行不?

3. Product Owner没有权利验收用户故事,优先级也不是TA说了算啊!

4. SM和PO就一个人做呗!

……


这些问题有标准答案吗?如果有标准答案,经理们愿意照着做吗?现实情况允许按照标准答案执行吗?我们只能采取循序渐进的策略,但是愿景是不变的

Every feature team should be able to work on their own on every backlog item independent from the requestor.

即:每个特性团队应该能够工作在每一项backlog上并与需求方无关。

对于没有任何Scrum理念的团队,从零起步,第一步就是要做到“自我管理”。什么是“自我管理”?Self-Managing这个词源于已故哈佛教授 Richard Hackman 2002年的著作《Leading teams: Setting the stage for great performances,定义如下:

The team is responsible for executing the tasks and monitoring and managing process and progress.

即:自我管理团队负责执行任务监管过程和进度。


Hackman定义了一个团队进阶模型,看下图紫色区域,就像四个台阶。

从严格管控模式起步,团队要成长为自我管理团队,必须自己担当起下面这些责任:

  1. 团队自我检查Sprint执行状态,是否可以按照迭代计划达成目标?

  2. 如果进度落后,团队要自我采取行动,比如主动加班

  3. 团队自我决定如何完成工作

  4. 团队自我解决冲突及团队中的问题

当团队逐步成长为自我管理团队时,经理不再负责

  • 检查Sprint状态

  • 组织任何“状态会议”

  • 告诉团队要做什么,或者加班

  • 决定派哪个团队成员解决生产问题

  • 在“敏捷项目管理工具”中监视团队

  • ……

这时的团队必须保证完全透明,经理去看 (Go see) 就好了!而不是通过他们掌握的信息 (信息不对称) 来控制团队,也不会通过加点东西来跟踪团队。

请仔细看清楚,上面所述的自我管理团队的责任是需要很多能力支撑的。你是不是看到了项目经理、架构师、甚至管理者的身影?是的,自我管理团队绝不一般!核心角色和骨干成员共同担负起了管理和跟踪的职责,而且还要透明、轻量级、有效率、促进团队幸福指数~~ 不容易但是可以做到,多久可以做到?稳定的团队半年之内应该可以了。但还需要经理负责这些事情:

  • 设计团队及其组织环境

  • 设定全局方向

当一个Scrum initial team在项目经理、架构师、经理、教练等外部力量的帮助下,付出很大努力上了一个台阶,到达自我管理团队的状态后,下一步怎么走?

我还没有亲眼见过 Hackman所描述的下一个台阶上的自我设计“Self-Designing”团队,下面先用一个非常有趣的BMW案例纸上谈兵吧!期待未来可以亲眼看到或者亲手做到一个活生生的案例。


BMW请敏捷顾问Mark Bregenzer辅导了一个“Self-Designing”团队工作坊,即ReOrg工作坊!让我感受到了自治的力量!首先制定了如下议题:管理者一开始要讲清楚愿景 (即本文开头的愿景) 以及这个ReOrg工作坊的目标, 即:

  1. 更灵活地处理不同的backlog工作项

  2. 推动项目的有效性

  3. 再造团队精神

  4. 增加每个人的动力

开这个ReOrg工作坊之前,这个百人团队的阵型已经被诟病为前进的障碍, 不能灵活应对需求和优先级频繁变化, 不好扩展, feature cycle time太长,等等:

  • 有两个需求方: A, B

  • 约100名项目成员

  • 4~5个跨学科领域/组件开发团队

  • 4个横切crosscutting团队,即非开发团队

1. 持续集成CI团队

2. 缺陷与测试管理团队

3. Build治理团队 (BMW架构,BMW标准…)

4. 设计治理团队 (业务澄清,发布计划…)

  • 一个项目管理团队和敏捷教练们

  • 每两个团队有一个Scrum Master


ReOrg工作坊是为了调整阵型,把组件团队重组成特性团队。游戏规则如下:

  1. 新项目团队应该尽可能地匹配愿景 (即本文开头的愿景)

  2. 因合同问题,横切团队仍保持其结构/大小,但可能交换单个团队成员

  3. 组建5个特性团队,每个团队包括:1 PO,2 PO支持,6-7开发人员

  4. 每个特性团队必须至少有一名来自分包商的内部开发人员

  5. 团队任命自己的首席开发 (主要对接Build治理团队) 和Scrum Master

  6. PO、PO支持和开发人员自己去发现自己的团队

  7. 只要符合这些规则,项目管理就会接受每一个组织

每个人填写一张技能卡,这样在团队创建阶段可以很容易地看到可用的技能:

每个特性团队有一个团队容器板:

ReOrg行动通过三个迭代进行,第一个迭代35分钟主题为“找团队”,每个参与者都要做这些事情:

  • …面试同事

  • …要求新成员

  • …用大头针把技能卡别在团队容器板上面

然后所有人进行评审,也有三件事情:

  • …能从一个队移到另一个队

  • …检查团队是否符合愿景

  • …如果需要的话,可以在团队容器板上发布缺陷

迭代一结束时,新团队初步形成,可是有一个组件团队 (叫它Black队吧) 没怎么动。第二个迭代30分钟主题为“完善团队”,大家做了这些事情:

  • 团队尝试解决他们的缺陷,并要求Black队的支持

  • 接下来Black队的团队成员有离开的,也有少量加入的

  • Black队还不完整

  • 其他队想尽量保留他们的队员

  • 不知何故,改革进程停滞不前

然后所有人离开会议室,休息10分钟。再回来做第三个迭代25分钟主题为“完善团队”,大家又取得了新成果:

  • 参与者休息完,获得了新能量

  • 所有团队都帮助解决最后的缺陷,特别是帮助Black队

  • 当解决完最后的缺陷时,整个队伍欢呼起来!

ReOrg行动结束时,又完成了这四件事情:

  • 发现一个团队名称

  • 发现一个团队工作区

  • 投票选出首席开发

  • 投票选出Scrum Master

最后向所有人解释下一个迭代的运作规则:

  • 未完成的用户故事由开发负责人并入新团队

  • PO和PO支持刚开始仍保持他们的责任/接口

  • 各个领域专家不再只专注于一个团队

  • 工作中的缺陷仍然伴随着他们的开发人员,并进入新的团队。

  • 正在解决的缺陷由开发负责人并入新团队

  • 未开始的缺陷仍然分配给老队,由新队拉入自己团队

  • “测试管理”团队会升级没及时解决的缺陷问题

大家最后以一个词反馈来结束这个ReOrg活动

这次ReOrg即Self-Designing”团队工作坊非常成功,会后发生了很多积极变化,每个新团队被奖励一次团建活动:

  1. 非常积极的心态,正能量和激励效果

  2. 每个人都对他的新团队感到满意,甚至连没参加工作坊的成员都对他们的新团队感到满意

  3. One-team精神超出了管理层的预期

  4. 所有特性团队都能够工作在每一项backlog上并与请求者无关

  5. Social问题貌似得到了解决

上面这个案例讲述了如何从自我管理(Self-Managing)团队走向自我设计“Self-Designing”团队,这也意味着管理者就不再负责设计团队及其组织环境了,ReOrg不再是管理层自己的事情,而是所有人参与选择和完善的过程,组织环境由此而变。

原文链接: http://mp.weixin.qq.com/s?__biz=MzI3MDYwNzA4MA==&mid=2247483875&idx=1&sn=985231d21df0ac41d4608673fffade05&chksm=eacf3664ddb8bf725e9c9c321730cb84db3962517b709df1c3b8afab8fb6b6eb30233a0be3c6#rd

从事面向未来、解决问题的工作,就没有舒适区。第一需要长期培养看得懂全盘、大局的专业素质;第二需要持续学习和适应不断变化的需求和趋势;第三需要尽心尽力做好每一个项目,树立信誉和口碑。以敏捷思维赋能万事万物,我们一起在路上!

29 篇文章
浏览 8802
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线