Reteaming Is Not Resourcing

A long time ago, as a new Development Manager, I was confronted with a "pool" of twenty-five software engineers managed by a "team" of five project managers. Every week, the project managers discussed their various clients and decided which software engineers they would move to which projects. These meetings involved significant negotiations and heated debates in which they attempted to match the most critical work with the available engineers. There was a lot of resourcing.

Needless to say, this was not a productive way of working. For the project managers, this was a weekly fight over the most valuable "resources." At the same time, the software developers felt as if they were constantly being pulled by their necks and thrown around from one project to the other. It was a terrible situation.

So, one of the first things I did was to create self-managing, Steady Teams?of engineers, and I told the PMs they could offer work to teams rather than individuals. The team members would figure out their expected capacity and who would be doing what within each team, using an approach heavily inspired by (but different from) Scrum. It worked! At the time, I thought it was the only logical solution.

Now, I know there are other possibilities.

The Teaming Options in the unFIX model suggest that we could have created four Dynamic Teams (still self-managing but with individuals moving across team boundaries). We could have created Mission Teams (temporary teams per project within one large Team of Teams). We might even have tried Liquid Teams (with engineers swarming between short-term projects). As long as we turned the original "pool of resources" into a self-managing Turf of software developers, with project managers respecting the needs of the engineers and the projected capacity of subteams, we could even have tried several ways of working to see which one delivered the best results.

However, I was unaware of the various alternative options, and the static team?dogma was still strong in the Agile community then.

Now, I know better.

I'm glad to see that, despite pushback from several conservative pockets within the larger Agile community, voluntary reteaming across autonomous, self-managing teams is increasingly accepted as something worth trying. And no, this is not a return to the old days of "pools of resources" managed by project managers. Nobody is being pulled by their necks and thrown across projects.

Reteaming is NOT the same as resourcing.

Jurgen