4 ms·
Yep, 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
by overgard 11y ago
Yep, 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