1.3 合作
合作（collaboration）有两个方面的含义。一个方面是团队成员尽可能高效协同工作的能力。这方面可能是在所有项目中——实际上在所有团队工作中——都具有的，这方面总能得到提升。实际操作中，这意味着从团队环境中移除所有阻止有效沟通的障碍，并且有团队成员可以高效地引导（facilitate）团队合作。
合作的另一个微妙但同样重要的方面是，实际上完成项目核心工作的团队成员也是做计划并报告进度的人。这是从项目的传统视角看到的转变，传统项目中这些类型的任务由项目负责人完成。团队成员是最熟悉这项工作的人，同时他们处在最合适的位置，能够确定要完成什么工作。因此，团队成员应该自愿完成不同的工作项，而不是由别人进行指派。
无论采用任何方法论（methodology）和具体方法，这一指导原则都应该被用在每个项目中。然而这一原则可能是团队最难采用的。某些项目经理具有根深蒂固的指挥控制习惯。团队也倾向于由别人告诉他们做什么，即便他们并不喜欢被指派工作。改变这一现状的过程往往会违背人类的本性。
如同其他所有事物一样，合作最好适度。为了确保团队意识到关键信息，有些合作是必要的。但是，当确保每个人都熟知所有信息时，会降低团队以稳定速度交付价值的能力，导致合作变得混乱，而这可能就是一个团队无法很好地一起工作的一种原因。合作也并不意味着共识（consensus）。有些时候冲突也是适当的、合理的。但是，过多的冲突会带来过多的伤害，特别是当它没有通过在正确的渠道发生时更是如此。
我曾和一个无论如何都无法一起好好合作的团队共事过。我无法准确地找到原因，但我认为有几个因素在发挥作用。
该团队的一些成员来自有毒的环境。他们已经转到采用敏捷方法的团队，以摆脱他们以前的环境。但是，我不确信他们是否采纳了敏捷的原则和价值观。这些成员常以“我们正在敏捷”作为各种不正常行为的借口。例如，他们缺乏专注，据称是因为要和队友频繁互动。
该团队确定了几个“头儿”，这些人往往是在分析、开发、测试技能以及敏捷方法的知识方面具有更丰富的经验。但是这些人逐渐滑向了指挥控制的行为方式，有时甚至吩咐团队成员就某一个问题停止互相交谈。一个成员说他觉得自己从原来有一个老板变成了有4个老板。
该团队无法公开讨论他们的想法，他们只在极罕见的情况下才尝试进行讨论，他们将讨论包裹在大量过程中，致使讨论没有任何收获。
该团队最终解散，部分原因是没有足够的工作，但主要原因是它功能运转失灵。有趣的是，该团队总能兑现承诺。有些人可能会说应该再给他们一次机会，因为他们能够交付。
对比一下我所在的另一个团队。这个团队不是在敏捷环境中工作，但决定尝试敏捷方法。像前一个案例一样，开发人员没有完全认同敏捷方法。与前一个团队的想法相呼应，不认同的开发人员最初时说他觉得有2～3个老板而不是一个。我们能够解决这些问题，讨论彼此的关注点，并利用这些分歧来找出改善的机会。我们建立了一些工作协定，并且在这个团队中从未出现指挥控制的方式。这主要是因为我们互相尊重，并且能够无需借助流程就能讨论这些问题。最基本的是，合作意味着在一个项目中工作的人形成一个真正的团队（team），而不是工作组（work group）。这使得他们能够解决任何困难，而不会因为生闷气或急着去找身边最近的决策者。
也许是更重要的是，合作也意味着，团队成员承诺完成共同的目标，而且他们并不害怕走出自己的专业领域去帮助团队中的其他人。团队中的每个人都有自己的专业领域，如开发、测试或者分析，他们花了大量时间在这些领域，但是在有需要时，他们能够跳入其他领域并完成一些工作来帮助团队实现总体目标。对于一个业务分析师，他可以推进整个团队进行合作，利用团队成员和利益相关者的深刻洞察辅助分析，并在团队中其他人遇到困难时帮助完成测试和文档工作。这也意味着，分析师不再把所有分析工作对其他人都藏起来，也不再只做分析工作。他们作为团队成员将所有时间投入到团队中，而不再限定为业务分析师角色。这种合作的结果是，角色变得模糊，但团队处在更能频繁交付产品增量的位置，从而获得更有意义的反馈。