The Agile movement popularised a shift to teams which could pull their work, rather than having work pushed onto them. Practices such as Sprint Planning, or WIP Limits enable this. However, I’ve recently been thinking that rather than the people pulling the work, the work should be pulling the people. This seems counter-intuitive, and equivalent to going back to the traditional project-based approach of the past. To differentiate the different approaches, I will describe three basic teaming models.
Pushing People to the Work
This is the typical project teaming model. First, a central group (e.g. a PMO) defines the work up front as a project. Then they form teams and people are pushed to the work by allocating them to the projects. The diagram below visualises this, with the work at the centre, and people being pushed onto it. Apologies for the terrible artwork. I have tweaked the graphics from slides I used for Kanban presentations over 10 years ago!
In reality, people are often pushed onto multiple projects, making things even worse. In the next diagram, notice the unlucky person in the middle who has been allocated across (pushed to) three projects. At the same time, once people have been pushed onto projects, the actual work is often pushed back onto them. Time, scope and cost are fixed, with no allowance for their actual capacity or capability to do the work.
People Pull the Work
This is the typical Agile teaming model. First, long-lived and stable teams are formed to align to some product or value stream. Then the work is defined as backlog items (or options) and the teams pull that work as their capacity and capability allow in order to deliver value.
While this model is typically used with single agile teams, it can also be applied at scale with teams of teams. SAFe’s Agile Release Train structure usually consists of pre-formed and fixed teams that have a backlog of work to pull. As a result, PI Planning is often an exercise in managing dependencies between teams by adjusting the backlog and scheduling items into iterations.
Work Pulls the People
This is more of a Dynamic Reteaming model. First, a value stream is identified, and work is defined as backlog items (or options) to flow through the value stream. At the same time, a pool of people is also identified as part of that value stream. Then the people self-organise themselves into teams as necessary to deliver the highest value work, to the best quality, with the fastest flow. Thus, while the work is pulled into the value stream as capacity allows, it then pulls the people required to enable the flow. As new work is pulled in, the teams may reform to better match the skills and experience required by the changes in demand.
What this looks like in practice is a regular cadence where people can come together to review the current work and anticipate future work. In doing so they can re-organise themselves to deliver the highest value work, at the earliest date, to the best quality. A more general quarterly “Big Room Planning” (as opposed to SAFe’s PI Planning format) can be a good way of doing this.
Also, notice that in the above diagram, not everyone is on a team. Sometimes, it makes sense for people to float between teams to enable them to get better. Or they may form an enabling team of their own as per Team Topologies. Similarly, there will realistically be some constraints around who should be on each team. This may be with respect to experience and continuity to maintain consistency and quality of what is being built. Effectively, this dynamic reteaming model shifts team formation away from governing constraints which are independent of the work context. Instead, it shifts towards enabling constraints which allow for the context of the work.
I like your proposed model. I’ve been thinking on similar lines lately. Practically it seems like an experimental, iterative approach has been useful for gaining alignment and edging towards this. Ultimately it will take a certain degree of maturity and distributed decision making to reach this kind of advanced dynamic.