敏捷团队领导的职责可大致分为四类:人员、产品、流程和项目。根据领导者的具体背景、能力和职业道路,通常不会将每项职责都发挥到极致。另外,随着敏捷团队的演变会按需对四类职责进行适当的调整。
人员—--让团队成员尽量专心工作
- 避免分心。尽量减少打扰和外部职责,以便团队就能以最佳的状态进行工作。最常见的分心理由就是预料之外的任务。采纳与团队合作以最大限度地降低干扰的频率或干扰带来的影响另一种分心则是疏忽,在组织中普遍存在。团队成员对项目的亲和感和忠诚度投入到别的地方时,他们对项目的敬业度和对团队的参与度就会下降。当职能部门的管理者继续以个人为单位分派任务和掌控进度就会发生这种情况。当明知项目的价值较低但仍继续推进时也会发生这种情况——项目人员会将精力投入到重要性或关注度更高的工作上。采纳的措施是当决定是要继续为团队而努力,还是叫停项目。
- 培养协作意识。防止各自为政,不愿请求别人帮助。领导应该四处走走,听一听,看一看,当注意到这种情况,让团队成员向彼此求助,促成人们相互沟通,鼓励相互合作。
- 让团队担起责任。敏捷规划从本质上就是互惠交换的关系。团队以承诺交付特定的成果为条件获得对设计、任务详细安排和工作预算(根据速度进行粗略估算)的控制权。如果团队未能履行承诺,则应进行问责,并帮助团队学会在下一次的工作中改进。
- 支持个人成长和发展。看清行动和决策所带来的影响。及时给予反馈,同时尊重反馈对象,以支持团队和个人的成长。与团队的管理者协作,帮助团队成员出色地承担团队义务并实现个人和职业发展。鼓励团队成员彼此进行反馈——教会团队怎么做到这一点。
- 获取资源。团队需要各种资源,例如新硬件、外部专业力量的协助、培训,甚至是用于某些会议的食物。代表团队取得这些资金和许可并进行安排。
产品—--主要在于让所有人集中精力开发正确的产品
- 确保商业价值的流动。帮助产品负责人在待开发项列表上安排已经过排序的、有价值的待开发项供团队进行开发。帮助交付团队和产品负责人寻找有效方式共同定义交付的内容,从而为项目任务提供支持。确保团队充分考虑到产能因素,确保遵从项目优先安排,并最终确保团队最大限度地提升其交付的价值。
- 保持战术执行与战略意图相符。经常检视所规划的可交付成果是否仍有价值。不断提醒团队具备全局观,因为短周期和较小的事件容易造成团队短视和感到机械式地重复。保留一份项目章程,确保团队一直相信项目章程中所描述的愿景,并控制该章程的参数。如果参数有变动,公开改变的内容,让团队成员知道。
- 让利益相关人参与。项目规模越大,在组织内涉及到的范围越广,就可能会有更多的利益相关人。邀请这些利益相关人参加迭代演示,并举行规划会议以了解他们关于产品演变的意见。将项目的变化告知利益相关人。此外,还要对他们的期望进行管理,因为团队很可能无法满足他们所有的要求。
- 外部协调。如果其他的软件团队能够为你的团队的解决方案提供一臂之力,让那些团队谈谈计划和共同担心的问题——如果不主动提起,他们是不会自发地进行这么深入的沟通的。如果项目内容不只局限于软件,你应当成为非软件内容(例如营销、封装和第三方)的接触点。应就日程表和计划进行协调,并对依赖关系进行管理。
流程职责—--帮助团队遵循流程,按需对流程进行调整,让流程顺利运转。
- 承担流程管理工作。团队拥有一定的流程,会在完成任务后和其他场合对流程进行检视和调整。许多团队未对流程给予足够的关注或根本不进行调整(或者干脆不知道如何进行调整)。协助团队成员遵循团队选择的方式,并尊重团队达成的共识。指出团队尚未注意到的问题。引导团队成员继续改进和完善其流程。
- 消除阻碍。阻碍(障碍)会妨碍团队的进度或产能,几乎每天都有。不断关注此类情况,就能够先行对这些问题进行处理。任何团队成员都可以尝试解决这些问题,但在此过程中提供帮助或至少提供引导则是领导的责任。消除一个既定的阻碍需要一些时间(尤其是在需要向团队外寻求帮助的情况下),因此记得跟进其进展。
- 管理知识、信息源和工件。建立资源库以方便调用。保留需要保持更新的工件(例如计划、风险和问题),将其余的存档。
- 追踪进度、趋势和指标。因为领导的角色不涉及对解决方案的日常构建或定义,领导能观察和分析解决方案所选取的路径。搜集与其相关的信息(尽量避免干扰团队集中精力工作),让团队能够看得到这些信息。提醒团队注意正逐渐显现的风险或趋势。你会其中某些风险或趋势加以缓冲,却又对另一些加以强化。确保仔细进行测量,因为测量结果往往会影响团队的行为。
- 提升组织的敏捷性。无论团队是否唯一的敏捷团队与否,改进组织的敏捷性能够提升团队的成果。在更大的范围内推行敏捷型团队需要有人支持和领导;作为组织内活跃的敏捷型团队实践者,敏捷团队领导的参与是这一举措成功的基础。
项目职责—--不论面对的是单一项目还是长期持续的价值交付协议,还有另一类职责:将团队的工作与组织的需求联系起来。
- 建立适合的团队,确保获得项目发起人的支持你应当建立一个可以交付成果的团队,并能够通过名字认出整个团队的人。别忘了还有项目发起人!没有项目发起人的支持,团队要想成功恐怕是凶多吉少。
- 正确地开始工作。即使有了正确的团队,有了项目发起人的支持,仅仅填写一张待开发项列表就急忙开展第一次迭代,这种做法是不负责任的。确保项目具备明确的章程,该章程由各方合作制定并经项目发起人签署——即使其中大部分内容是团队自己写的。在那之后才应当规划版本和迭代。
- 为预算和预测提供数据。不论是不是敏捷型组织,大多数组织在开展新一轮工作前需要了解工作目标。敏捷团队领导可以根据待开发项列表和其他来自产品负责人和团队的信息为他们提供相关数据。
- 识别、管理和规避全局风险。团队中的大多数人都会埋头工作,可能没注意到并非迫在眉睫的风险。而敏捷团队领导的视野更广,看待问题更客观,能够在风险实际出现前发现。确保整个团队懂得持续不断的风险管理是每个人的事——你只不过恰好是这项工作的领导而已。
- 报告所需的信息。不论团队的计划和工件有多透明,这类未经处理的数据很少能对高管的高层决策提供什么帮助。对进度信息进行解释或汇总以回答管理层的提问并形成常态。
培养与团队中各角色的关系
在传统的“命令-控制”式架构的组织模型中,项目主管会告诉团队成员组织希望他们做什么。沟通的形式多是通过团队领导向下传达。相比之下,在敏捷型架构中,敏捷团队领导还需要跟组织进行沟通,将团队的需求告诉组织。现在沟通的形式大多是向上传达。敏捷团队不再只是为组织服务,而主要是为团队服务。
敏捷团队领导与团队中各个角色之间有何关系?
与交付团队的关系:大多数团队成员按根据职能划分的层级结构进行报告,例如开发、质量保证(QA)或架构。应当引导、激发和支持团队成员对团队而非功能组的忠诚。
作为敏捷团队领导,应当引导、支持、鼓励和指导团队成员,而非只是检查团队的工作。应协助他们为了服务于共同的目标而进行自组织。团队的气氛轻松愉快;团队的人却很难管理。要根据团队成员的看法,帮助他们尽可能快速有效地开展工作。应当给予团队支持,让团队以更高明的方式工作,并且适应需求的变化,而不是只顾着榨干团队的工作能力。
与产品负责人的关系:正如向交付团队提供支持一样,还应当支持产品负责人。许多产品负责人会写出待开发项并排定其优先级——然后时间就用完了。敏捷领导可以预先将待开发项全部整理一下,为下一个规划周期进行准备。另一个可提供支持的领域就是与团队中全体成员建立并维持联系。去和利益相关人、管理者和顾问委员会沟通;维持互惠交换关系;进行对话以产出有用的工件——这一类和其他类别的支持活动通常需要耗费大量的时间。由于产品负责人需要维护功能路线图,他/她需要与比其更忙碌的人交谈,因此敏捷领导应当帮助其建立和维护这类联系。而在谈话中究竟会透露什么信息(任何与该领域相关的信息、产品要求、路线图等)往往由产品负责人自己决定。
如果产品负责人没有履行其职责,敏捷领导应该怎么做?产品负责人未能承担起责任是一个非常重大的风险,可能是整个团队成功的最大阻碍。如果产品负责人由于正当的理由遇到了麻烦,敏捷领导可以挺身而出,帮助这位不称职的产品负责人。也许现在他正焦头烂额,需要更多培训,或暂离工作岗位。但是如果产品负责人不承担其责任,不称职,或不希望承担这一角色——你就不必替他出头。将问题的根源暴露出来,以此让产品负责人承担起责任,因为这个问题在组织内的牵涉更广,仅凭你一己之力是无法解决的。
与利益相关人的关系:利益相关人不太可能与团队进行日常互动,他们往往只会直接与两个人沟通:产品负责人,与他谈要求、系统细节和优先级;以及敏捷领导,其他一切事物的联络人。他们希望敏捷团队领导倾听他们担心的问题,邀请他们参加相关会议,告诉他们最新消息。如果产品负责人很忙而利益相关人很多,与他们沟通的担子就会更多地压向你这一边。
照料好利益相关人。他们大多身居要职,如果他们觉得不受重视,你和你的团队就可能不会有好果子吃。以最大限度地提高交付成果的价值为宗旨,帮助他们管理与团队的互动。以包容、开放和体贴的方式与他们沟通——他们也会相应地投桃报李。
与项目发起人的关系:项目发起人(通常是公司或工程部的总裁或部门主管)是重要的利益相关人:他们代表着高管和公司在项目中的利益。他们以公司资金和其他资源为赌注,运行项目,收获组织回报。许多项目有一个或两个发起人。
敏捷团领队应当结识项目发起人。早在起草项目章程的时候就会与项目发起人互动。尽管敏捷团队领导和项目负责人很有可能是章程的作者,但发起人是唯一的签字人,他们可以轻易变更章程,甚至叫停整个项目。之后,他们会在必要的时候于会议上为项目辩护或为你争取更多时间和资源。
你与项目发起人之间的互动与按照传统方式运行的项目中的互动很相似。发起人会问:
——我们是否能够按预定完成目标?
——有哪些风险?
——我们能如何增加成功的机会?
——还有什么事需要告诉我的吗?
——你需要什么?
——我能帮你什么忙?
与团队成员管理者的关系:大多数实施敏捷式开发的组织都是在现有的架构上叠加敏捷式结构。如果所在组织是按职能划分的层级结构,那么,团队成员会来自多个不同的技术职能部门,例如开发、测试和数据库设计。这些团队成员会向多个管理者报告,其中一个也许正好就是你的老板。这些管理者也许与团队联系密切,或者在日常活动中不怎么参与你的团队。
敏捷团队领导和职能部门的管理者的总体目标一致的:让组织持续交付价值。你们的策略也应该一样的:充分发挥相互协作的自组织团队的力量。如果情况确实如此,与职能部门的管理者之间应该能够建立良好的关系,为敏捷团队锦上添花。如果情况不是这样,那么,可能会遭遇敌对关系、部门对抗和公司政治的洗礼,令团队成员垂头丧气。
摘自Gil Broza分别于2012年1日和2日发表在ProjectsAtWork上的两篇文章The Human Side of Agile和Agile Team Relationships。
Gil Broza是3P Vantage的所有者,著有 The Human Side of Agile 一书。