Scrum Self-Similarity: Creating Organizational Fractals

Scrum exhibits fractal self-similarity, a property you can use to scale Scrum. Large organizations can deliver higher corporate productivity, revenues and agility in the face of rapidly changing markets. Everything scales, including the challenges.

We use a unique Enterprise Scrum process at Citrix Online (we are aware of no other organization using it) to manage a large, multiproduct engineering department. Anyone who cares, from the President on down, knows what engineers are working on, and has discussed and agreed on priorities.

Everyone knows what projects are succeeding, and which are having trouble. When a problem could impede a release, it becomes rapidly visible and can trigger immediate executive action. We are producing more frequent releases, and our engineers are becoming more flexible and better aligned with company success. Enterprise Scrum works.

To create Enterprise Scrum, I analyzed normal Scrum as a fractal, focused on Scrum’s fundamental properties, and then scaled them up.

Fractals in Scrum

Fractals are geometric shapes that exhibit self-similarity: some properties remain the same regardless of scale. For example, Figure 1c is a fractal. If you look at the gross structure in Figures 1a, 1b and 1c, the images are similar (squint if you are having trouble). Going from Figure 1a to 1c, the metrics, complexity and fine detail become greater, but the general outline remains the same.

Normal Scrum exhibits self-similarity, so we’ll use it as an example.

Scrum has two feedback loops at different time scales. Every sprint, the whole team discusses what they did (Sprint Review),
what they will do (Sprint Planning) and what blocks progress (Sprint
Retrospective). Every day, the standup meeting requires each team member to discuss what they did, what they will do, and what blocks progress. The rough purpose of each feedback loop is the same: share information, get feedback, adjust goals, escalate impediments. Everything but the time-scale is roughly the same.

Scrum has two estimation scales. Whole teams groom and estimate effort for Product Backlog Items, using story points, a unit often roughly the size of estimated programmer days. The whole team is considered responsible for a Product Backlog Item. Individual team members usually generate and estimate effort for Tasks, using estimated programmer hours. That same person is responsible for completing the Task.

The purposes of estimation is the same: allow the team and individuals to prioritize activities on both relative value and relative effort, limit effort to respect the capacity of the team and individuals, allow the team and individuals to focus on a small number of activities, and gain greater understanding of the actual capacity of the team and individuals. They differ in scale.

Typical Scrum teams establish done criteria at different scales, though people sometimes don’t realize it.

For example, a Task Done Criteria might include

1. unit tests were written and succeed,
2. a local build with all tests still succeeds,
3. the code was reviewed by another team member,and
4. the work was checked into the source control system.

A Product Backlog Item Done Criteria might include

1. automated feature test was written and succeeded,
2. continuous build system on all platforms still succeeds,
3. team agrees it is good quality and marks it Done, and
4. deployment package was produced and checked into the repository.

Finally, a Sprint Done Criteria might include

1. upgrade and revert processes were performed on a clean integration system,
2. operations staff did a successful dry run install,
3. Product Owner reviewed the Sprint Backlog Items, marked them Accepted or rolled them forward, and closed the Sprint, and
4. product package was queued up in the Operations Backlog.

Let’s review the Done Criteria parallelism. The 1s confirm the work was done. The 2s ensure other components in the ecosystem won’t fail. The 3s cause an external party to validate the work. The 4s publish the work. They differ in scale. Now, when you look at the subcaptions of Figure 1, they might make more sense.

Scaling Scrum to the Enterprise

We’ve analyzed what exists, normal Scrum. Let’s create something new, by scaling Scrum up to meet the needs of a whole engineering department. Enterprise Scrum looks like regular Scrum, with everything writ
large:

• Story point size is estimated team months, estimates come from architects,
• Enterprise Backlog Items (EBIs) can be no smaller than 1 team-month of work,
• Sprint size is three months, i.e., a Quarter,
• Standup meeting frequency is every week, and
• Teams (not people) sign up for Enterprise Backlog Items.

If you were thinking Enterprise Scrum is just Scrum-of-Scrums, you’d
be wrong—Enterprise Scrum is top-down, Scrum-of-Scrums is bottom-up. Citrix Online does both: in a big project, we do Scrum-of-Scrums; to prioritize and staff multiple big projects and products, we do Enterprise Scrum.

Sound simple? Once running, Enterprise Scrum is mechanically simple, but initiating is not. Your executive staff will take time to adopt Enterprise Scrum. Enterprise Scrum increases executive accountability, always a little scary. Enterprise Scrum exposes executive decisions so publicly that they can be second-guessed, and this threatens control. Without Enterprise Scrum, other departments could blame delays on the engineering department. I don’t think you can adopt Enterprise Scrum unless your CEO and relevant Vice Presidents support you.

In other words, in this fractal the diplomatic challenges scale up with the rest. The same organizational impediments you faced with Scrum adoption will emerge in Enterprise Scrum, writ large. But the rewards scale too; if your company can do it, you win big in productivity.