在传统的研发团队中实施Scrum,不可避免的会遇到传统职位与敏捷角色的冲突，如果没有很好的重新定位，冲突很可能会放大，反之，如果用好，这种冲突能够促进组织的发展。

传统的研发团队，通常是如下的组织结构：

在这种组织架构下实施Scrum, 如果职能经理和技术主管没有深度参与，即职能经理和技术主管，没有担任Scrum团队的任何角色。那么可能造成的困扰有：

1. 职能经理或技术主管参与Sprint Planning 会议时，团队成员可能会保持沉默，等待职能经理或技术主管分配任务，即使他们只是旁听，由于长期形成的影响力，也会无形的对Scrum团队产生影响，导致会议气氛紧张，效果不好。

2. 职能经理或技术主管参与Daily Scrum时，变成汇报会，所有的成员面向职能经理或技术主管，描述他们的工作，有时也会变成向ScrumMaster的汇报会。

3. 职能经理或技术主管参与回顾会（Retrospective）时，气氛会变得更差，不小心就会变成批斗会。大家沉默不语，面无表情。

如果职能经理和技术主管没有参与这些活动，团队成员会在有经验的Scrum Master的指导下，能够轻松高效的完成任务。但是如果职能经理和技术主管不参与Scrum，那他们的职责又是什么呢?

戈尔茨坦(Ilan Goldstein)在他的新书《Scrum Shortcuts without Cutting Corners》的第九章中提到:

(注意中文书名翻译成《Scrum 捷径：敏捷策略、工具与技巧》笔者认为不妥)

职能经理的未来

…让我们关注一下职能经理进入神圣的敏捷领域之后会有怎样的机遇？

问题来了，在组织里通常一个优秀的开发人员会被晋升成为职能经理。这个职位将赋予新的经理享受与重视的等级特权。当然，他们可能不需要花太多时间在他们喜欢的代码工作上，而是花在无聊的会议，委派的任务以及无足轻重的行政文案工作上，但是，能向老妈报告说他们已晋升管理职位难道不是一件很酷的事么？

关键在于，敏捷中没有规定需要向一个自组织团队委任一名职能经理。职能经理们就会想：那我们要变成怎样的角色呢？他们要感谢敏捷剥夺了他们的头衔么？

好吧，我可不这么认为。我的答案无非是帮助他们重新设计一个职能经理位置的涵义。首先，我通常会对他们说，也如同敏捷培训师，Stormglass首席执行官Pete Deemer(2011)所建议的，“简单来说，敏捷中的经理对团队而言不是保姆，而应该是导师或宗师，帮助大家学习，成长和工作”，目前为止没有任何在职的职能经理对此提出异议。

然后，我想谈谈多个敏捷团队的事，敏捷团队中已经有强烈的需求要帮助和确保技术标准已经被定义好，并且有人能够指导团队解决来自内部和外部的技术障碍。我们的职能经理一定会乐此不疲。

进一步，我想说团队中需要有人要能够识别技术缺口，以便能引入在技术和相关领域层面的适合团队学习和发展的课程。职能经理对此没有异议。

接着，当我们需要招募新的团队成员或者替代时，‍我们同样要求团队中有人能够胜任招聘新的研发人才的工作。职能经理对此仍然没有异议。

最后，我告诉职能经理他们可以把那些痛苦的被迫要做的委派任务扔出窗外，以便他们可以回到真正喜欢做的事情上！对职能经理这个角色重定义的典型反应是“听上去太棒了！那我们什么时候开始？”

我看到组织架构的转变从远离等级指挥一步步向“实践社区”发展，如果这个转变能够成功，那么我并不介意他们希望继续保留职能经理头衔的想法。

笔者认为，戈尔茨坦(Ilan Goldstein)提到的职能经理的角色新定义，应该在企业组织层面上，即规模化敏捷。将敏捷从Team 层面延伸到Program 层面再到Portfolio 层面,最终实现企业级规模化敏捷。他们必须有精益敏捷的领导力，他们是”life-long learners who help teams build better software systems through understanding and exhibiting the values, principles and practices of Lean, systems thinking, and Agile development. –by Dean Leffingwell, the author of 《Agile Software Requirements》.”

文章出处：《Scrum Shortcut without Cutting Corners》，IIan Goldstein 著

译者：Cartman Wu

审校：Jim Wang