本章是有关Scrum Master作为教练角色的。我们常常认为ScrumMaster是团队的教练,帮助团队发挥出最好水平去达到冲刺目标。本章中,我将᧿述教练是什么,并分享Scrum Master作为教练时可采用的三个视角。
什么是教练?
有很多很好的定义可以用来᧿述教练。我最终的定义是:“教练是释放一个人的潜能,使他们发挥出最高水平。帮助人们学习而不是直接教他们。”
其它好的定义如下:
• “教练的终极目标是帮助客户更好地了解他们自己,使他们能充分发挥自己的潜能8。”
• “高效的教练技术是指引而不是强制规定。”
• “促进他人效能、学习和发展的艺术 。”
• “教练缩小了想去做和实际做的差距 。”
什么是高效教练?
通过波西亚·唐顿的网站(自私编程),我偶然发现了 “高效能教练的7个习惯12”。Scrum Master可以采用这些习惯,检查她或他是否正在用一种成功机率最高的方式去进行辅导。她᧿述的习惯有:
• 以身作则。这也就是说,教练会践行他们信奉的价值观和原则,并将他们了解的工具和技巧应用在自己身上及工作中。
• 以终为始。教练会从目标出发,找出从A到B最有效快捷的方式
• 制定可持续发展的步伐。周围的人都失去理智的时候,教练会保持冷静。
• 动脑思考,用心感受。教练会兼顾思维和情感。解决问题的时候,教练会同时运用逻辑思维以及同理心。
• 吸引,而非强推。教练等待且时刻准备好有人前来求助。教练创造并ᨀ供学习机会而不是把他们的想法、建议和观点强加给其他人。
• 少说多听。教练不急于对他们听到的内容做评判,耐心听的同时等其他人说完。
• 像溪流一样涓涓教诲。教练是有耐心的、务实的且活在当下。
Scrum Master作为教练
描述Scrum Master作为教练,可以从三个不同的角度出发:个人,团队和组织。指导个人专注于思维模式与行为,指导团队做持续改进,指导组织真正地与Scrum团队协作。考虑丽莎·阿德金斯说过的:”
教练技术不是关于给出建议,而是关于帮助人们想出他们自己的解决方案。如果你问对了问题,他们常常会给予有效的帮助。”指导个人
• 解释所需要的思维模式与行为模式,帮助个人发现新的视角和可能性。
• 影响团队成员个人用好Scrum。
• 帮助每个人在他或她的敏捷旅程中迈出下一步。
指导团队
• 倡导一种持续改进的思维模式,创造一种学习文化。
• 帮助团队解决难题,解决冲突。
• 指导团队发展进步 “直到成员知道如何最好地从彼此身上学习。
• 改变那些妨碍做好Scrum的态度,思维模式与行为。
• 指导团队成员互相给予开放而诚实的反馈。
指导组织
• 帮助组织交付高质量高价值的产品,取得惊人的成果。
• 指导整个组织做产品管理,专注于持续地为产品增加商业价值。
• 支持并鼓励组织与Scrum团队互相协作并合作 。
小结
通过一些研究,我已经为Scrum Master作为教练创建了一个简洁的描述。除了分享了关于“教练”最常见的定义,本章还包括了可用来描述Scrum Master作为教练的三个角度。指导个人专注于思维模式与行为,指导团队做持续改进,指导组织真正地与Scrum团队协作。
与敏捷项目管理相关的推荐资源
The “daily scrum” is one of the important event for monitoring the heartbeat of your scrum project and is a “good habit” for your team. The purpose of the daily scrum is to increase the team’s communication and focus by answering 3 questions. (“每日Scrum”是监控Scrum项目心跳的重要事件之一,也是团队的“好习惯”。每日Scrum的目的是通过回答3个问题来加强团队的沟通和关注。)
Sprint is a Timeboxed iteration with a continuous development cycle. In Sprint, the planned workload must be completed by the team and ready for review. Scrum projects are subdivided into small and consistent time intervals, called sprint. They can be as short as a few days, usually no more than three to four weeks. (Sprint是一个持续开发周期的时间盒迭代。在Sprint中,计划的工作量必须由团队完成并准备好进行审核。Scrum项目被细分为小而一致的时间间隔,称为sprint。它们可以短至几天,通常不超过3-4周。)
This article show you how scrum framework is operated in a general sense. It can be illustrated in 8 typical steps. It leads you through the entire Scrum lifecycle from the start to the end. (本文向您展示了一般意义上如何操作Scrum框架。它可以用8个典型步骤来说明。它将引导您从开始到结束整个Scrum生命周期。
The Stand-up meeting is the opportunity for the entire team to succinctly sync up on everyone’s individual progress against the iterated Sprint, feature, or story point estimations. (站立会议是整个团队根据迭代的sprint、feature或story point估计简洁地同步每个人的个人进度的机会。)
A Scrum product backlog is simply a list of things to do for the project. The Product Owner creates, maintains, and regularly re-order a list of feature to be implemented for a product for adapting to emerging requirements, customer feedback, and market changes. (Scrum产品积压只是项目要做的事情列表。产品负责人创建,维护并定期要为产品实施的功能列表重新排序,以适应新出现的需求,客户反馈和市场变化。)
Scrum processes are distinguished from other agile processes by specific concepts and practices, and are classified into roles, rituals (also called events or meetings) and artifacts. (Scrum流程通过特定的概念和实践与其他敏捷流程区别开来,并分为角色、仪式(也称为事件或会议)和工件。)
The Scrum framework includes the Scrum team and its associated roles, events, artifacts, and rules, and each component within the scope of a specific purpose is essential to the success and use of Scrum. (在Scrum的框架包括Scrum团队及其相关的角色,事件,工件,和规则,与作为特定目的范围内的每个组成部分,是对Scrum的成功和使用是必不可少的。)
Story points are metrics used in agile project management and development to estimate the difficulty of implementing a given user story, which may be related to the complexity, risk and effort involved. (故事点是敏捷项目管理和开发中使用的度量标准,用于估计实现给定用户故事的难度,困难可能与所涉及的复杂性,风险和努力有关。)
Agile teams use collective estimation methods to estimate their workload. Group estimation usually uses planning poker as a tool, and teams perform group estimation by playing estimation games. Planning poker is considered to be the most effective and interesting technique for workload estimation in agility. (敏捷团队的估计工作量使用了集体估算方法。集体估算通常使用规划扑克作为工具,团队通过玩估计游戏进行集体估算。规划扑克被认为是在敏捷中进行工作负荷估算的最有效和最有趣的技术。)
Scrum: 谁创建 Product Backlog项目或用户故事?
The Product Owner (PO) “owns” the product backlog on behalf of the stakeholders, and is primarily responsible for creating it. He or she may instruct the development team and/or the Scrum Master to help him/her in defining the backlog items and in estimating them. (产品所有者(PO)代表利益相关者“拥有”产品积压工作,并主要负责创建积压工作。他或她可以指示开发团队和/或Scrum主控来帮助他/她定义积压项和估计它们。)