The new product line of work, whether you work for a small start-up companies or in large companies, increasing for a long time when the number of teams will always reach a critical point. Early identification of this critical point can make your team avoid entering inefficient stage.
Each product is different, teamwork, too. Therefore, the split team also need to make decisions that reflect the situation of the team. The following points need to be considered when making decisions:
- How to ensure the integrity of the team are not together expertise at work?
- You should by function? (Eg: front-end and back-end team Team)
- The new team should have a separate backlog it?
- Whether the product should be a corresponding increase in the management team?
When did you start to create a second team?
Began to consider the team to split or add a new team most obvious sign is the increase in the team's budget. This may happen in the new target of a new round of investment in start-up companies or companies products. If the budget increased more your team will grow 3 times the size even more, and this time you have to split the existing team to continue the existing technical knowledge. However, when the budget increase was incremental, your decision becomes less clear, the end result is to increase the number of newcomers on the roster. If you plan to own a team of seven people to 11 people, you need to be done to split it? Agile promote small team, but also to promote individual and interactive than processes and tools. With two or more teams will be created to avoid more processes to be able to operate synchronously.
Experts how to say?
Amazon founder Bezos had two pizzas and principles used in the team meeting. That means the number of meetings or whether the team should have only two pizzas can feed lunch.
Scrum guidelines suggest there are 3-9 members of the actual implementation of sprint backlog. This means that the total number can not contain PO or Scrum Master, unless they have some of them in the implementation of sprint backlog items.
These figures look more intuitive sense, but they also have the mathematical principles behind. If everyone on the team are seen as a node and link them to other nodes. This is the relationships between teammates. Between them can be friendly, competitive, malicious or care. Whatever the relationship between the two is that everyone needs to have a certain mental capacity. With the growth in the number of teams, a number between these links do not increase linearly. Formula link between nodes, as shown in FIG Growth FIG link:
Mathematically chart clearly shows why maximized when the team is not particularly large scale was only able to achieve operational efficiency. If we follow the advice of the team using Scrum Guide 3-9 scale the number of people, the final link is 3 to 36. If the number of teams increased to 15 people, the link value will exceed 100. This size only team in the team define each person's responsibilities are very clear and very little overlap or unofficial group in order to operate efficiently. Agile principles-based work is neither Case nor desirable.
Team larger signal
Daily Scrum
Daily Scrum is gathering the entire team, elaborate sprint for the progress and difficulties encountered, sometimes called the station will be daily. Scrum Guide recommends daily station will be completed within 15 minutes, this is a time limit on the size of the team is a good litmus test. If you notice that your team start line more than 15 minutes, you can show two things:
-
It will lower the efficiency of the station. We fall into too much detail them. Or there is no clear need for team members take turns speaking order named. PO is also possible to use the station or Scrum Mater time will raise the sprint independent various updates.
-
团队规模过大。如果站会效率很高，但是你的团队开会时间仍然超过15分钟，那就很有可能是你的团队人数过多导致的。你还应该注意到团队中的一些人正在逐渐失去兴趣因为一个人可以接收的信息量是有限制的。如果太多人提供更新，那么跟踪每个人的进度并了解团队的状态就会变得很难。这使得人们只会向内看，只看到自己的进步而不是寻找机会去帮助他人。
梳理和Sprint规划
梳理和迭代规划都是与分解用户故事和预估交付时间或规模大小有关的活动。虽然有更多的人可以帮团队做出更好的决策，同样的拥有太多人也容易让团队陷入僵局。同一任务可以由不同的方法来完成，并且每一边的论点数量都会随着人员数量的增加而增加。
与站会一样，不要把低效的计划谈话与团队规模过大混淆。最终，让scrum仪式变得更高效且有效是scrum master的工作。
回顾
在回顾会议期间，团队成员可以解决任何争论或冲突并提出改善其工作流程的方法。回顾会议教会我们妥协的艺术，因为它让我们在不同团体直接寻求共同点。团队也因为它的成员愿意在他们的分歧上适当妥协而变得强大。
然而，和sprint规划一样，团队成员过多那么链接点也会很多，所有这些链接点都是潜在冲突。如果你在回顾会议时发现大家的共同点越来越少的时候你就应该开始注意。这很有可能是由于团队规模过大，团队拆分是最佳选择。
如何拆分团队？
表明上看，拆分团队是一个相对简单的任务。将团队成员分成两组，确保每组中都有相似经历的成员，明确新团队的目标。然而，在拆分团队时还有很多因素需要考虑进去以免影响团队以后的成功。
团队士气
需要时刻牢记的最重要的事情之一就是团队士气。一天结束时，团队中的成员将不得不在新的组织架构中工作。如果团队在敏捷原则方面是成熟的，那么他们应该能够自己分裂。这是最理想的结果，因为团队成员最了解他们的内部关系——谁与谁关系最好以及谁能从分离的组织中收益。
跨职能团队
Scrum推动跨职能团队“拥有创建产品增量所需的所有技能”。扩展到两个甚至更多团队时也是如此。对于很多开发者尤其是一些敏捷新手来说，自然趋势是与技术线路一起思考的。例如，团队经常想将拆分成前端和后端。这在某些罕见的情况下可能会有意义，但作为产品经理，你应该在大多数时间提出反对意见。一个全是前端开发者的团队无法自行提供产品增量并且自然地就开始思考技术能力也就是将他们团结起来的原因。相反，他们更应该关注的是客户以及如何满足他们的需求。
另一个有趣的考虑因素是团队中的非开发角色。在各种情况下，一个团队可能包括一个设计师、业务分析师和QA专家。一旦你拆分了一个团队，尤其是如果你没有雇更多的新人，那么在处理这些角色的问题上就会陷入两难的境地。他们应该分配自己的时间到不同的团队吗？你应该雇佣只服务于一个团队的新人吗？他们应该跟开发团队一起工作呢还是成为产品团队的一员？
对此并没有绝对的好建议因为每个产品都是不同的。这些决定最好与团队一起做出，同时记得需要一直不断修正。
团队之间应该有独立的Backlog吗？
如果一个团队被拆分，那么接下来的问题自然就是他们应该用同一个backlog工作还是再独立一个backlog出来。
Scrum@Scale是由Scrum指南的创建者开发的一种方法。Scrum@Scale不是很规范，但它确实指出了两点：
- 团队级别的流程跟Scrum指南中的流程相同。
- 产品负责人组成专门的产品负责人团队，在他们那里创建单一的backlog。这样做是为了避免重复工作，在公司范围内增强可见性。与此同时，团队从统一的backlog中提取各自的backlog。
所以，本质上来讲，Scrum@Scale描绘了新团队与他们各自的PO和backlog紧密配合的场景。只是添加了一些额外的结构来协调团队之间的工作。Scrum@Scale适合数个、数十个或数百个团队，但即使你们只有两个团队一起工作它也能提供一些有价值的见解。
大规模scrum（LeSS）
LeSS提供了一种有趣的产品backlog方法。在LeSS中，一个PO与2到8个团队一起工作。一个PO能跟那么多团队一起工作看起来有点不太可能。LeSS的理念是PO在抽象层面上工作，并将产品backlog项细化的职责委托给团队。这种情况下，跨职能开发团队还应该包括业务领域知识以便交付产品增量。在LeSS中，只有一个backlog。
如何保持更新？
对于一个产品经理来说，多团队意味着更多的工作追踪和响应查询。
优先级会议
如果你曾参加单个团队的每日站会，那么现在你可能会发现继续这个习惯很可能是徒劳的。将每日站会作为一个让他们了解团队动力并提醒他们可以进行讨论的机会。
你参加sprint规划会议与否取决于你团队的成熟度。如果团队中有很多新面孔或者他们已经很长时间没有用敏捷的方式工作了，那么你的指导就非常必要。即使你有信心让团队在没有你参与的情况下进行规划，如果出现问题请务必要在规划期间与团队进行交流或语音聊天。
Sprint review必须始终是你的首要任务，所有人都应该参加。Sprint review是一个能让你从所有在场的利益相关者和团队本身获得第一手反馈的机会。这是一个验证假设的时间，不应该错过。
与Scrum Master多互动
你可能会减少某些scrum仪式的参与，但应该增加与scrum master间的合作。团队拆分后，肯定不止一个scrum master，这种情况下，你需要与他们所有人密切合作。
确保你可以信任他们，以便真实了解团队的进展及sprint期间出现的任何问题。这种关系可以帮助你了解最新进展并且无需参加所有的scrum仪式。
scrum of scrums 介绍
时候也称为元scrum，scrum of scrums是一个新的仪式，通常作为scrum流程规模引入。它是更高级别的站会的复制品。每个团队都指派一名大使，所有大使每天都在S0S会议上碰面沟通进展和阻碍。这个会议还用于突出可能需要解决的任何跨团队技术问题。
考虑扩充产品团队
如果你的团队设置要求产品经理积极参与到团队中，那么请考虑在产品方面再添加一些人员。有几种方法可以解决这个问题：
初级产品经理。 一条途径是让自己承担更具挑战性的工作，同时增加初级产品经理来处理一些日常琐事。他们可以承担一些如质量保证（QA）、编写用户故事或为新功能创建高级模型的任务。
业务分析。 另一种方法是让一个或多个业务分析师在团队中或者与团队一起工作。产品经理可以与业务分析师一起确定产品假设，然后让业务分析师通过研究或新功能找到验证假设的方法。
结论
随着团队的发展，你可能会开始注意到一些它变得太大的迹象，尤其是在：
- 站会。 如果你们的每日站会超过15分钟的时间界限并且注意到人们开始逐渐失去兴趣。
- sprint规划 。如果你们在Sprint规划期间越来越频繁的陷入僵局。
- 回顾 。如果你开始注意到在回顾期间大家的意见越来越难达成一致。
所有这些迹象都表明你可能需要拆分团队。拆分团队看起来是一项简单的任务但也会带来持续的后果。如果真的要这么做，每个产品经理都要考虑以下几个问题：
- 团队士气 。理想情况下，应该让团队自己决定如何拆分，最大限度的减少对良好的工作关系的影响。
- 跨职能团队 。团队应该具备创建产品增量的所有必要技能。
- 产品backlog 。决定你的团队是有独立的还是一个统一的backlog。
如果需要跟踪两个或以上团队则需要确定优先级顺序。高效率的产品经理应该计划如何与新团队保持同步：
- 优先级会议 。思考哪些敏捷仪式是值得你花费时间参与的而哪些是可以被忽略的。
- 与scrum master互动 。让scrum master作为你的团队代理人，通过他们获取团队信
息。 - 扩充产品团队 。在产品团队中添加一些成员和你一起工作，让他们帮你完成一些日常重复性任务或进行用户调研和市场分析。
希望通过以上几点建议，你能有一个相对比较清晰的团队拆分思路。
Worktile官网： https://worktile.com/
作者：VYTAS BUTKUS
内容整理：Worktile
文章首发于「Worktile官方博客」，转载请注明来源。
