Brad wrote an interesting post about peanut buttering software, in which he asks if I’ve ever seen that.
Yes, I’ve seen it. Numerous times.
Within a given team, it doesn’t happen that often. The problem is when you get to multiple teams. When you start a new development cycle, the teams all get asked “what are you going to do”, and they come up with features to fill whatever amount of time is available (well, they overfill it, but you know what I mean). The problem is that there is sometimes no evaluation of the features that team X is spending their time on versus the features that team Y is spending their time on, so even if team X has some really high-value work to do and team Y has some low-value work to do, there is no load-balancing, and team X can’t get done what needs to be done. Some teams are good enough to shift people around, but it’s hard to do in many cultures.
As you move to larger orgs, the problem only gets worse. Team A1 may have customers absolutely screaming to address an important area of the product while team B2 has plans to write something that nobody really asked for, but because the planning is done individually in the orgs, the right thing does not happen. I’ve seen this happen repeatedly. I’ve had customers who have said, “You’re Microsoft, why can’t you fix <x>?”, where fixing <x> is absolutely the right thing to do, but can’t be done because the resources are out doing less important stuff.
This behavior is not to be confused with what I’ll call “New stuff bias”, which is the bias towards adding new features rather than understand what is wrong with the existing features and them. This also drives customers – and anybody who talks with customers – crazy.