大规模Scrum中的分形结构
所谓分形，就是一种你细看的话在不同尺度上都能找到相似形状的结构。
拉近再拉远来看Scrum
首先，修正常见的错误理解
一般常见的Scrum图示大体上和图A类似。这可能是对迭代开发和经验过程的误解。在一个Sprint过后，如图B所示，该组织应该要调整前进方向。这体现在他们更新了的产品待办事项列表上。
转个方向靠近一点看
想像我们把图B向内转90度，再靠近一点，看看成功的Scrum团队内部的细节。在一个Sprint中，里面其实有多个迭代，每一个都会产出完成了的产品增量、得到完整的反馈、并且产出用户价值。团队完成一个待办事项之后才开始下一个，这样就把在制品（WIP）数控制在最小，如图C所示。Scrum具有迭代的性质不是说一个Sprint就只是一个迭代。
再近一点看
如果你再近一点仔细看的话，一个成功的Scrum团队的内部工作方式在重复上面描述的模式。当他们工作在一个待办事项时，会把它分成很多更小的迭代，其中每个都是向目标靠近的坚实的一小步，并且尽量得到全反馈。就像图D那样，这样的团队会用像ATDD、TDD、主干分支开发、持续交付等等方法来达到他们的目的。
还是不够近
那就让我们看得更加近一些。一个有众多成员的成功团队大概不会只以单一的线程工作（也有些团队真的就是用mob programming这样的方式保持单一线程）。他们可能会把待办事项分成小的任务，然后并行工作。不过和我们前面看到的一样，所有的任务都属于同一个待办事项，并且每一个人都在持续地协调和集成，看上去就像图E。对很多人来说这看上去有点吓人，但对于一个实践代码共有、持续集成、手谈（用代码沟通）以及自主协调的团队来讲这很正常。当然，像TDD这样的个人实践也在其中。可惜的是，一方面决策者往往看不到这个级别，很多团队自身因为技术实践水平所限往往也没机会体验到这种状态。
拉远了看一看
现在让我们拉得远一点看看。你会如何规模化Scrum呢？在大规模Scrum中，一个Sprint看上去应该像图F那样。整个开发织组向着同一个方向努力。虽然每个团队关注在不同的以用户为中心的待办事项上，但这些事项都是关于有限的几个主题的（最好就是一个主题）。他们自己不停地集成和协调。在Sprint结束时，整个组织有了新的方向，这体现在他们唯一的、更新过的产品待办事项列表上。
错误的分形
有人说过“所有的模型都是错的，但是有些是有用的”。多年以来这个模型帮助我理解不同规模上的Scrum。但是我从来不提分形结构是因为这个理解可能也有很多问题。在不同规模上面临的问题的性质，所受到的约束是不太一样的，而且分形也容易被曲解。可是现在我越想越觉得其中的相似和相似的道理足以对大家都有帮助。不过还是重点澄清几个事情的好：
Sprint自身不是分形的一部分。Sprint是很独特的，比方说它用时间盒，这和工作的上下文不直接相关但是它是一个组织的节奏。
一个对Scrum的错误理解是，工作要事先计划好以断开其中的依赖关系，这事情一般由管理者来做。完成每项任务时的协调，以及完成后的集成也是由管理者控制的。按照这种想法也可以以“分形”的方式来规模化“Scrum”，如下图所示。不过这样的模型就错得太离谱，只有害，没有用了。