Heterogeneous Scrum: overview

What I envision as Heterogeneous Scrum is basically to separate a Scrum team into two separate sub-teams. These teams can still be cross-functional and their members interchangeable, and ideally do a sprint-based rotation to keep everyone fresh and ease knowledge transfer.

What’s the difference between them?

One sub-team, which we’ll call IAI, will do small tasks, bugfixing, architecture discussions, brainstorming meetings, your usual refinements, specification writing or requirement discovery, plus deal with production issues. This sub-team is all about Interaction and Interruption. It’s the CPU of your team. Also, for most purposes, this sub-team can replace the ScrumMaster role in terms of handling external communication, removal of roadblocks, and general project assistance to the Product Owner.

The other sub-team, which we’ll call PAF, just takes tasks from the board and does them. Tasks scheduled to this sub-team should be relatively large; the usual 8 story-point and above. They can do pair programming, or solo, pick up approaches from extreme programming or do whatever they like, but they just crunch code away, review it, and test it. This sub-team is about Progress and Focus. It’s the GPU of your team.

Interestingly, this might be not Scrum at all:

Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

While implementing only parts of Scrum is possible, the result is not Scrum.

—The Scrum Guide

Or be completely Scrum anyway:

The development team is self-organizing.

—Also the Scrum Guide

So it is Scrum depending on the external observer.

Heterogeneous Scrum: rationale

You may already know where I’m going, but you may still ask yourself, what’s this split for?

It comes from personal experience. I’m a witness of how numerous Scrum approaches make difficult to perform any focused work, and reduced capability to perform quality work. I routinely see people going to work early or stay late to get things done, simply because there are fewer people around. And that’s not how it should be.

Whether you like it or not, the fact is that there’s no safe amount of multitasking and productivity only decreases with context switching.

I am not alone when I find that there are just way too many meetings in Scrum. Someone might excuse this as You’re Doing Scrum Wrong™, and while I agree somewhat, it’s still a bit like the That’s Not Real Communism™ when so many people keep trying and bringing this issue up. My anecdotal evidence points to people not minding (or liking) the amount of meetings when they tend to do IAI work, and the opposite when they lean towards PAF work, and most people love and hate these from time to time depending on the level of mental involvement in their tasks at any given time. That’s the main issue I see Heterogeneous Scrum solving.

Scrum.org has an article on this topic, but I find that it’s largely a strawman argument against long meetings (rather than its number), and most of the advice in there is either self-evident (Make them short by timeboxing! Thanks, doctor, I’m cured!), or plain wishful thinking (Refinement is no longer a meeting! While most of its advantages of it come from being a meeting with actual exchanges being done). The only real advice that actually tackles the problem is to enforce Do Not Disturb slots, but even that will just move internal interactions from one slot to another.

Another common mantra is to make sprints as short as possible. While this has the advantage of reducing the length of meetings (who likes 3h refinement meetings, right?), in practice it just multiplies the number of context switches per unit of time, which is more of a problem than the actual length of the meetings, from a mental load perspective. Also the fact that in practice, since most people (and often everyone) are required to join these meetings, these are scheduled to start at the dreaded 10-11h and 14-16h (2-4pm) slots, interrupting focused worked only to accommodate the relative freedom of arrival/departure at the workplace of the members.

But not only meetings are the bane of the flow: also external communication with other teams and clients, and even internal among team members add to it.

While the ScrumMaster is there to protect the team, expecting the ScrumMaster to filter all external interaction is often a bottleneck, yet letting all external interaction in obviously hurts the team.

The point of Heterogeneous Scrum is to add a new agility dimension to the team, and adapt the team and the user stories according to the nature of the workload on a sprint per sprint basis.

Team Architecture

This brings a topic that’s rarely (ever?) discussed, and it’s what I call Team Architecture. How people in the team are supposed to interact, how information flows between them, how are responsibilites distributed, how newcomers are introduced, or simply the size of the team… are all important points to address both for maximizing both the performance of the team and the well-being of their members.

Scrum as such defines a very loose architecture (guidelines on number of team members) and delegates the rest to the team without any particular recommendation. That usually translates into a lack of architecture, a shapeless blob in term of responsibilities, and large blast radius in terms of information flow impact (most communication happening in a large Slack channel, mailing lists with everyone in, everyone must join all team conference calls, etc). Teams are free to tackle these problems individually, but they’re not always given the tools to architect themselves the right way.

Heterogeneous Scrum as I present it is nothing but a framework that defines broad team-architectural choices that teams can decide to use and adapt.

Heterogeneous Scrum: architecture

Heterogeneous Scrum as an instance of Scrum is a team architecture that tries to maintain a high team throughput while keeping the ability to adapt to the moving target that is business. While meetings in particular (and interruptions in general) are a necessary evil, it doesn’t mean that these flow breaking artifacts can’t be harnessed, tamed, and domesticated.

The IAI sub-team handles most ScrumMaster responsibilities, regular development tasks that are small and well defined in scope and complexity, along with all Scrum meetings (sorry, events), any topic-specific meetings, architecture boards, and cross team coordination. Most of the value from these tasks comes from being a large number of relatively independent and short bursts of work: definition of further tasks, presentations, demos, actionables, user story refinement, sizing, and small development tasks. There’s no interruption if you finished the previous task to begin with! And there’s less damage if the interruption happened but your task at hand is relatively small and of little complexity.

The PAF sub-team handles large user stories. That’s it. Their user stories have been digested enough to be well defined coding-reviewing-testing blocks of work that can be done independently from the rest of the team.

The PAF sub-team has few or no Scrum mee^H^H^Hevents aside from an initial Sprint Planning, though they’re free to attend them:

• Sprint Planning: obviously they have a say in what’s gonna be done during the Sprint. Also this event should decide the size and composition of each sub-team, to adapt to the incoming workload.
• Daily Scrum: the PAF members can join it if they want, especially if they struggle with something or have a point to raise. Otherwise it’s generally a waste of time, but mainly focus, for those that have worked, still work, and will work on the same subject for one week straight without dealing with IAI-type tasks.
• Sprint Review: this event usually shows what’s been done, and, in my opinion, there’s no better Definition Of Done than one that requires someone else being able to show it off. On task completion, the PAF member will assign the task to the IAI sub-team for them to produce a live demo of the story, and immediately move onto another task. They can attend if desired, but preparing a demo would be out of scope for the sub-team.
• Retrospective: PAF members are, again, free to join or not. In practice, and at least in my experience, most of the problems and improvements explored in this event relate to responsibilities that now almost exclusively lie within the IAI sub-team: communication, meeting format, blocking points, externalities, etc. Of course, PAF members should join shall they find any teamwork or organizational concern or recommendation, but ideally they shouldn’t feel the need.
• Backlog refinement: probably the worst one in terms of removing focus from the task at hand, at least for me. I’m working on X, it’d be great if I could analyze W, Y and Z said a brain in the zone never. Again, freedom to join, but ideally PAF members are advancing on their own tasks instead.

PAF could have eventual cross-team exchanges for tasks that require coordinated development, but these tasks should be exceptional, and IAI should ensure in the refinement that this kind of tasks reach PAF at a minimum, and schedule them for themselves instead.

Regarding the size of the team, traditional Scrum recommends 7 (5 devs) and no more than 9 (7 devs), namely for coordination and communication overhead. Isolating these responsibilities into a sub-team allows teams to grow (and kind of requires them to to benefit from it) while precisely limiting these factors. This gives teams the ability to scale the team towards 12-20 people (10-18 devs), or even further if required, as only the size of the IAI sub-team is the limiting factor.

The communication constraints should ideally be enforced. PAF members should be removed from irrelevant channels and mailing lists. They’re free to contact IAI, but not the other way around unless related to their task at hand.

Heterogeneous Scrum: closing thoughts

I’m not even sure I’ll ever see this being put in practice, as certainly something will replace Agile/Scrum in the coming years. Maybe watefall will return, or Scrum and CMMI will have a baby. But I doubt it’s not happening already somewhere, even informally, since this article is born not only from personal experience, but from coffee machine conversations and personal exchanges.