From the Scrum alliance comes this advice on conducting Scrum of Scrums meetings:
The scrum of scrums meeting is an important technique in scaling Scrum to large project teams. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.
The book Agile and Iterative Development also discuss this issue.
I don't think there is a boundary, after all the ideas of scrum came out of car manufactoring and that's pretty big in terms of people. The thing with big projects is, that you need to start with a small team and grow it over time. Keep separate teams that interact via Scrum of Scrums and it will scale, if the people are willing to collaborate it will work. It's like always in our business: divide and conquer. Break the big hard problem into smaller manageble chunks.
It outlines a lot of the issues and trade-offs he ran into when scaling up Scrum / XP at Microsoft, and has some very thoughtful and interesting solutions.
There are other posts on the same blog that also deal with these issues of scale that concern you - IMO it's a gold-mine of ideas on "agile for grown-ups".
Within a team the communication channels are proportional to (N * N-1) / 2 as an upper bound, so could loosely be viewed as O(N^2). The decentralised nature of agile teams means that there is no central point of reference and the communication will grow closer to the upper bound than if there was such a point of reference.
Where you have a written specification and a more formal structure (see Painless Functional Specification for a discussion of spec documents) the communication is closer to a hub-and-spoke model, which has closer to O(N) channels (for N staff on the project). Most of the rule-of-thumb commentary I've seen puts the sweet spot for Agile teams at 6 or less and the upper bound at around 10, although your mileage may vary.
In the PFS articles Joel (yes, that Joel) discusses the role of a Programme Manager, whose role is to develop and own the specification. The Painless Functional Specifications series goes into this in quite a bit of detail and is also quite accessible to non-technical management - I've referred quite a few people to this article.
Picture Scrum/XP as a series of mini-Waterfalls. Initially, you want to do an upfront effort to get a good, well-defined backlog. Not necessarily the whole system, I'd argue that once you get one or two sprints worth of product backlog items, it's time to start sprinting. Concurrently with the sprint, you should be creating additional PBIs (and reprioritizing them appropriately).
The idea is that you can get business value delivered before the system is FULLY defined.
Scaling scrum or any agile approach is dependent on your environment.
If you have multiple projects with multiple teams, scaling is simply sharing best practices across teams. As soon as you start requiring integration between systems/projects, be wary. Tighter integration between teams is preferable at that point.
If you have one large project (I had a team of 45 at one point), there are different approaches to scaling. We chose to keep one team with multiple standups - developer standup separate from BA/QA standup. The iteration manager attended both and at least one from each side attended the other. We had one card wall, but it included pre-iteration stuff (stories in process of analysis, production bugs to chase) and post-iteration stuff (release/deployment work).
I've also been a part of one very large project with many scrum teams (~20 teams - some distributed - ranging from 10-20 members each). Each had separate standups, and there was a scrum-of-scrums and even a scrum-of-scrum-of-scrums. I think we made a mistake by segmenting the teams by functional area rather than workflows. Our segmentation created silos of code ownership with onerous integration management issues between teams.
In sum, it's not just about size for scaling... it's also about the content of the project. Feel free to share more specifics about your environment to hear more specific approaches to addressing scale in your environment.
CAS 以人体为例。 我们有心脏和肝脏等器官。 它们是独立的模块（细胞团队:)，通过神经系统/血液/等相互作用。
Agile scales fine. It is not a rocket science. In fact it is all about modularity. Software development is a CAS (Complex Adaptive System) and, as almost any CAS, it has modules to rule the complexity better. Scrum of Scrums is one of the possible modular approach for development process scaling. Functional divisions (Developers, QA, etc) is an another modular approach. The worst case is when you do not have modules at all in a large project.
Depending on a project nature, team may decide what modules will work for the project. General pattern is to form several teams that work on some low cohesion modules. Each team should be quite autonomous, but interaction with another teams should be good.
The analogy from CAS is a human body for example. We have organs like heart and liver. They are separate modules (teams of cells :) that interacts via nervous system/blood/etc.
发布评论
评论（7）
Scrum 可以使用“Scrum of Scrums”进行扩展。
来自 Scrum 联盟的建议< /a> 关于召开 Scrum of Scrums 会议：
《敏捷与迭代开发》一书还 讨论此问题。
Scrum can be scaled using "Scrum of Scrums".
From the Scrum alliance comes this advice on conducting Scrum of Scrums meetings:
The book Agile and Iterative Development also discuss this issue.
我不认为存在界限，毕竟 Scrum 的所有想法都来自汽车制造，而且就人员而言，这是相当大的。 大型项目的问题是，您需要从一个小团队开始，并随着时间的推移不断发展壮大。 保持独立的团队通过 Scrum of Scrums 进行交互，如果人们愿意合作，它就会规模化，它就会发挥作用。 就像我们行业中一贯的做法一样：分而治之。 将大难题分解为易于管理的小块。
I don't think there is a boundary, after all the ideas of scrum came out of car manufactoring and that's pretty big in terms of people. The thing with big projects is, that you need to start with a small team and grow it over time. Keep separate teams that interact via Scrum of Scrums and it will scale, if the people are willing to collaborate it will work. It's like always in our business: divide and conquer. Break the big hard problem into smaller manageble chunks.
请查看这篇博文 伯尼·汤普森。
它概述了他在 Microsoft 扩展 Scrum / XP 时遇到的许多问题和权衡，并提供了一些非常深思熟虑且有趣的解决方案。
同一个博客上还有其他帖子也涉及您关心的这些规模问题 - 在我看来，这是“成人敏捷”思想的金矿。
Have a look at this blog post by Bernie Thompson.
It outlines a lot of the issues and trade-offs he ran into when scaling up Scrum / XP at Microsoft, and has some very thoughtful and interesting solutions.
There are other posts on the same blog that also deal with these issues of scale that concern you - IMO it's a gold-mine of ideas on "agile for grown-ups".
在团队内，沟通渠道与上限 (N * N-1) / 2 成正比，因此可以大致视为 O(N^2)。 敏捷团队的分散性质意味着没有中心参考点，并且与有这样的参考点相比，沟通将更加接近上限。
如果您有书面规范和更正式的结构（请参阅无痛功能规范了解规范文档的讨论）通信更接近于中心辐射模型，该模型更接近于 O(N) 通道（针对项目中的 N 名员工）。 我见过的大多数经验法则评论都将敏捷团队的最佳点设置为 6 或更少，上限为 10 左右，尽管您的里程可能会有所不同。
在 PFS 文章中，Joel（是的，那个 Joel）讨论了 项目经理，其职责是开发和拥有规范。 无痛功能规范系列对此进行了相当详细的介绍，并且对于非技术管理人员来说也很容易理解 - 我已经向很多人推荐了这篇文章。
Within a team the communication channels are proportional to (N * N-1) / 2 as an upper bound, so could loosely be viewed as O(N^2). The decentralised nature of agile teams means that there is no central point of reference and the communication will grow closer to the upper bound than if there was such a point of reference.
Where you have a written specification and a more formal structure (see Painless Functional Specification for a discussion of spec documents) the communication is closer to a hub-and-spoke model, which has closer to O(N) channels (for N staff on the project). Most of the rule-of-thumb commentary I've seen puts the sweet spot for Agile teams at 6 or less and the upper bound at around 10, although your mileage may vary.
In the PFS articles Joel (yes, that Joel) discusses the role of a Programme Manager, whose role is to develop and own the specification. The Painless Functional Specifications series goes into this in quite a bit of detail and is also quite accessible to non-technical management - I've referred quite a few people to this article.
将 Scrum/XP 想象为一系列迷你瀑布。 最初，您希望做好前期工作以获得良好的、定义明确的待办事项列表。 不一定是整个系统，我认为一旦你获得了一两个冲刺的产品积压项目，就该开始冲刺了。 在冲刺的同时，您应该创建额外的 PBI（并适当地重新调整它们的优先级）。
我们的想法是，您可以在系统完全定义之前获得交付的业务价值。
Picture Scrum/XP as a series of mini-Waterfalls. Initially, you want to do an upfront effort to get a good, well-defined backlog. Not necessarily the whole system, I'd argue that once you get one or two sprints worth of product backlog items, it's time to start sprinting. Concurrently with the sprint, you should be creating additional PBIs (and reprioritizing them appropriately).
The idea is that you can get business value delivered before the system is FULLY defined.
扩展 scrum 或任何敏捷方法都取决于您的环境。
如果您有多个团队的多个项目，那么扩展只是跨团队共享最佳实践。 一旦您开始需要系统/项目之间的集成，请保持警惕。 此时，团队之间更紧密的整合是更好的选择。
如果您有一个大型项目（我曾经有一个 45 人的团队），则可以采用不同的扩展方法。 我们选择让一个团队拥有多个站立会议 - 开发人员站立会议与 BA/QA 站立会议分开。 迭代经理出席了双方的会议，并且双方至少有一个人出席了另一方。 我们有一面卡片墙，但它包括迭代前的内容（分析过程中的故事、要追踪的生产错误）和迭代后的内容（发布/部署工作）。
我还参与过一个非常大的项目，该项目有许多 Scrum 团队（大约 20 个团队 - 有些是分布式的 - 每个团队有 10 到 20 名成员）。 每个人都有单独的站会，还有争吵中的争吵，甚至争吵中的争吵。 我认为我们按照职能领域而不是工作流程来划分团队是错误的。 我们的细分造成了代码所有权的孤岛以及团队之间繁重的集成管理问题。
总而言之，这不仅仅是关于缩放的大小……还与项目的内容有关。 请随意分享有关您的环境的更多具体信息，以了解解决您环境中规模问题的更具体方法。
Scaling scrum or any agile approach is dependent on your environment.
If you have multiple projects with multiple teams, scaling is simply sharing best practices across teams. As soon as you start requiring integration between systems/projects, be wary. Tighter integration between teams is preferable at that point.
If you have one large project (I had a team of 45 at one point), there are different approaches to scaling. We chose to keep one team with multiple standups - developer standup separate from BA/QA standup. The iteration manager attended both and at least one from each side attended the other. We had one card wall, but it included pre-iteration stuff (stories in process of analysis, production bugs to chase) and post-iteration stuff (release/deployment work).
I've also been a part of one very large project with many scrum teams (~20 teams - some distributed - ranging from 10-20 members each). Each had separate standups, and there was a scrum-of-scrums and even a scrum-of-scrum-of-scrums. I think we made a mistake by segmenting the teams by functional area rather than workflows. Our segmentation created silos of code ownership with onerous integration management issues between teams.
In sum, it's not just about size for scaling... it's also about the content of the project. Feel free to share more specifics about your environment to hear more specific approaches to addressing scale in your environment.
敏捷规模很好。 这不是一门火箭科学。 事实上，这一切都与模块化有关。 软件开发是一个 CAS（复杂自适应系统），与几乎所有 CAS 一样，它具有更好地控制复杂性的模块。 Scrum of Scrums 是用于扩展开发流程的可能的模块化方法之一。 职能部门（开发人员、质量保证等）是另一种模块化方法。 最糟糕的情况是大型项目中根本没有模块。
根据项目性质，团队可以决定哪些模块适用于该项目。 一般模式是组建多个团队来处理一些低内聚模块。 每个团队应该非常自治，但与其他团队的互动应该很好。
CAS 以人体为例。 我们有心脏和肝脏等器官。 它们是独立的模块（细胞团队:)，通过神经系统/血液/等相互作用。
Agile scales fine. It is not a rocket science. In fact it is all about modularity. Software development is a CAS (Complex Adaptive System) and, as almost any CAS, it has modules to rule the complexity better. Scrum of Scrums is one of the possible modular approach for development process scaling. Functional divisions (Developers, QA, etc) is an another modular approach. The worst case is when you do not have modules at all in a large project.
Depending on a project nature, team may decide what modules will work for the project. General pattern is to form several teams that work on some low cohesion modules. Each team should be quite autonomous, but interaction with another teams should be good.
The analogy from CAS is a human body for example. We have organs like heart and liver. They are separate modules (teams of cells :) that interacts via nervous system/blood/etc.