原创连载译文 Fixing Your Scrum (转载请联系捷伴行)
Chapter 2 第2章
Why Scrum Goes Bad 为什么Scrum会变质
Scrum itself doesn’t go bad—it’s the ways that organizations implement it that can be problematic. We frequently see people changing the Scrum framework to fit their organization rather than the organization itself changing. Changing an organization can be slow and frustrating, but the whole point of adopting Scrum is to switch to a more efficient and empowering way of creating products, so change is a must.
We’ve experienced, and sometimes even promoted, many of the Scrum anti-patterns that we’ll describe in this book. The root cause of these anti-patterns is typically policies that have been in place since long before the company adopted Scrum. Such longstanding policies can sometimes make what Scrum brings to light seem counterintuitive. For example, the idea of having a dedicated product owner who is fully empowered to make all decisions about a product can feel really foreign to many organizations, but having someone in that role is crucial to the success of any Scrum team.
Scrum本身不会让事情变糟,而是组织实施它的方式可能会出现问题。我们常常看到人们更改Scrum框架以适应组织,而不是改变组织自身。改变组织可能会很慢并让人感到沮丧,但是采用Scrum的唯一目的是要转变到一种更高效,授权的方式来创造产品,所以改变是必然的。
我们将在本书中介绍很多Scrum反模式,这些我们经历过,有时甚至还被推广。这些反模式的根本原因通常是在公司采用Scrum很久之前就存在的政策。这种长期的政策有时会使Scrum暴露出来的东西似乎违反直觉。例如,设置一个完全有权对产品做出所有决定的专门产品负责人的想法对于许多组织来说确实很陌生,然而让某个人担任这一角色对于任何Scrum团队的成功至关重要。
As Scrum masters, part of our service is to the organization, and that means one aspect of our role is making sure the organization is fully embracing the Scrum way of doing things—which may require changes. Organizational change can come in many forms, such as:
-
Working with HR to redefine job roles.
-
Working with Finance to understand how budgeting processes impact the way teams work.
-
Helping Management adopt agile leadership principles.
-
Removing the divide between IT and business partners.
In order to know which change(s) your organization needs to make, you first need to understand the underlying causes of bad Scrum.
作为Scrum master,我们的一部分职责是为组织提供服务,这意味着我们角色的一方面是确保组织完全采用Scrum的做事方式,这可能需要一些改变。 组织的改变可以有多种形式,例如:
-
与人力资源部门一起重新定义工作角色。
-
与财务部门合作,了解预算流程如何影响团队的工作方式。
-
帮助管理层采用敏捷领导力原则。
-
消除IT和业务伙伴之间的鸿沟。
为了知道组织需要进行哪些改变,首先需要明白这些不良的Scrum背后的根本原因。
Turning Scrum into Best Practices 把Scrum当做最佳实践
Ryan once worked with an organization whose Project Management Office created a 500-page Scrum manual that detailed the processes and “best” practices that all their Scrum teams had to follow. Not surprisingly, these “Scrum” best practices looked a lot like the old waterfall processes the company used prior to adopting Scrum. We aren’t against teams creating their own practices within the Scrum framework—that’s actually a good sign of a team that’s working well together. But we’ve seen many organizations take the idea of “best” practices too far (like with the 500-page manual). A best practice is a practice you adopt and use everywhere all the time as the best way to do your work. But the type of work that Scrum teams do is typically too complex for any particular practice to always be the best approach, so there’s no such thing as a best practice in Scrum.
Ryan曾经与一个组织合作,该组织的项目管理办公室创建了500页的Scrum手册,其中详细说明了所有 Scrum团队必须遵循的流程和“最佳”实践。 毫不奇怪,这些“ Scrum”最佳实践看起来很像公司在采用Scrum之前使用的旧瀑布式流程。 我们不反对团队在Scrum框架下创建自己的实践,这实际上是团队合作良好的一个好兆头。 然而我们已经看到许多组织对“最佳”实践的想法做得过头了(就像这500页的手册)。 最佳实践是被采用的,作为完成工作的最佳方法,在任何时候,任何场合可以使用。 不过对于任何特定的实践来说,Scrum团队所做的工作类型通常都太复杂了,以至于不能总是成为最佳方法,所以Scrum中没有所谓的最佳实践。
At the other end of the “Scrum as a best practice” spectrum is the tendency to modify the Scrum framework itself. This can be very tempting, but don’t do it. When a team only uses part of the framework, they lose most of the benefits of working with Scrum. What do these framework changes look like? Here are some examples:
Treating every Scrum event as optional. We have enough meetings as it is!
Skipping the sprint review when there isn’t any work to show. I mean, it’s just a demo, isn’t it?
Holding the daily scrum biweekly. Just because it’s called the daily scrum doesn’t mean we have to do it every day, right?
Canceling the sprint retrospective in favor of getting more work done. Because who has time to improve?
Ignoring the Scrum event time boxes. I mean, who doesn’t love a 45-minute daily scrum? (Spoiler: no one loves it.)
把“Scrum作为最佳实践”的另一个极端,是倾向于修改Scrum框架本身。 这可能很诱人,但别这么干。 如果团队只用框架的一部分,他们会失去使用完整Scrum的大部分好处。对框架的改变是什么样的? 这里有些例子:
-
将每个Scrum活动视为可选的。 我们有足够的会议!
-
当没有要展示的工作时,跳过Sprint评审。 我的意思是,这只是一个演示,不是吗?
-
每两周举行一次每日Scrum。 仅仅因为它被称为“每日Scrum”并不意味着我们每天都必须这样做,对吗?
-
取消Sprint回顾,就可以完成更多工作。 因为谁有时间改善?
-
忽略Scrum活动的时间盒子。 我的意思是,谁不喜欢每天45分钟的讨论?
Scrum is a collaborative framework that teams work within to help them deliver working software frequently. Your team needs to deliver an increment every sprint so they can determine whether they’ve met stakeholder expectations, whether customers actually want the product that they’ve delivered, whether they’ve created value at a reasonable cost and timeframe, and whether they’re using the appropriate technologies. This feedback loop that the Scrum framework implements (between the Scrum team, stakeholders, and customers) is an example of risk reduction.
Scrum是团队的协作框架,帮助他们经常交付可用的软件。 团队需要在每个Sprint上交付增量,这样他们可以确定是否满足利益相关者的期望,客户是否真正想要他们交付的产品,他们是否已经在合理的成本和时间范围内创造了价值,以及他们是否在使用适当的技术。 Scrum框架实现的反馈循环(在Scrum团队,利益相关者和客户之间)是降低风险的一个示例。
Along the way, you and your teams will discover that it’s really hard to deliver product increments. Changes will be required at all levels of your organization, from the Scrum team all the way up and down the org chart. Changing the Scrum framework, ignoring the rules of Scrum, and simply swapping out old jargon for new- and-improved terms won’t get you there.
在此过程中,你和团队将发现很难交付增量产品。改变需要在组织的各个层级进行,从Scrum团队向上或向下的组织结构图。 改变Scrum框架,忽略Scrum规则,仅将旧术语换成新的和改进的条款并不能有所帮助。
When an organization is reluctant to fully adopt Scrum without making lots of customizations, we’ve found it useful to make a clear distinction between the Scrum framework and other complementary practices that the Scrum team is using. Often in our consulting engagements, we spend most of our time tearing out complementary practices in order to simplify things and firmly establish the core Scrum elements. Scrum teams should strive to get the basic elements of the framework solidly in place before they add any additional practices that may be needed.
当一个组织不愿全盘采用没有经过大量定制的Scrum时,我们发现在Scrum框架和Scrum团队正在使用的其他补充实践之间进行清晰区分是很有用的。 通常,在我们的咨询服务中,花费大部分时间来完善补充做法,以简化工作并牢固地建立核心Scrum要素。 在添加任何可能需要的其他实践之前,Scrum团队应该努力稳固地掌握框架的基本要素。
Where does your team stand in terms of having the basic Scrum framework elements in place? To find out, try this simple exercise alone or with your team:
-
Write each element of the Scrum framework on a separate sticky note: Product Owner, Scrum Master, Development Team, Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Product Backlog, Sprint Backlog, and Increment.
-
Next, grab a different color sticky note and write down each complementary practice your team uses (one per sticky note), such as story points, poker planning, or sprint burndown charts.
-
Now that you have a list of the Scrum elements and a list of the complementary practices, on every sticky note, write a score from 1 (we aren’t doing this at all) to 5 (we’ve mastered this).
-
Finally, reflect on how you can get every Scrum element sticky to a 5. Are you spending too much time and effort on complementary practices? Are any complementary practices prohibiting a Scrum element from getting to a 5?
就掌握基本的Scrum框架元素而言,团队处于哪个程度?要找出答案,请尝试单独或与团队一起进行以下简单练习:
-
在单独的便笺上写出Scrum框架的每个要素:产品负责人,Scrum Master,开发团队,Sprint,Sprint计划,每日Scrum,Sprint评审,Sprint回顾,产品待办事项列表,Sprint待办事项列表和增量。
-
接下来,拿一个不同颜色的便笺,写下团队使用的每种补充实践(每个便笺一个),例如故事点,扑克规划或Sprint燃尽图。
-
现在,在每个便笺上已经有了Scrum要素的列表和补充实践的列表,写下一个分数(从1(根本没有做)到5(已经掌握了))。
-
最后,思考一下如何使每个Scrum要素达到5分。在补充实践上花费了太多时间和精力吗?是否有任何补充实践阻碍了Scrum要素达到5分?
Best practices work well for work that is repeatable or can be standardized, but Scrum is designed for solving complex problems. All too often, we cling to best practices as a way to feel like we know exactly what’s going to happen. Wouldn’t it be great if we could follow a 100-step process (filled with best practices) and always get the results that we expect? However, complex work doesn’t play out that way. We need, instead, to be transparent both within the Scrum team and to the wider organization, to have frequent opportunities to inspect and evaluate our work, and to have the ability to make adaptations as needed. Scrum is a simple framework with 11 elements that provide a means of using empiricism (transparency, inspection, and adaptation) to your advantage. Adding complementary practices to Scrum may enhance the framework, but you must be doing Scrum well before you adopt any additional practices.
最佳实践对于可重复或可以标准化的工作效果很好,然而Scrum是为了解决复杂的问题。 很多时候,我们坚持采用最佳实践,觉得好像自己完全知道会发生什么。 如果我们可以遵循一个100步骤的过程(含有最佳实践)并始终获得我们期望的结果,那不是很好吗? 但是,复杂的工作并不会以这种方式呈现。 相反,我们需要在Scrum团队内部和整个组织内部保持透明,并有频繁的机会检查和评估我们的工作,并具有根据需要进行调整的能力。 Scrum是一个简单的框架,包含11个元素,可提供使用经验主义(透明度,检查和调整)的方法。 在Scrum中添加补充实践可能会增强框架,但是在采用任何其他实践之前,Scrum必须做得已经很好。
Lacking Goals 缺乏目标
Want to know the best way to demotivate a development team? Keep them from seeing how their work impacts your customers. Likewise, it’s demotivating for a Scrum team when they don’t know how their product relates to the overall mission of the company. This misalignment of value and purpose can make it difficult for a Scrum team to have their own clear goals that reflect larger organizational goals. This cascades all the way down to sprint goals—and without sprint goals, the development team lacks urgency and inspiration. In that situation, the developers become backlog lumberjacks: they chop through features and stories without really understanding why they’re doing that work.
想知道挫伤开发团队积极性的最佳方法么?就是别让他们看到他们的工作如何影响客户。 同样,当Scrum团队不知道他们的产品与公司的整体使命有何关系时,也激励不了他们。 价值和目的错位会使Scrum团队很难拥自己的清晰目标,并思考更大的组织目标。 一直到Sprint目标都是这样,没有Sprint目标,开发团队缺乏紧迫性和灵感。 在这种情况下,开发人员就像是待办事项的伐木工人:他们在不真正了解为什么要进行一项工作的情况下砍伐(完成)功能和故事。
What does this look like in practice?
- Carrying work over across multiple sprints becomes the norm.
- We’ll finish that PBI in the next sprint, right?
- Your team actually starts using a sprint goal (hurray!) but it’s basically just “finish the sprint backlog” (boo!).
- Quality suffers. We don’t know why we’re doing the work or who it helps, so who cares how good it is?
实践中会成什么样呢?
-
跨多个Sprint进行一项工作成为常态。
-
我们将在“下一个”Sprint中完成该PBI,对吗?
-
团队实际上开始使用Sprint目标,但基本上只是“完成Sprint待办事项”。
-
质量受损。 我们不知道为什么要从事这项工作或对谁有帮助,那么谁在乎它有多好呢?
Stakeholders get upset. A lack of a product vision equals a vacuum of product leadership that ultimately gets filled by the development team. And there is no way for developers to magically know what customers want, especially if they do not know how their work is impacting customers.
利益相关者会不高兴。 缺乏产品愿景等于产品领导力的真空,这最终会由开发团队来填补。开发人员不能像变魔术一样地知道客户想要什么,特别是当他们不知道他们的工作如何影响客户的时候。
Scrum teams work best when they are aligned with the organization’s goals and customers’ needs. Leadership sets the high-level goals for a company, product visions serve these goals and the customers’ needs, and sprint goals keep Scrum teams aligned with the customers. When this alignment is in place, the Scrum team has purpose. Purpose is a powerful tool that can bring a team together and keep them inspired and motivated to deliver great products.
当Scrum团队符合组织的目标和客户需求时,他们的工作效率最高。 领导层为公司设定了高层目标,产品愿景为这些目标和客户需求服务,Sprint目标使Scrum团队与客户保持一致。 当达成一致时,Scrum团队便有了目标。 目标是一个强大的工具,可以使团队团结起来,并激发他们的灵感和动力,以交付出色的产品。
Does your Scrum team lack goals? This happens when executives fail to advertise company goals clearly or fail to communicate changes to company goals. Goals, from the organizational level cascading all the way down to a Scrum team’s sprint goal, should be measurable and customer-focused. Work with your product owner to clearly understand why your team is doing the work they’re doing. Trace it all the way up to the company’s goals and mission.
Scrum团队是否缺乏目标? 当管理层无法清晰地宣传公司目标或无法传达对公司目标的改变时,就会发生这种情况。 从组织级别一直到Scrum团队的Sprint目标,目标应该是可衡量的并且以客户为中心。 与产品负责人一起清楚地理解团队为什么从事他们正在做的工作。追溯这些工作到公司的具体目标和使命。
During your next retrospective, see if your team can make the connection between their sprint goal and a corporate goal. Ask the product owner and development team to reflect on the sprint goal from a recently completed sprint and have them connect this goal to the product vision, and ultimately to a corporate goal. Making these connections explicit can help the Scrum team stay focused on the impact of their work.
在下一次回顾中,观察团队是否可以在Sprint目标和公司目标之间建立联系。 要求产品负责人和开发团队对最近完成的Sprint中的Sprint目标进行反思,并使他们将该目标与产品愿景,最终与公司目标联系起来。 明确这些联系可以帮助Scrum团队专注于他们的工作所产生的影响。
Taylorism Creeping Back in
We’ve worked in countless organizations where people hold strong beliefs about product development that aren’t compatible with the proper use of the Scrum framework. These beliefs are often held both by people in various levels of management and among the people doing the work. These beliefs are often overlooked and rarely discussed because the trust needed to talk about them is lacking. To make matters more difficult, many of these beliefs are deeply rooted in corporate culture and are difficult to work through.
我们在无数的组织中工作,人们对产品开发有一些很强信条,这些信条与Scrum框架的正确使用并不匹配。 这些信条通常属于处于不同管理级别的人员和从事具体工作的人员。 经常被忽略,很少讨论,因为缺乏谈论这些信条所需的信任。 让情况变得更加困难的是,许多信条根植于企业文化中,因而难以开展工作。
What kinds of beliefs, you ask? Ones that people in management and large organizations have held for a long time. In fact, many of these beliefs are over 100 years old. We won’t bore you with the details, but in 1911, Frederick Winslow Taylor published a study called The Scientific Principles of Management, which resulted in a methodology known as Taylorism. Taylorism is rooted in the idea that we can break tasks into very small, simple steps that can be analyzed, taught, and repeated. The goal was to separate workers’ brains from their hands. In other words, remove the need to think about the work and simply give people small steps to follow to complete a task. With small steps in place, the result is predictability and compliance, not innovation.
想问是什么信条? 管理人员和大型组织中的人已经存在了很长时间。 实际上,其中许多信条已有100多年的历史了。 我们不会提供细节,但在1911年,弗雷德里克·温斯洛·泰勒(Frederick Winslow Taylor)发表了一项名为“管理科学原理”的研究,从而得出了一种称为泰勒主义的方法。 泰勒主义植根于这样的观念:我们可以将任务分解为非常小的,简单的步骤,可以对其进行分析,教导和重复。 目的是使工人的大脑与手分开。 换句话说,无需“思考”工作,而只需给人们一些小步骤即可完成任务。 只要采取一些小步骤,结果就是可预测并且合规的,而不是创新。
Taylorism was designed to solve manufacturing problems that were prevalent in the industrial era (which emphasized repeatable work), and it solved those problems quite well. But when people apply the principles of Taylorism to complex work in the innovation and development space, the results are typically disastrous.
泰勒主义旨在解决工业时代普遍存在的制造问题(强调可重复的工作),并且很好地解决了这些问题。 但是,当人们将泰勒主义的原理应用于创新和研发领域的复杂工作时,结果通常是灾难性的。
Taylorism differs dramatically from the Scrum way of doing things. A quick summary of the main beliefs in Scrum and Taylorism is shown in the table.
泰勒主义与Scrum的做事方式有“戏剧性”上的不同。 下表显示了对Scrum和泰勒主义的主要信条的简要概述。
Table 1. Taylorism vs. Scrum
Taylorism泰勒主意 | Scrum Scrum |
---|---|
Workers only know how to do the specific tasks they’ve been assigned; they don’t have or need a big-picture view of what their organization is trying to accomplish and are not encouraged to broaden their skill sets. 工人只知道如何完成分配给他们的特定任务; 他们对自己的组织正在努力实现的目标没有或不需要全面了解,因此不鼓励他们扩大技能范围。 | Work is performed by cross-functional teams that have all the skills they need to get the job done. These teams are supported by leadership, and high levels of trust are leveraged between leadership and Scrum teams to make decisions quickly and deliver increments of working software to customers frequently. Workers are encouraged to broaden their skill sets and collaborate. 拥有完成工作所需的所有技能的跨职能团队执行工作。 团队在领导层的支持下,领导层和Scrum团队之间建立了高度信任,可以快速做出决策,并经常向客户交付可工作软件。 鼓励工人扩大技能范围并进行协作。 |
Managers plan work without input from the people who perform the work. 经理在没有工作人员帮助的情况下计划工作。 | Planning happens at varying levels across all the Scrum roles. Management is invited in to inspect the team’s work during sprint reviews and to collaborate with the product owner, so that the team can take management and stakeholder opinions into consideration as they figure out what to do during the next sprint.规划在不同层级进行并涉及所有Scrum角色。 邀请管理层在Sprint评审期间检查团队的工作,并与产品负责人进行协作,以便团队可以在下一次Sprint期间确定做什么之前可以考虑管理层和利益相关者的意见。 |
Management tries to make the work as predictable as possible by precisely managing resource utilization with exact estimates. 管理层尝试通过精确地估计资源利用率来使工作尽可能可预测。 | Scrum teams manage their time and focus as they plan their work. The development team is responsible for resource utilization. They use estimates to trigger conversations within the Scrum team and with management— not to make the work as predictable as possible.Scrum团队在计划工作时会管理时间和精力。 开发团队负责团队资源利用。 他们使用估算来触发Scrum团队内部以及与管理层的沟通,而不是使工作尽可能地可预测。 |
**Taylorism ** | Scrum |
---|---|
Management optimizes workers’ performance using metrics and measurements.管理层使用指标和度量来优化员工的绩效。 | Scrum teams use metrics to optimize outcomes that benefit the customer.Scrum团队使用指标来优化产出使客户受益。 |
Management uses money and rewards as primary motivators for performance. Workers are motivated to achieve rewards and avoid punishment (extrinsic motivation). 管理层将金钱和报酬作为绩效的主要动力。 激励员工获得报酬和避免惩罚(外部动机)。 | Scrum team members have a goal they are trying to achieve, the autonomy to achieve it, and a comprehensive set of skills to accomplish their goal. They also have opportunities to learn from each other. Team members are motivated to perform their work because they enjoy what they do and feel a sense of personal accomplishment (intrinsic motivation).Scrum团队成员具有他们要实现的目标,实现目标的自主权以及完成目标的综合技能。 他们也有互相学习的机会。 团队成员执行工作的动机是因为他们喜欢自己所做的事情,并且有个人成就感(内在动力)。 |
As you can see, Taylorism and Scrum are two very different mindsets. They are basically opposite ways of approaching work. So it’s no surprise that adopting Scrum in an organization that is accustomed to the Taylorism way of doing things can be an uphill battle. Keep this info in mind when you’re trying to bring people in your organization around to the Scrum way of doing things. It’ll help you understand where people’s opposition to Scrum practices comes from.
可见,泰勒主义和Scrum是两种非常不同的理念。 他们的工作方式基本上是相反的。 因此,在习惯于泰勒主义做事方式的组织中采用Scrum可能是一场艰苦的战斗,这并不奇怪。 当尝试将组织中的人员带向Scrum的方法时,请记住下面的信息。 可以帮助我们理解人们反对Scrum实践的根源。
When Taylorism and Scrum are at odds in your organization, you’ll likely see some of these signs:
-
A mechanical implementation of the Scrum framework without truly embracing its principles and values.
-
Scrum team members view Scrum as just new way to get micromanaged.
-
No meaningful signs of collaboration between Scrum team members.
-
The Scrum team is producing poor-quality increments.
-
People are still being measured by how busy they are, not by the outcomes of their work.
-
The Scrum team is unable to deliver increments of product every sprint.
-
Reverting back to past practices—but calling them by new names.
当组织中的泰勒主义和Scrum出现矛盾时,我们可能会看到以下一些现象:
- Scrum框架的机械实现,而没有真正拥抱其原则和价值。
- Scrum团队成员把Scrum看做进行微观管理的一个新方法。
- Scrum团队成员之间没有有意义的合作。
- Scrum团队产生质量较差的增量。
- 仍在根据人们忙碌程度来衡量工作,而不是根据他们的工作成果来衡量。
- Scrum团队无法在每次Sprint中交付增量产品。
- 恢复到过去的做法,却用新的名称称呼它们。
Keep an eye out for these signs that the old ways of working are still at play in your organization. This book describes a lot of anti- patterns that occur when Taylorism and Scrum compete with each other. Adopting Scrum will require conversations about your company’s culture that will give you an opportunity to create change. Take advantage of those opportunities so you can positively impact your organization and move it more toward the Scrum model, which represents the world we work in today far better than Taylorism does.
请留意,有这些迹象表明组织中仍在使用旧的工作方式。 本书描述了泰勒主义和Scrum相互竞争时发生的许多反模式。 采用Scrum需要就公司的文化进行对话,这样会有机会进行变革。 利用这些机会,可以对组织产生积极影响,将其进一步推向Scrum模型,Scrum模型远比泰勒主义更好地展现我们今天工作的世界。
Trust is Missing 信任缺失
Trust is a weird thing: it’s contextual, exists on a spectrum, and is very transactional. Think about your relationships. You trust some people with certain aspects of your life, but not everything. For instance, Todd and Ryan trust each other to work on this book and to co-teach a good class together—but they don’t trust each other to do each other’s laundry. And trust changes over time. It can take a long time to build up trust with someone, and then one misstep can wipe it out.
信任是一件很奇怪的事情:它是与环境相关的,存在于一定范围内,并且非常具有事务性。 想想你的人际关系。 你会在生活中的某些方面相信某些人,但不是所有事。 例如,托德(Todd)和瑞安(Ryan)互相信任,共同努力写这本书,并一起上好课,但他们不信任对方能洗好自己的洗衣服。 信任随着时间而改变。 与某人建立信任可能需要很长时间,而一旦失误就会完全失去它。
What does trust look like on a Scrum team?
- The product owner trusts the development team to create a done product increment by the end of every sprint.
- The development team trusts the product owner to provide them with a clear product vision.
- Development team members trust one another to do their best and support one another.
- Management trusts the Scrum team and removes any impediments to delivery.
Scrum团队的信任是怎么样的?
- 产品负责人信任开发团队能在每个Sprint结束时创建完成的产品增量。
- 开发团队信任产品负责人能为他们提供清晰的产品愿景。
- 开发团队成员彼此信任,以尽最大努力并互相支持。
- 管理层信任Scrum团队并消除任何阻碍交付的因素。
Without trust, you can’t have transparency. If the members of a Scrum team don’t trust each other or an organization doesn’t trust a Scrum team, then it’s impossible to make the team’s work and progress evident to stakeholders. Instead, people play defense: they blame one another and fail to work as a truly collaborative team.
没有信任,就不会透明。 如果Scrum团队的成员彼此不信任,或者组织不信任Scrum团队,那么就不可能使利益相关者看到团队的工作和进步。 取而代之的是,人们在防守:他们互相指责,却不能作为一个真正的协作团队在工作。
Want to quickly make your organization trust your Scrum team? Deliver. We’ve found no better way to build trust than consistently delivering increments of products every sprint.
想让组织快速信任Scrum团队么? 交付。 事实证明,没有比在每个Sprint持续交付增量产品更好的建立信任的方法了。
But how do you increase the likelihood that a Scrum team can work together smoothly and deliver successfully? Well, other than solving the many anti-patterns in this book, here are a few quick ideas you can try:
-
Shorten your sprint length. Instead of a four-week sprint, try a one-week sprint. The development team will have fewer product backlog items to focus on, the product owner will have stakeholders in the sprint review even more frequently, and collaboration will happen in shorter intervals.
-
Focus sprint planning on setting a sprint goal that has a true impact on the customer. This helps inspire the team and gives them something real to work toward.
-
Use the daily scrum as an opportunity for the development team to inspect their progress toward their sprint goal. Celebrate progress and promote opportunities for Scrum team members to support and help one another. This helps increase trust within the team.
-
Create opportunities for the Scrum team to collaborate with real customers. The sprint review event is perfect for this. Who better to talk about the impact of the team’s work than the people who are actually affected by it?
-
Introduce or reemphasize the importance of the Scrum values. If you and your team keep the Scrum values in mind, then empiricism will shine.
然而,如何增加Scrum团队顺利合作并成功交付的可能性?好吧,除了解决本书中的许多反模式之外,还可以尝试以下简单的思路:
-
缩短Sprint长度。请尝试1周的Spint,而不是四周。开发团队专注在更少的产品待办事项上,产品负责人使利益相关者更加频繁参与Sprint评审,协作在更短的时间间隔进行。
-
将Sprint规划的重点放在设定对客户有真正影响的Sprint目标上。这有助于激励团队,并为他们提供切实的工作方向。
-
利用每日Scrum开发团队可以检查其实现Sprint目标的进度。庆祝进展,并为Scrum团队成员创造相互支持和帮助的机会。有助于增加团队内部的信任。
-
为Scrum团队创造与实际客户合作的机会。Sprint评审活动非常适合此操作。有谁会比受着实际影响的人来谈论团队工作产生的影响更好?
-
介绍或重新强调Scrum价值的重要性。如果我们和团队牢记Scrum价值观,那么经验主义将大放异彩。
If you see that trust is lacking—either between your Scrum team and the rest of the organization or within the team itself—do everything in your power to find a way to build trust. We offer tips and exercises for doing so throughout the rest of this book. For Scrum to work to its full potential, trust is mandatory.
如果发现Scrum团队与组织的其余部分之间或团队本身内部缺乏信任,请尽一切力量找到建立信任的方法。 在本书的其余部分,我们提供有关练习和提示。 为了充分发挥Scrum的潜力,信任是必不可少的。
Coach’s Corner 教练园地
Most big organizational structures are based on Taylorism; something that has been in place for so long takes time to unwind. Scrum has been around for over 20 years, but a lot of large organizations have been around for far longer than that. Even newer organizations likely have employees who are used to the older, pre-Scrum ways of doing things.
大多数大型组织结构都基于泰勒主义; 已经存在了很长时间的东西需要花费时间来解除。 Scrum已经存在了20多年,但是许多大型组织的存在时间远不止于此。 即使是较新的组织,也有员工可能习惯于旧的,在Scrum之前的工作方式。
But change is possible. As a Scrum master, you can unwind old policies and create new ones every day! A great way to figure out where to start (or continue) creating change in your organization is to perform this exercise, which is inspired by the liberating structure, 15% Solutions:
- Gather all the Scrum masters in your organization.
- Discuss with them how far your organization has come in terms of transitioning to the Scrum way of doing things and how much is still left to do. If it’s helpful, reference the Taylorism vs. Scrum info we presented in this chapter.
- Have everyone in the group spend five minutes on their own answering the following question: What’s within my control that I can change to get our organization 15% closer to where it needs to be?
- Put people in groups of two to four, and have each person take three minutes to share their 15% Solution with their group. Make sure that the people who aren’t sharing are actively listening and not giving feedback or advice.
- Finally, have each team member spend five minutes sharing their idea(s) again—but this time encourage the other team members to ask questions and give feedback to each 15% Solution.
然而,改变是可能的。作为Scrum Master,可以每天解除旧政策并创建新政策!找出组织中从哪里开始(或继续)进行改变的一个好办法就是做以下练习,灵感来自于自由式结构沟通,15%解决方案:
- 集合组织中的所有Scrum Master。
- 与他们讨论组织在过渡到Scrum的做事方式方面取得了多大的进步,还有多少工作要做。如果有帮助,请参考我们在本章中介绍的泰勒主义与Scrum信息。
- 小组中的每个人是否都花了五分钟来回答以下问题:在我能力范围内可以做哪些改变,使我们的组织更接近需要的位置15%?
- 将人员分成2到4个小组,让每个人花3分钟时间与小组共享15%的解决方案。确保没在分享的人积极倾听,并且不提供反馈或建议。
- 最后,让每个团队成员花五分钟再次分享他们的想法,但是这次鼓励其他团队成员提出问题,并为每个15%的解决方案提供反馈。
Thinking in terms of 15% Solutions can keep people from feeling overwhelmed. Concentrating on what’s within our control and finding a way to get 15% closer to where we want to be can be a powerful exercise.
用15%的解决方案思考可以使人们避免不知所措。 专注于我们控制范围内的事情,找到一种方法使距离我们想要的目标更近15%可能是一项有力的练习。
In this chapter, we covered some of the old practices that Scrum often competes against in organizations. Next, we’ll delve into how we can break bad Scrum by concentrating on the values and principles that influence behaviors both within a Scrum team and in the wider organization.
在本章中,我们介绍了Scrum在组织中经常与之竞争的一些旧做法。 接下来,我们将研究如何通过影响Scrum团队内部和整个组织行为的价值观和原则,解决不良的Scrum。
-- * End of Chapter 2 Why Scrum Goes Bad *--