Pull systems provide a lot of the value in Lean/Agile approaches to delivering software. In general, throughput increases as we move towards pull systems. More throughput means more profit. In simple terms: pull is good; pull works.

What the hell is “pull”? In a work system, “pull” means that workers grab the next available task as they finish their current task, whereas “push” means that someone assigns work to workers, who then complete tasks one by one. As you might guess, in a “push” system, the manager assigns enough work to keep the worker busy all the time, which is to say, more work than the worker can ever possibly complete. In a purely pull system, we wouldn’t even identify the next task to do until someone became available to do it, but I’ve never seen a software team work that way. I have worked that way as an individual on a solo project on which I also acted as the customer. I digress.

I encourage all members of the team to pull their work from a single project backlog. This leads to higher profit (higher throughput) compared to a project manager assigning work to individuals. The team delivers sooner when the next available person takes responsibility for completing the next desired feature. (That person might ask someone to pair on the work, but that doesn’t matter for this discussion.) When instead we favor giving work to specialists, for example to “the most capable hands”, that work waits for those hands to become free. This creates backlogs in front of individual people—work becomes trapped as other, available workers, diligently push to whittle down their own backlogs. Even if we finish this work with less effort (time spent working), those features take longer to complete (calendar days from request to deployment), because waiting time increases. Waiting time seems to increase almost without bound. The conclusion seems clear: give the team a single backlog of features and don’t plan in advance who does which work.

This makes some people nervous. Not everyone has the same skill level. Not everyone has the same motivation level. Not everyone has the same level of engagement. Surely I can improve the situation if I strategically assign the most important work to the most capable people. This would mean creating individual work-streams for individual people. Since we find the Kanban Method most fashionable these days, that implies individual Kanban Boards for individual programmers. The nervous project manager or executive feels better knowing that the most trusted programmers will work on the most important work.

Except it doesn’t work. Waiting time goes up. Important features languish because the most capable hands already have too much to do. It feels more efficient, but profit goes down. Queueing theory tells us that this will happen, and it does.

And then it gets worse.

When you give work to individual people, but call them a “team”, then you set up competition between “team” members for important resources, especially the recognition of their peers and superiors. Some executives believe that competition improves worker engagement, but I’ve mostly seen the opposite. Would you like a compelling example of this? I thought you might. I refer you to a series of articles (5-10 minutes’ read for each one) chronicling a restaurateur’s experience running two restaurants, in only one of which he has eliminated the arcane custom of tipping. Click here to start reading those articles. When you encourage your programmers to work towards independent goals, rather than team goals, it has the impact of making them work for tips, except that you probably call those tips “bonuses” and “perqs”.

Please, please, please do not waste your energy creating cross-functional teams, then give each team member a separate work-stream. To do this would destroy all your effort creating a cross-functional team. Build a team, then let the members pull work off the backlog. If someone on the team isn’t pulling their weight, then the team will know who, and it won’t keep that a secret for long. As the team achieves more, its members should feel more engaged, and if a team member doesn’t feel more engaged, then you have a much deeper problem than one could solve with a carrot or stick.

One team. One Kanban board. One stream of work. It just works.

If you’d like to learn more about the power of worker engagement, then you should read, unsurprisingly, The Power of Full Engagement. I have enjoyed this book a few times and have found little nuggets of value in it each time I’ve read it. (Well, listened to it—I have the audiobook.)