写点什么

自组织敏捷团队的领导关系

2013 年 5 月 02 日

实现自组织敏捷团队的组织依然需要管理者,但是管理者和他们团队之间的交互方式将会改变。对于那些为了实现自己的目标而工作的团队而言,管理者控制他们方式不再是告诉他们应该如何工作,而是应该建立一种服务型的领导关系,指导团队学习并持续提升他们自己的能力。

作为数字营销机构 Ciplex 的创建者,Ilya Pozin 在一个 LinkedIn 帖子想要公司发展么?解雇你的管理者中描述了,为了提升工作质量并且使雇员保持愉悦的心情他在自己的公司中做了哪些事情。他的公司正是通过这些事情让客户感到满意,同时降低了成本并且获得了更好的整体结果。他实现了一个面向目标的团队文化和支持学习并持续提升的领导关系,这和敏捷软件开发中使用的事情非常相似。在他的公司中,创建的团队和自组织敏捷团队相似:

我创建了 3 到 5 人的小团队,并且移除了这些团队或者团队成员中的所有“老板”。我还移除了这些团队中的所有“高级”或者“VP”头衔。尽管一个团队中的领导者将自然而然地浮现,但是依然没有必要使用一个严格的报告结构。

管理者为团队指定工作目标,但是并不会告诉他们该如何实现这个目标。团队使用 Scrum 冲刺的方式工作,同时会经常反省以提升自己:

我为每个团队指定了一个目标,这个目标能够很容易地在短时间(如 1 周或 2 周)内进行衡量。这使得雇员能够真切地看到他们工作的产出——这样他们就能够关注为什么要这样做而不再是该怎么做。给定一个目标并且坚持短时间框架,团队就能够衡量他们的性能并且从之前的错误中学习,还能够在下一个时间周期内获得提升。

团队由服务型领导关系管理:

管理者和老板应该重新定位,他们应该为团队提供支持,为团队工作,在他们所需要的任何地方帮助他们。之前的高层主管提供帮助和支持,而不是告诉雇员该做什么,该如何做。

同时应该辅导团队成员,这样他们就能够从自己遇到的问题中学习,并且能够解决它们:

不要纠正雇员或者解决他们的问题——而应该通过领导关系引导、支持他们。如果有一个问题,那么应该询问关键的问题从而引导他们找到解决方案,而不应该直接跳到解决方法,让自己占有支配权并拥有问题。

Ilya 在 LinkedIn 上发布的这个帖子介绍了自组织团队和领导关系如何为公司创造价值。今年的早些时候,InfoQ 也发布了一篇自组织团队的文章,该文章介绍了一个组织如何变成自组织,以及他们从这个过程中学到的知识。

在 Dzone 的文章自组织团队必须对领导关系做哪些转变?中,Gil Zilberfeld 谈论了领导敏捷团队,以及组织为了采用领导关系能做哪些事情。他解释了“自组织团队是否需要一个领导者?”这个问题:

无论我们是否愿意,我们都将看到领导者出现。这是自组织的一部分。因此,将会有一个或者多个带有不同类型影响的领导者。我们不能提前知晓谁将成为领导者,我们也不能主导这个过程。

根据 Gil 所言,管理自组织团队需要一个不同的管理模式,这个模式能够支持并引导团队,帮助团队更加高效:

我们需要理解自组织团队要比命令—控制这种金字塔型的团队更加有效。作为管理者,我们需要退一步,让团队获取自治权从而让其更加高效。

为了成为高效管理者,需要知道如何让自组织团队自我进化。我们需要告诉他们所有的复杂性和不确定因素,如何退一步从外部影响自组织团队。

在博客帖子领导一个敏捷团队就像拥有猫中,Mike Bovich 使用比喻描述了为了支持他们的团队敏捷领导者能够做什么。首先,他解释了自组织敏捷团队请求按照管理他们的方式进行改变:

为了成为一个高效的敏捷领导者,你必须愿意放弃控制权并且为团队服务。对于我们中的大多数人而言,这可能是最大的挑战——它有悖于我们的本能,但绝对是成功所必须的。

开发者是非常复杂的。每一个人都有各自的行为方式,而理解他们的唯一方式便是投入时间。就像猫一样,他们能够讲出真正有兴趣的人和仅仅是走过场的人之间的区别。投入时间,你将收到回报。忽略你的雇员,你将发现生产力受损。

根据 Mike 所言,敏捷领导关系会促进可持续开发,同时也会平衡工作和娱乐时间:

期望你的团队努力工作,但是也不要太过分。在工作完成之后,确保团队有时间放松,如果团队持续疯狂的工作,那么无论对谁都没有任何好处:生产力会降低,士气也会低落。作为一个敏捷领导者,期望团队能够高效工作没有问题,但是记得要保持平衡。

Steve Martin 在博客被遗忘的敏捷成员:管理和高级管理人员中解释说,为了能够成功地进行敏捷转变,管理者和高级管理人员的角色必须发生改变:

仅仅因为你有自组织,授权敏捷团队并不意味着管理或者高级管理人员不再有所牵连。他们依然不可或缺,没有这些角色,你推动的敏捷就有风险,这通常不会收到预期的回报。但是转变可以,为了做到这一点管理和高级管理人员是必不可少的。这也需要他们转变角色,就像团队成员的角色一样。

在敏捷转变过程中,管理者、高级管理人员和团队之间的领导关系和协作是非常重要的,涉及的所有人员对此都有贡献:

高级管理人员需要参加并就职,但他们不是主导者。这是一条好的实践路线。

管理者的角色应该转变为指导者和问题解决者,而不是每天亲自进行管理并分配工作。

团队也必须开放,并且愿意接受来自于管理和高级管理人员的意见并给出反馈。

查看英文原文 Leadership for Self-Organized Agile Teams

2013 年 5 月 02 日 09:131786
用户头像

发布了 321 篇内容, 共 103.4 次阅读, 收获喜欢 8 次。

关注

评论

发布
暂无评论
发现更多内容

图说前端-使用Atomics避免SharedArrayBuffers中的race conditions(3/3)

梦见君笑

前端 内存管理 前端进阶训练营

ARTS 打卡 第2周

Scotty

如何搭建一个HBase集群

Rayjun

HBase

啃碎并发(九):内存模型之基础概述

猿灯塔

Java 猿灯塔

图说前端-ArrayBuffers 和 SharedArrayBuffers(2/3)

梦见君笑

前端 内存管理 前端进阶训练营

那些让程序员目瞪口呆的Bug

Java小咖秀

程序员 程序员人生 bug

架构师训练营第六周总结

陈靓-哲露

云原生实践系列:概述

孤岛旭日

Serverless 微服务 Service Mesh 服务架构

架构师训练营第六周总结

hiqian

redis系列之——Redis为什么这么快?

诸葛小猿

Java redis 程序员

DOM 树的构建

法正

html DOM 前端进阶训练营

基于Kubernetes实现的大数据采集与存储实践总结

岿然独存5

Docker Kubernetes S3 EFK Fluentd

RESTful 架构及实践

pingan8787

Java 前端 RESTf

【计算机网络】网络层——路由器与路由选择协议

烫烫烫个喵啊

计算机网络 网络层

redis里的数据结构

流沙

redis

架构师训练营第六周作业

张明森

不会有人还不知道全文检索工具Lucene怎么用吧?文字长文教程

给你买橘子

Java 搜索引擎 lucene 程序员 开发工具

架构师必须知道的架构知识

Chank

架构 架构师 Architecture Architect

图说前端-内存管理(1/3)

梦见君笑

前端 内存 前端进阶训练营

Java 线程的生老病死

武培轩

Java 线程 多线程 并发 线程状态

计算机的时钟(一):NTP协议

ElvinYang

DolphinScheduler-1.3.0-dev功能体验

Eights

hadoop 大数据任务调度

玩转Redis高可用 - 哨兵(Sentinel)模式

Man

高可用 redis高可用 中间件

分布式系统的一些基础理论

俊俊哥

分布式事务 CAP Base

基础篇:JAVA基本类型

csc

Java Java 25 周年

游戏夜读 | 如何分析游戏体验?

game1night

数据分析之AB testing实战(附Python代码)

JackTian

Python 编程 程序员 数据分析 AB testing实战

如何基于 BitMap 进行海量数据分析

GrowingIO技术专栏

互联网 数据分析 科技互联网 数据化

给 Spring Boot 项目减减肥!18.18M 到 0.18M 是如何做到的?

给你买橘子

Java 程序员 Spring Cloud 编码 SpringBoot 2

java 后端博客系统文章系统——No3

猿灯塔

基础篇:Object对象

csc

Java Java 25 周年

混合云之争的开端与终途

混合云之争的开端与终途

自组织敏捷团队的领导关系-InfoQ