是转变的时候了：传统组织中的敏捷团队

InfoQ在Agile2006会议上曾经采访过Joseph Little和Michael Spayd。当时他们正与一组敏捷教练和专家教练一起在一个大型企业中推行敏捷软件开发。我们和他们探讨了当时敏捷社区中正热烈讨论的“组织范围的变更”和“组织训练”：为什么现在这个这么热门？他们凭着他们帮助传统组织中的团队步入敏捷开发的经验作出了回答。

他们发现培训开发团队只是意识到其中的商业利益的开始：通过引导这些组织与他们的开发团队互相配合，可以获得更大程度的改进。反过来说，如果推行敏捷开发的过程中没有整个组织的配合，会阻碍这些团队在向敏捷转变过程中的成长和活力。

我不认为你可以掌控变化。你可能做得更好，你也可能做得更糟糕。
——Joe Little

Michael Spayd将这种需求归因于敏捷方法论受众的变化。敏捷的“早期采纳者”们通常将这种方法带入已经存在某种程度的敏捷的组织中。现在，大型的、进展缓慢的组织也希望从中受益，但却发现这种转变并不那么顺利。因此，他们寻求教练的帮助，来引导他们完成这种文化的转变，这对一些教练来说是一个新角色。

在访谈中，他们谈及了“敏捷组织”、如何着眼于实践，并主动迎接各种阻力，从中吸取教训以达到平稳的过渡。

以下是这次访谈的一些摘录，《Little和Spayd谈敏捷与组织范围的转变》

你们曾为一些组织引进敏捷：你们看到了些什么？这些转变是如何发生的？

Spayd：首先是在团队层面发生转变，团队克服他们的转变曲线。对于有些团队来说这并非容易的事，特别是在他们不具备所有条件时，比如：产品的买主或者客户不那么好说话，或者你缺少一个教练。对团队层面来说，这些都是困难。

Little：对，这是一般的自下而上的发展过程；你从团队开始着手，然后他们的影响逐渐扩散到整个组织。另外一种常见的发展过程是自上而下，最好的情况就是这两种过程同时发生。通常最困难的转变发生在中层；一段时间之后忠诚的管理人员就会开始想“啊，我的工作开始变得不一样了。这对我意味着什么？”



那么，在你们开始着手的时候，就知道将会遇到对敏捷的阻力，但你们并不清楚将会遇到什么样的阻力。那么你们从哪里开始着手呢？你们采用那种方法论？

Joe：谈到面对组织层面的转变时，我会选择Scrum，因为它让各种障碍清晰可见……对大家都可见，不光是你自己，而且让它你更容易地安排事情的优先次序，这一点比我了解的其他方法要强。

Michael：我也同意应该从Scrum开始进行实践，因为它是最容易实现的，也最容易得到一些早期的成功。不过，我认为不应仅限于此，我想……如果不建立起自己成熟的工程实践，这早晚会不适用的。但一开始时Scrum还是足够用的。



你们有看到过强制式的敏捷实践的例子吗？有效吗？

Little：这样通常都会导致不好的工作方式，特别是除了给出一些指引外没有给出任何其它帮助时。

Spayd：我曾遇到过于强制的做法，也见过一些不那么明显的强制的做法。不管是哪种，结果都不怎么好，因为这不符合敏捷的本意。不过话说回来，我们都非常热心；我们期望真心信仰敏捷，因为敏捷很酷，并且……人们其实难以放弃他们强制式的想法：“你必须采用敏捷，因为这样做好多了”。 （他大笑道）我们当然知道我们做的是对的。

查看英文原文： Time for Change: Agile Teams in Traditional Organisations