- Written by Lee Allison
And why this is THE reason for feature teams…
Donella Meadows, in her seminal book “Thinking in Systems,” wrote about the Law of Minimums.
"It was with regard to grain that Justus von Liebig came up with his famous “law of the minimum.” It doesn’t matter how much nitrogen is available to the grain, he said, if what’s short is phosphorus. It does no good to pour on more phosphorus, if the problem is low potassium."
This isn’t exactly new thinking here. After all, anyone who’s been a project manager for any amount of time has heard of critical path management, critical chain and even the theory of constraints. But it truly applies where feature teams are concerned.
I’ve been studying systems thinking lately and have been trying to apply this discipline directly to Agile. Over the weekend I realized that there is one basic stock that we take for granted… developer hours. Of course, I mean developer in the Agile sense; ie: everyone who works directly on the product.
If you view dev hours as a stock then its easy to start to look at the various drains that draw on that stock; vacations, meetings, sick leave, long lunches, etc. And the less of that stock there is the less amount of product that will be delivered. While I was considering this, the law of the minimum occurred to me.
If your group is chronically short on QA (not an uncommon occurrence) and all of the QA folks are sitting in one team, then your organization can only generate product as fast as the QA team can run its tests. The same situation exists for all specialist roles in your organization: UI/UX, database, IT Ops, etc. When looking at stories flowing through your system, any chokepoint will limit the organization’s ability to finish those stories. I don’t know about you, but in my experience, the ability to churn out product very strongly determines any company’s fate.
And this is where feature teams SHINE. By arranging your developers into holistic groups that can completely deliver a story you get the ability to deliver finished product without running into the self-induced limits that specialist teams bring. On those occasions when you lose a person, for whatever reason, then the worst case scenario is that one feature team is sub-optimal. All of the others can keep on producing. That isn’t true for a specialist arrangement.
I hear lots of reasons for feature teams, lots of good reasons. But in my mind this is the one reason that is most likely to make sense to a non-agilist. This logic speaks directly to the company’s ability to generate value. If you have multiple, smaller teams who can all produce full and complete stories, then your limit to growth won’t be your ability to generate product. It will shift to some other limit, like marketing, capitalization or such.
I keep seeing this same anti-pattern over and over. People just seem so wed to specialist teams and resist any attempt to get their people aligned in the best possible way. Hopefully this article will help some of you win this argument. Again.