写点什么

自组织的基础

2016 年 3 月 03 日

自组织团队理念被称为敏捷开发的秘密武器。本文试图系统化如何思考以及如何发展健康的自组织。

引言

我第一次开始思考软件开发团队中的自组织是在 2011 年。当时,除了如果你渴望敏捷,你应该拥抱它之外,真的没有多少相关文献。在如何(作为经理 / 教练 / 领袖)促进和培养自组织方面几乎没有什么建议,而且大部分建议是这几个方面:

  • 不要指派角色

  • 不要指派领袖

  • 不要指派任务

  • 不要规定方式方法

有很多不要,当然意识到问题的反模式肯定是有用的,但是很大程度上却没有回答出你究竟 _ 怎么做 _ 来支持自组织

如今,你可以更容易地在互联网上搜索到敏捷团队的自组织建议,例如这里这里 ,但是在我看来这个问题还是未被描述清楚且有待完善。我在这片文章中描述的模型并非完全独特的,但是我认为与其它描述相比,它更加的清晰,专注。我希望这片文章可以作为灵感,也许可以作为讨论如何在组织内最佳利用自组织的起点。

什么和为什么

与定义一群人截然不同,人们对团队的定义各不相同。简洁但有用的定义是:

  • 团队是一群才能和技能互补,并有着共同目标的群体。

这是一个通用的定义,并且没有特指敏捷或者软件开发团队。

有时自组织、自主、自管理团队之间是有区别的。更复杂的是不同的人对这些术语的定义不同 [1] 。本文的重点不是区分它们之间的不同。但是我写这篇文章的时候也做了一些假设:本文讨论的环境是有数个团队有着共同的或者至少相关的目的,在这个环境中存在自组织团队,以及存在围绕团队的管理架构。即团队不是自发聚集的,他们有一定程度的相关依赖性。

那么,从业务和管理的角度来看,为什么拥有自组织团队是一个好主意?虽然被认为有着完善的价值和被授权的员工这种现代化组织的确很好,但是真实原因却更加的实际;自组织是一种强大的管理策略,将会带来更好的结果,因为:

  • 为了向商业交付重要价值,将端到端的所有权指派给团队将激发人们更加优秀,最终将带来更高质量的可交付成果。

  • 局部决策意味着更快同样更好的决策,最终将带来更快的交付,这种方式更适合目的。

  • 与始终在不同任务之间切换截然不同,由于没有(或者至少很少)的交接工作,当团队对端到端负责时,你会完成的更多且更快,因为你只需要关注一件事。

除了纯粹的商务术语中的改进成果之外,运作良好、自组织的敏捷团队还应该展示一些特性或者价值,例如:

  • 承诺(Commitment)

  • 勇气(Courage)

  • 问责制(Accountability)

  • 诚实(Honesty)

  • 透明(Transparency)

  • 信任(Trust)

  • 公开(Openness)

  • 真实(Authenticity)

  • 尊重(Respect)

  • 沟通(Communication)

  • 反馈(Feedback)

  • 简洁(Simplicity)

有些文章暗示培养自组织的方法就是确保这些特性存在团队之中。但是,我想争辩的是这些特性更多的是运行良好、自组织的证明而不是培养自组织的良方。相反我想说必须有一套组织的先决条件,才有可能实现自组织。然后,考虑到这些先决条件,我们还需要铭记健康的组织在很大程度上依赖团队成员。下图试图说明这一点,即首先你需要有合适的组织资产基线,我称之为基础。在这之上你需要确保拥有健康的团队和面面俱到的个人。只有这样我们才能实现健康的自组织,拥有真正的团队价值观和行为,就像上面列出的一样。

让我们更详细地看看模型的不同层,首先从基础层开始。

基础

在基础层,我们发现如下组织基础架构 [2] :

  • 目标与效用

  • 知识与学习

  • 沟通与反馈

  • 工作方式与决策制定

  • 高标准与期望

我们简要地谈一下每一点。

目标与效用

为了得到健康的自组织,你必须有一个为之奋斗的伟大 _ 目标 _,并知道如何以正在进行的方式度量团队产量和服务的 _ 效用 _。

在经济学中,最简单定义效用的方式是货币的数量,人们愿意支付商品或者服务的货币数量。过去几年,在敏捷中非常流行使用延误成本 [3] 作为价值的度量指标,可能也是效用的最佳代理了。换句话说,团队必须有一种严格的经济术语可以用来确定其有效程度。度量价值 / 效用并非没有挑战:

  • 很难从个人用户故事层面推断延误 / 价值成本。通常你至少需要上升一个层面。

  • 甚至即使你上升一步,可靠地估算延误 / 价值成本也不是那么容易。

  • 而计算组件团队和基础设施团队的延误 / 价值成本计算就更加不容易。

blackswanfarming.com 网站上有一些指示有助于你思考价值 [4] 和计算延误成本 [5] 的紧迫性,但是为了关联你们具体的商业环境,你还需要进行大量的关联工作。

除了理解效用,团队拥有一个为之奋斗的伟大的高层次的目标同样非常重要。优秀的高层次的目标应该包括:

  • 意图和最终状态——专注于团队工作的“为什么”和需要完成的 _ 变化 _。在软件开发中,通常按照客户和业务的机会实现表述。

  • 主要努力——必须有发布一个完整产品或者进行显著变化的详细细节。定义一个努力的主要努力内容,通常以关键特性列表的方式提问,这些关键特性旨在解决手头问题。

这类似于美国海军陆战队和其他军事机构的任务指令结构形式。

许多组织在经济成果之上定义目标:收益、收益率等等。然而,作为促进自组织的手段,这种目标完全不起作用。作为能够起到有效指导的目标,你需要觉得你(作为一个团队或个人)对能否完成目标有着巨大的影响。这与你依据顶级 KPI 定义目标不同。目标应该是一些你关心的,觉得兴奋和有挑战的事情。

在目标有所成就方面,我见过的一个最佳的例子大约是在 20 年前;那时软件还是以纸盒的方式发布。那时我还在 Rational Software 工作,从事软件开发工具,Rational 其中一个产品 UML 建模工具 Rational Rose 非常的出名。那时,微软是当时公认的首屈一指的高科技超级独角兽。总之,Rational 跟微软做了笔交易,开发 Rational Rose 的变体——Microsoft Visual Modeler,作为 Visual Basic 5.0 / Visual Studio 97 的一部分发布。留给我们完成产品的时间表非常具有攻击性,从事这项工作的团队是最近才组建的,成员分布在美国和瑞典。完成这项工作不是一件容易的事情。让团队走到一起并作为一个整体的高层次目标可以简单表示为:

与 Visual Studio 97 一起发布

这是一个伟大的目标,因为它即让人兴奋和渴望,同时对开发团队而言也具有挑战性。并且也与 Rational 的商业目标有关联,能够最大化暴露给使用 Visual Basic 的企业开发人员,能够实现引人注目的提升销售。最后事实证明尽管与 Microsoft CD 作为一体发布不是一个正确的决定,不如将 Visual Modeler 作为软件下载发布好。然而在完成产品 [6] 方面,这是一个伟大的目标。

还有更多有关如何使用目标和度量(效用)的内容,但是我想在以后的博客中详细探讨。

知识与学习

有时人们认为为了能够自组织,从一开始团队就应该具备所有必须的知识。在现实中我们完全具备 _ 大部分必须的知识 _。剩下的可以在过程中学习。因此,每个团队必须理解:

  • A.我们知道的事情。

  • B.我们 _ 意识 _ 到目前我们不知道,但是为了成功我们必须知道的事情。

除此之外,还有一些让人讨厌的知识范畴,可以归类为:

  • C.我们 _ 没有意识 _ 到我们不知道,但是为了成功又必须知道的事情。

因此,要取得成功我们需要 B 和 C 范畴的学习方法,同时我们还需要一种方法能够意识到 C 范畴。为了实现这一目标,团队需要帮助、时间,或许资金。从本质上来讲如果不考虑太多的细节,提供适当支持的责任应该由围绕团队的组织制度负责。比如:

  • 干系人 / 商业人士的参与可以根据需要在业务领域培训团队,为此他们正在创建解决方案。

  • 技术监督从而确保团队知道标准、设计模式以及团队将接触的任何现有解决方案的设计意图。这种监督不给人命令式的印象或者这将会拖延团队工作的方式完成非常重要。与建立正式批准相比,负责监督的人应该实践自己去看,比如出席 Sprint 评审、旁听设计研讨会等等。这样你可以联系上下文培训团队,久而久之它会变得越来越自给自足。

  • 时间、资金和各级管理层的道义支持从而确保团队有时间学习必须的知识。包括整个组织专用的学习日和用于培训的个人预算。

有学习自然有反馈,接下来我们讨论反馈。

沟通与反馈

自组织团队将不断适应他们所构建的和打算构建的,以及如何去实现。为了做到这一点,团队必须得到工作的反馈。其反馈应该是:

  • 我们是否构建了正确的事情,即我们解决的问题是否是真的需要解决的问题,或者我们是否误解了真实需求?我们可以把这看成是从我们所构建系统的干系人 / 用户那得到的反馈。

  • 我们是否采用了最佳的工作方式,即是否有能够变得更好的改变?我们可以把这看成是流程反馈。

  • 我们是否正确地构建事情,即我们构建的解决方案是否有正确的质量属性,故障等级是否是可容忍的?我们可以把这看成是技术反馈。

反馈是敏捷方法的心脏,这并非是巧合。敏捷团队通常定期向干系人 / 商业人士验证 / 评审,从而获得所构建解决方案的反馈;他们举行回顾会议以评估工作方式,使用技术实践比如自动化测试和持续集成来获得持续的技术反馈提要。

单个团队内的沟通本身就是一个挑战,但是在这个模型中我们将在随后的人们层讨论这一问题。然而,在多团队情境中,你可以充分持续观察团队之间的沟通。有意义的沟通的发生通常需要具备 _ 沟通机制 _ 和 _ 共享的本体 _ [7] 。如果你有多个协作团队并且拥有共同的历史,那么很大程度上沟通将自然而然的发生。另外一方面如果你有许多团队但没有共同的历史,团队可能需要支持,以建立沟通机制和共享的本体。如果你的团队分布在和 / 或属于不同的组织,这会进一步放大这个问题,比如你与外包合作伙伴合作。

实际上,这意味着你需要建立会议时间表,并需要确保有足够的空间和技术运行会议,比如分布式会议。同时你还需要建立一种文化,使人们不会犹豫寻找其他团队的帮助或者为共同利益进行讨论。为了做到这一点,必须建立存在哪些团队,他们从事什么,和如何联系他们的目录。

如果您的组织正从传统的层级组织转变,那么它将要求人们学习新的行为。当你拥有自组织团队时,协调和请求将在点到点之间处理,而不是贯穿项目上下或者各级管理层。根据我的经验,你需要明确告诉团队成员帮助他人是他们的职责。在一个大型组织内,这意味着有时你会求助一些你不认识的人,并与其沟通。对于团队的某些成员而言,这会让他们一开始感觉不舒服,但是根据我的经验,一旦你打破密封层,人们都会领会直接沟通的优势。你有时看到的反模式是 Scrum master/ 敏捷教练代表团队处理了所有的外部沟通。在我看来,这是向传统项目管理角色后退的不幸的一步。

共享本体应该以某种方式记录在案。例如,一种可能性是在领域模型 [8] 中捕捉商业领域中最重要的概念。但是这很容易造成过犹不及,因为如果某个模型太大或者太详细,很快其就会变成废词和 / 或者难以理解,因此请保持精益。高等级的架构描述和指导原则可以在技术领域起到类似的作用。这些描述的目的是提高对所谈论的有趣事情的关注,而不是详细地指定事情。

工作方式与决策制定

任何智力活动都需要做决策,比如软件开发。有时做决策很简单,有时却很复杂。有时决策会影响局部性质,有时却会影响全局性质。在职责分工明确的层级模型中(至少在理论上)很容易理解谁做哪种类型的决策和在哪做决策。但是当涉及自组织团队时,谁做决策就不是那么明显了。

此外,作为团队有效地工作你需要对工作完成度有一定的共识,即工作方式。自组织团队对定义这种工作方式有一定程度的自由,但是在较大型组织中,还需要跨多个团队达成一致的共识,或者甚至是跨整个组织作为一个整体。本质上来讲,达成共识的工作方式应该有助于个人和团队之间的协作,并能够确保组织内在正确层面做出高品质和及时的决策。

即便如此,仍然需要制定不同类型的决策。关注软件开发的决策主要分布在三个不同的领域:

  • 业务领域

  • 技术领域

  • 工作方式领域

对于每个领域,提出不同类型的决策在哪个层面制定的分类非常有用。目标应该分为在局部做小经济和小型组织影响的决策,和以协调一致的方式做大型组织影响或者较大经济后果的决定,同时还应该避免很长的交付周期和决策僵局。

在敏捷组织内多个团队之间不同层面做决策的例子可能是:

  • 个人

  • 团队

  • 项目(多个团队致力于同一解决方案)

  • 组织

考虑这两个维度,我们可以排列一个矩阵,帮助理解应该在哪里做决策,如下:

业务 技术 工作方式 个人 团队 项目 组织

不同的组织矩阵内容是不一样的,但是它应该能够回答如下问题:

  • 谁决定可接受的工作时间和在家工作的政策是什么?

  • 谁决定某种技术用不用?

  • 每个层面可以独立决定的预算?

  • 哪些设备可以提供给团队和个人?

  • 哪些工具可用?

  • 完成的定义是什么?

  • 解决方案能够解决的范围和不能解决的范围?

  • 发布计划是什么?

  • 我们如何测试?

  • 我们怎么做代码 / 设计评审?

一旦对某一类决策的制定层面达成共识,无论决策来自哪一层面,确保你在制定决策时是敏捷的特别重要,否则它会令事情变慢,阻碍进度。这在个人和团队层面则不是太大的问题,因为决策可以按需制定。但在项目和组织层面,通常需要正式的决策讨论会,且是计划性的会议。在项目层面,这种讨论会将有团队和项目管理代表出席。在组织层面,将由各级管理部门制定决策,但是应该视情况咨询项目和团队的意见。最后是紧凑但频繁的会议,而不是冗长、低频率会议,从而确保事情顺畅发展。项目层面的决策主体更应该每日召开会议,而组织层面的决策主体的频率可以稍微低点。

决策的制定是一门非常值得单独讨论的主题。在偏离本文主题太远之前我希望能够及早收回话题。

高标准与期望

自组织并不意味着没有效能需求。类似清晰且具有挑战的目标,建立卓越的文化,或者追求卓越的文化同样非常重要。那么你如何在团队内实现呢?几年前我参加了一个讲座,是由瑞典的一个主导足球俱乐部教练 [9] 举办的(他们刚刚赢得那年联赛冠军)。讲座谈到了如何在一个相当多样化的群体里创建追求卓越的共享的渴望。其中一些引用让我久久不能释怀 [10]

  • “做简单的事情,并每天做”,即以高品质

  • “好的总是充满乐趣,但充满乐趣的不一定是好的”

就我的理解而言,这些是团队内的座右铭,为了实现:

  • 建立纪律和关注细节

  • 建立不懈地专注每件事的品质和成果

我认为这种心态的影响完全可以应用到软件开发团队中,因为他们同样面向细节和品质,比如在如下方面:

  • 代码品质

  • 适当的自动化,比如测试和构建

  • 为自己设立具有挑战性但可实现的目标

  • 交付承诺

  • 他们是如何不断努力变得更好

在这方面我同样认为足球团队的教练可以在软件开发团队中扮演类似的角色。即激励并挑战团队追求卓越,或者为团队建立合适的座右铭。

现在我们更详细地看看本模型中自组织的人们层。

尽管我们有技术,尽管有不同的技术可以用于获取需求、估算、或者管理团队工作等等,但是在团队内仍然需要人的协作使事情发生。当如此考虑时,把团队看成一个整体,把所有团队成员从团队分离看成个体非常重要。为了从团队中得到优秀结果,你必须确保同时拥有积极的个体和伟大的团队动力。

积极的个体

我心酸地体会到至少在相当大的程度上,积极性是个人责任。几年前我因为严格的经济原因而不是对角色成功的渴望,很长时间紧紧抓着一个职位。长话短说,你个人认为的缺乏动力在别人看来就是糟糕的心态。这绝不会让别人觉得你是价值贡献者或者适合为未来投资的对象。对此我的意见是你不能指望你的老板或者职场的其他人激励你。毕竟,你才需要对自己的未来负责。再明显不过了,是吧。组织能做的是创建一个个体能够自我激励的环境。

下图显示了内在动力的三个必要成分。

这一激励模型来自 Dan Pink 的心理研究正文 [11] ,基于他的畅销书 Drive [12] 和 TED 演讲 [13] ,它们都是同一题材。上图中的自主(Autonomy)、能力(Competence)、和关联(Relatedness)就是 Dan Pink 所谓的自主、精通(Mastery)和目的(Purpose)。

你绝对不该做的就是创建愚蠢的繁文缛节流程,这会打击个体的积极性。组织应该意识到使人丧失积极性远比让人获得积极性更加容易的重要性。那么,你能做些什么从而助力积极性?正如本节开头所述,我信奉的是内在动机基本上是个人责任。即个人必须将自己置于能够自我激励的位置。组织需要做的是了解并支持这一机制,并创建一种能够助力内在动机的文化。我们将在下一章节详细探讨这一问题。

团体发展

在团体发展和团队动力方面有很多书籍和研究。有些文章比其它文章在心理研究方面更加有理有据。Susan Wheelan [14] 提出了一个有理有据且新颖的模型,如下图所示。

当你将上文描述的内在动力模型覆盖在这个模型上时,你可以发现一个重点,团队发展的早期阶段就是找出共同基础和工作协议,从而让所有成员有可能通过以下方式实现内在激励:

  • 自主——意味着有足够的水平能够影响你的工作方式和工作内容。Dan Pink 将自主看成是选择团队、任务、时间和技术的自由,即与谁合作、干什么、何时做和如何做。敏捷充分内置了这一属性,在敏捷中团队被允许自行决策这些事情,只要他们的决策不会消极影响他人。然而,自主并不意味着完全独立或者你可以不考虑其他人的需求任意妄为。敏捷与传统实践相比能够提高自主的案例包括:团队成员自愿参加任务而不是被分配,团队成员可以跟喜欢的其它团队的成员配对,与干系人的直接沟通,团队决定自己开发实践,等等。

  • 能力 / 精通——这意味着你感觉能够胜任,并且做的很好。这需要对你的工作有一个合适的挑战度,需要考虑你的个人知识和学习的意愿。但是这是不够的,因为最重要的因素觉得能够胜任是积极的反馈,即积极的反馈加速激励而消极的反馈会减速激励。因此确保你建立的机制能够给团队或者个人更多显著的积极而非消极的反馈。除了常规管理和干系人反馈外,研究如何刺激同伴为荣誉 [15] 反馈或者类似的机制。

  • 关联 / 目的——正如在基础之下讨论的这意味着对组织 / 团队目标的强烈支持(buy-in),尤其是涉及到 _ 为什么 _ 和期望的 _ 最终状态 _ 时。同时这也意味着你觉得与合作的同事相关联,你们有着共同需要达成目标的愿望。如果为什么和最终状态是明确的,而良好的沟通和有能力的人还是不能获得支持,那么他们可能是在错误的地方。

虽然敏捷教练可以促进,并对其中一些事情能够产生影响,但是最终对组织功能中的团队和个人运行良好负责的还是组织的各级管理部门。我的建议是简单地跟团队谈这些事情,或许可以作为回顾扩展的一部分。不需要那么复杂,但是通过展示给他们和小组讨论在团队内提高对这些机制的认识,在我看来有助于事情的发展。我不会直接跟新成立的团队谈这些,因为如果他们有至少一个月的合作经验,你将能够从讨论中获得更多有价值的内容。这里描述的简单的团队发展和个人激励模型可以用于指导。

成果

模型的最后一层是你在有足够合适的前两层的基础上希望得到的成果。我认为成功的自组织有三个主要成果

  • 价值(value)

  • 平衡(balance)

  • 结果(results)

价值

这里所描述的模型并不意味着任何理想的敏捷价值可以在不考虑它们的情况下自动出现。相反它表明如果在模型中你没有合适的基础层和人们层,你就不要指望它们的出现。

敏捷价值通常包括上文列出的,即:

  • 承诺

  • 勇气

  • 问责制

  • 诚实

  • 透明

  • 信任

  • 公开

  • 真实

  • 尊重

  • 沟通

  • 反馈

  • 简洁

让团队意识到这些价值和为什么重要是敏捷教练的职责。除非你非常确信你在做什么,否则我会非常小心地参与旨在促进信任、诚实、真实性等发展的明确干预或者小组练习。格外小心的理由是你这么做时总是会有风险对个人造成不可逆转的伤害。我认为这个精力更应该用在确保模型中下面两层在合适的位置,从而确保团队可以成功交付高品质的价值。没有什么能够比胜利更能建立团队精神。

当然,各级管理部门在文化的发展和组织内的价值观中同样发挥着重要的作用。如果行政决策者被视为不诚实那么可能一切都是虚假的,即为了促进价值的成长,你需要高层领导以身作则。

平衡

平衡是指自组织真正的含义:团队有权且有能力不断做出权衡。软件开发团队中包含的权衡如下图所示:

你也许会冒出团队为了展示自我需要的更多的权衡。这也是我从 Rashina Hoda [16] 的博士论文中学到的。

结果

归根结底都是有关达成目标与最大化效用的结果。正如本文一开始建议的,自组织是一个强大的管理策略,一个健康的自组织仅仅比严格的指导团队拥有更好的交付成果的机会。

复杂适应系统注记

有人建议你可以认为自组织团队是复杂理论中的复杂适应系统。我必须承认起初我对此也很好奇。但是一段时间后我发现这是个死胡同,并不能帮助你理解团队工作方式。敏捷团队其交互和自适应都是复杂的这是个事实。但是,如果我们研究一下复杂适应系统的定义,它应该有下述属性:

  • 交互和关系的复杂、动态网络

  • 自适应的行为变化是经验的结果

  • 主要原则是:

  • 自组织

  • 涌现(emergence)

如果我们仅仅看这些词语并把它们映射到敏捷团队中,你脑中很容易出现这样的想法:

i. 我们想要自组织团队

ii. 一群人放任不管,展示应急行为

iii. 因此我们可以认为自组织团队就是复杂适应系统

在我看来,这非常具有误导性,因为复杂理论中的复杂适应系统同样意味着:

  • 复杂适应系统中的个体 agent 遵循一组简单的规则,系统作为一个整体是复杂的,而不是个体 agent。

  • 复杂适应系统中有大量的个体 agent,系统中 agent 的简单交互可以自组织,并以复杂(不容易预测)的方式展示应急行为。

这与敏捷团队完全不同,在敏捷团队中我们只有相当少的 agent(人),而每个个体 agent 之间的交互和行为非常复杂,记住我们面对的是人,而不是蜜蜂。

总之,复杂适应系统不能作为自组织敏捷团队的有效模型,即使可以它也不能帮助我们理解如何在职场支持和培养自组织。

结论

有经验的敏捷领袖和教练应该熟悉本文中讨论的大多数内容。此外,本文并没有包含太多可以直接用于促进自组织的具体促进技术和练习。我希望你能够将此模型作为一个工具,研究自己的组织,看看在合适的位置是否存在必须的部分,从而实现健康的自组织。当然这只是一个理论,但是我希望你会发现这是一个好的,至少是有用的理论 [17]

这里有张图,是我有关自组织的大统一理论:

尽管该模型表明在关注更高层的项目之前你应该关注底部项目,但是那里没有严格的顺序。在实际应用中,你会发现你需要并行和迭代关注这些项目。这就是为什么箭头是双向的。

关于作者

Svante Lidman在创业公司和大型国际企业比如微软、爱立信和 Rational Software 拥有超过 25 年的软件开发和软件开发团队的管理 / 指导经验。2008 年以来,Svante 一直从事顾问工作,主要帮助软件开发组织转向精益 / 敏捷。2010-2012 年间,他曾在 Scandinavia 参与其中一个最大的精益 / 敏捷转型的启动和推进工作。

我希望能够获得你对本文的反馈。请在下面发表评论或者在 twitter( @svante_lidman )上或者 LinkedIn 上联系我。


[1]For some different definitions, see for example: Self-organizing, Self-directing, Self-managing, and Authority by Allan Kelly and Johanna Rothman:Managing Agile Teams - Interview with Johanna Rothman by Shane Hastie

[2]This is actually similar as to what you find in works about intelligent agents in the field of artificial intelligence.

[3]See: Cost of Delay

[4] Understanding Value

[5] Urgency Profiles

[6] Microsoft Announces Widespread Availability of Visual Modeler

[7]Essentially a shared understanding of the fundamental things that we talk about and what they mean.See also Ontology (information science)

[8] Domain Model by Martin Fowler

[9] Mikael Stahre then coaching AIK, and yes it is soccer we are talking about here

[10]Free translation from Swedish as I remember it

Self-Determination Theory

[12] Drive:The Surprising Truth About What Motivates Us by Daniel H. Pink

[13] The puzzle of motivation by Daniel H. Pink

[14] Creating Effective Teams:A Guide for Members and Leaders Fifth Edition Edition by Susan A. Wheelan

[15] Bring Kudo Cards Back to Your Office!

[16] Self-organizing Agile Teams:A Grounded Theory

[17]“There is nothing so practical as a good theory” - Kurt Lewin

查看英文原文: Foundations of Self-Organization

2016 年 3 月 03 日 17:163904
用户头像

发布了 92 篇内容, 共 15.8 次阅读, 收获喜欢 4 次。

关注

评论

发布
暂无评论
  • 出售权威的 Scrum Master

    Maris Prabhakaran在 Agile Tour Thailand上发表了题为“出售权威的 Scrum Master”演讲。其中他调查了 Scrum Master常犯的错误,并提出了使这一角色起到有效作用的一些想法和工具。

  • 通过面试,你能了解这个团队多少?

    面试是双向的,公司在考查你,你也在考查公司。更多地了解公司与职位信息,你可以在入职前,更好地评估这个职位是否适合自己。

    2019 年 4 月 19 日

  • 人力资源需要敏捷变革

    人力资源对待员工的思维方式已经过时了,需要大刀阔斧的改革。Dov Sal考察了敏捷组织中人力资源的作用,并鼓励人力资源从业者接受人力资源敏捷发展宣言。Bersin by Deloitte在一篇类似的文章中谈及一种人力资源的敏捷模型,涉及对人力资源部门的任务与关注点的彻底变革。

  • 敏捷时代下你该如何做绩效管理?

    敏捷时代更关注绩效,想要打造高绩效团队,OKR + CFR 的管理方式,可以助你一臂之力。

    2019 年 8 月 23 日

  • 特别放送(一)| 成为 DevOps 工程师的必备技能(上)

    DevOps工程师要关注工具平台开发、流程实践落地和技术预研试点3个层面,还应该具备沟通能力、同理心和学习能力等软实力。

    2019 年 10 月 17 日

  • 高效产品人的三个习惯

    Kent McDonald是产品领域的敏捷实践者,也是“Stand Back and Deliver:Accelerating Business Agility”一书的合著者。他最近为Scrum Alliance发起了一个网络研讨会,谈论了一些用于改进和成功实施远程产品开发的技巧。

  • 敏捷度量的 Why、What、Who、When

    敏捷不仅有度量,度量还是敏捷项目非常重要的一部分,但敏捷度量和传统的度量存在很大的区别。敏捷度量不是以评估和考核为目的的,它是为了帮助团队拉通目标和行动、指导指定工作计划和任务、协助团队持续改进而发生的。

  • 《Create Your Successful Agile Project》书评与作者访谈

    《Create Your Successful Agile Project》一书帮助人们理解敏捷方法,并选择适合他们的方法。通常,团队采用一种框架,但并不了解该框架适用的上下文环境。本书展示了如何利用团队独一无二的产品、上下文和人员为项目定义一种可持续的敏捷方法。

  • 敏捷团队:平衡领导力与自我管理

    如果自我管理团队能够正确理解并处理“领导与自我管理”的困境, 他们就可以做到良性流动,而且取得成功。太多的集中控制会破坏敏捷,禁止创新,抵制变更。太多的自我管理会导致混乱而毁掉一个团队。 成功的敏捷团队尽可能的沿着自我管理的方向运转,同时也不会陷入混乱。

  • 敏捷实施中的常见错误

    一些评论员写下了敏捷实施中一些常见错误和反模式。从过分依赖工具到依恋某个特定过程,这些因素通常被认为影响了敏捷实施的效率。下面的列表为实施敏捷需注意事项的想法和建议提供了养料。

  • 精益思维的演化:从精益思维转变到畅流思维

    畅流系统让组织重新思考、理解复杂性,拥抱团队合作和基于自治团队的领导力结构。

  • 基于干净语言和好奇心的敏捷指导

    干净语言问题是指不带有偏见的问题。它们可以用来发现组织中的基本规则、表达价值和应对机制,并且在组织中获得清晰度和多元化的想法。它们简单易学,但实施起来有点困难。干净问题要求更大的透明度,要求人们比平常更多地分享想法。

  • 有什么方法可以有效提升团队凝聚力吗?

    一个非常有凝聚力的团队,对于良好的协作有着直接和关键的影响。本文就和大家探讨如何提升团队的凝聚力,让团队可以默契协作。

    2018 年 9 月 29 日

  • Snapper 应用合弄制

    在过去的两年中,桑迪·马莫利一直在支持新西兰的交通票务公司Snapper 采用他们的合弄制(Holacracy)。在最近的一次敏捷的会议上,她解释了什么是合弄制,描述了他们的应用之旅,应用中发现的好处,并为其他考虑合弄制的人提了些建议。

  • 四种方式主导你的第一个敏捷项目

    Manish深入探究敏捷和Scrum过程的细节。贯穿这篇文章的最重要的内容是新手如何主导敏捷项目。这篇文章讨论了站会的重要性、找出团队的优势和劣势、最大限度地利用你的团队以及如何避免微管理。

  • 如何提升员工的个人能力?

    本文探讨了提升员工个人能力的常见做法和一些原则。

    2018 年 9 月 22 日

  • 在 Scrum 中添加目标与合弄制

    热衷于使用Scrum的组织仍然缺少一个关键因素:他们的组织治理从上个世纪开始就已经陷入了困境。合弄制完全可以代替传统的管理层次结构,并可以显著提高动力和生产力。

  • 对自组织的实验

    自组织(Self-Organisation)团队是更有成效、更具投入和更令人快乐的。自组织并非会令所有人感到满意。人们总是习惯于按要求做事,并且主要依靠自己去完成事情。我们需要基于意图的领导方式、全民政治和合弄制等现代的领导方法实现自组织团队。

  • 大咖对话 | 管理者是首席铲屎官?

    激发员工主人翁精神的一个关键就是让团队成员有参与感,而要让他们获得参与感就需要赋予他们建议权甚至是决定权。

    2018 年 7 月 6 日

  • 全球敏捷探索之旅

    David Spinks和Glaudia Califano正在环游世界,以探索民族文化对敏捷采用的影响。

发现更多内容

架构师训练营 1 期 -- 第十一周总结

曾彪彪

极客大学架构师训练营

《迅雷链精品课》第十课:共识算法理论基础

迅雷链

区块链

看区块链如何打通信息壁垒,盘活万亿级”积分”市场

CECBC区块链专委会

区块链 信息

一周信创舆情观察(11.23~11.29)

统小信uos

Java程序员做外包,10个月收入40万

Crud的程序员

Java 学习 程序员 外包

智能与影像的强耦合:华为Mate 40系列的视觉探索

脑极体

程序员的故事

Philips

敏捷开发 快速开发 原创小说 企业开发 企业应用

值得学习!阿里P8架构师“墙裂”推荐:Java程序员必读的架构书籍

Java成神之路

Java 程序员 架构 面试 编程语言

ETV全球熵APP系统开发|ETV全球熵软件开发

开發I852946OIIO

系统开发 现成系统

HTTP协议概述

落日楼台H

https HTTP 协议 HTTP2.0 HTTP3.0

【得物技术】搜索引擎技术简介

得物技术

搜索引擎 技术 算法 排序 搜索

腾讯T4Java大牛连续半个月每天熬夜到凌晨三四点,竟然就只是为了写一份MyBatis源码学习笔记

Java成神之路

Java 程序员 架构 面试 编程语言

价值、产业、数据加密,区块链如何助力互联网升级?

CECBC区块链专委会

区块链 互联网

区块链产业下的“非遗”突围战:商业化和手艺人发掘

CECBC区块链专委会

区块链 非遗

我对业务方提出需求的态度

boshi

随笔杂谈 需求落地

单机服务器模型,reactor的5种实现方式,只有这样才算了解了

linux亦有归途

c++ Linux reactor 后端开发

训练营第七周总结

大脸猫

极客大学架构师训练营

架构师训练营第二周框架设计课后练习

Geek_xq

年轻人想详细了解做了十年Linux跟做了十年Windows的程序员差距有多大吗?听我慢慢道来!

ShenDu_Linux

Linux 程序员 windows

「更高更快更稳」,看阿里巴巴如何修炼容器服务「内外功」

阿里巴巴云原生

容器 运维 云原生 双十一 CloudNative

我在阿里巴巴做 Serverless 云研发平台

阿里巴巴云原生

Serverless 容器 开发者 云原生 CloudNative

打造Django私有化缓存组件django-api-cache

pygodnet

django django-api-cache django缓存 私有化缓存 接口缓存

蘑菇街Java大牛纯手写熬夜肝出的《Spring MVC源码笔记》赶紧收藏

Java成神之路

Java 程序员 架构 面试 编程语言

赶紧收藏!Java大牛熬夜一周肝出的《Spring AOP/IOC源码笔记》

Java成神之路

Java 程序员 架构 面试 编程语言

LeetCode题解:52. N皇后 II,回溯+哈希表,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

技巧收藏|10个JavaScript常用数组操作方法

华为云开发者社区

Java 数组 开发

讲述我在阿里六面的经历,幸好我掌握了这份“Java并发编程+面试题库”成功拿到20K的offer

比伯

Java 编程 架构 面试 计算机

mysql的这些坑你踩过吗?快来看看怎么优化mysql?

比伯

Java 编程 架构 面试 计算机

线程池的优点及其原理,代码实现线程池。简单、明了。

Linux服务器开发

网络编程 线程池 后端开发 Linux服务器 web服务器

每周学点TARS——服务自定义命令

TARS基金会

c++ DevOps 后端 TARS

京东T7架构师手写的10万字Spring Boot详细学习笔记+源码免费下载

Java成神之路

Java 程序员 架构 面试 编程语言

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

自组织的基础-InfoQ