3 ms·
Oh god, this reminds me of a company I left where management would regularly talk about "swarming" a problem. They'd form these temporary "feature teams", where
by overgard 11y ago
Oh god, this reminds me of a company I left where management would regularly talk about "swarming" a problem. They'd form these temporary "feature teams", where they'd assign more programmers than were needed to a problem, while other important concerns were left abandoned. From a management optics standpoint, it let them tell the executives "Look how serious we are about this feature!" From a practical standpoint it was pretty much a disaster. You would end up with one person actually qualified to do the work being dragged in five directions by trying to manage five other people who were well meaning, but had no idea what to do. It ended up with one or two people being stressed out and overworked, and the rest of the team being mostly idle.
I know this isn't exactly the same thing, and I try to keep an open mind on these things, but you could just as easily call this "programming by committee". We all know how great anything described by "X by committee" turns out.
There's nothing wrong with gathering a few people together to work on a thorny problem, but that sort of gathering has to happen organically. When people trying to sell management books turn this sort of thing into a buzzword, it just ends up being cluelessly applied by some starry eyed junior manager that has found a shiny new hammer and the world looks like nails to him.
- JustSomeNobody 11y agoSounds to me like they tried to apply "put out fires" management style to new features. Sadly, most managers are of the wait until there's a fire type. These are not really managers except in title as they simply are not managing anything.
- overgard 11y agoYep, that's a pretty apt description. The sad thing is almost all these fires were avoidable if they had let forward thinking engineers work on problems we all knew were upcoming, but weren't the emergency of the week. Unfortunately, the dedication to "agile" seemed to mean that anything outside the scope of the next two weeks pretty much didn't exist, and if you tried to do anything that wasn't in the "backlog" you were some sort of rogue cowboy. (Even if the backlog was empty!) Fundamentally, the problem was trust -- the management didn't trust the engineers, so they micromanaged them poorly while invoking "agile" to make heavy management somehow seem like a populist movement for the "team". And because the team was micromanaged and not trusted, motivation was low and the output was poor, which just made the problems worse. (Not surprisingly: the company recently just laid off the entire staff)
- JustSomeNobody 11y agoThis is a strong reason why I do not believe engineering should be subordinate to management.
- danielbryantuk 11y agoI think this reply thread is confusing the specific, i.e. the technique of 'mobbing', with the general, i.e. the (mis-management) approach to fixing issues with 'all hands to the pumps'. The only thing the Unruly team is dogmatic about is delivering valuable software. The techniques they talk about are simply this - techniques. In my work as a consultant there is rarely a 'one-size fits all' technique to developing a feature, but knowledge of several approaches is very valuable. This is the purpose of the article - to allow you to consider the addition of 'mobbing' to your existing approaches of single development and pairing
- japhyr 11y agoThat sounds like a bad version of the group projects many of us hated in school. As a teacher I never assign group projects for their own sake. If something makes more sense being done in a group, we do that. If it's better done by individuals, we work alone and share our results.
- dmcg 11y agoThe Unruly mob is very much a ground-up movement. These guys mob when it suits them - they tried it as an experiment and found that it works for them.