Shrinking Teams





Shrinking Teams

As a team grows in capability, keep its workload constant but gradually reduce its size. This frees people to form more teams. When the team has too few members, merge it with another too-small team. This is a practice used by the Toyota Production System. I haven't actually used it, but it makes so much sense to me that I include it here. The other strategies I've seen for scaling up to larger workloads, like creating bigger and bigger teams, work so poorly that alternatives are worth considering.

Since I don't have experience with this practice, I'll explain by analogy. Say five people work together in a manufacturing cell. Rather than load them all equally, make sure that as many people as possible are fully engaged. The fifth person, then, might be working only 30% of the time. This is good. The team members, as they do their work, also think about how to improve their work process. They try ideas until they eliminate enough wasted effort that the fifth person is no longer needed. Trying to keep everyone looking busy obscures the fact that the team has extra resources available.

Try the same in software development. Figure out how many stories the customer needs each week. Strive to improve development until some of the team members are idle; then you're ready to shrink the team and continue.


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows