Split work and people

How to split work (from big to small) and how to split people (into multiple teams) are two essential and very related topics in the context of scaling Agile.

In these two dimensions (work and people), there are two common splitting strategies, through component or through feature. This leads to the below diagram.

Let's dive deep into each quadrant.

• Component work by Component team

This is the traditional way of working, and strongly related to waterfall development. Feature is split into components via design by architecture group, then developed and (component) tested by component teams, eventually integrated and (system) tested by system testing group. The problems with this strategy are handoff waste, prolonged cycle time, delayed feedback, lack of flexibility, etc.

• Feature work by Component team(s)

First split from big feature to small features, then split into component tasks is the key idea behind Agile and helps tremendously on the speed and flexibility in value delivery. When related component teams are able to collaboratively deliver the same small feature at the same time, it is quite ok. However, in practice, those component work around same feature is often out of sync, which delays feedback and value delivery. Moreover, this is a systematic problem, and can not be solved by stronger coordination. The deep assumption behind component team structure is that people are most efficient in working on familiar areas, and learning other areas is costly and slow.

I put SAFe into this quadrant, not because SAFe demands component team structure, but because SAFe implementation tends to retain current organizational structure, while component team structure is prevalent in organizations.

• Feature work by Feature team

Feature team takes feature, and splits into smaller features to deliver. This is great in achieving agility. This systematically addresses the problems with component team. Meanwhile, it has its own challenges such as coordinating in code, maintaining the component integrity, efficient learning, etc. Furthermore, it demands organization (re)design, which usually means more radical change thus is perceived as more risky.

I put LeSS into this quadrant, because LeSS explicitly requires that the majority of teams are feature teams. Organization design is vital in LeSS adoption.

• Component work by Feature team

This is rarely seen in practice. If you already have feature team, it makes no sense to feed them with component work. Rather feature team will take feature as input and split them into component tasks as part of their development.

Conclusion:

Split work via feature dimension is critical element in Agile adoption, while split teams via feature dimension is critical element in LeSS adoption. This is the place we shall strive for.