One referred to the team consisting of one manager plus one team member. Causing the team member issues as there was no way to validate thinking or to validate output (if anyone knows the post let me know)
I've experienced attempting to run Scrum teams with an off-shore company whose resourcing model was flexible. Meaning that our team composition was fluid over time and there was competition between projects to get an individuals time on the project.
Better yet, do we have names for these anti-patterns?
The people who make technical decisions (which we refer to as Architects) stop doing real technical work once they become Architects. So over time they drift away from the reality of the things they're working on, so we keep having these decisions that don't make sense at all. And these people almost never quit since they make so much money, so it's rare that we promote someone who will then go on to have sane decisions for about 1-2 years until they drift away from reality like the others.
We promoted a CFO to CEO, so now every employee, including R&D is just a cog with a cost and can totally be replaced by another random person in a 12h timezone difference.
Another is gold plating, where more requirements get added on even after the initial requirements have been met. A few years ago I worked at a startup that made a dashboard for small businesses to manage their online business listings (Yelp, Facebook, Google, etc). They could see all reviews across sites, reply, update info, etc. So product comes up with a new feature to create offers/coupons and post them on sites. We implement all the requirements for an MVP which was creating and posting immediately. Then on the eve of releasing it they add a new requirement to schedule posts (the engineers all objected but were overruled). That led to complexity with timezones that added an additional 2 months of development and bug fixes. In the end, analytics showed that only 2% of users scheduled posts, the other 98% sent immediately.
For example, we have an extremely outdated code base that's full of security and performance issues which we can't fix because doing so "isn't MVP". Unless something becomes a critical issue such as a server going down we're effectively not allowed to fix anything. We also add to tech debt constantly because we always have to build features in the quickest dirtiest way possible, again because "MVP".
Thankfully I'm a contractor and I doubt I'll be there much longer. While this is one of the worst examples I've known of a company that doesn't trust it's engineers enough to build things the best way, it is quite a common pattern I've noticed among larger companies which aren't primarily software companies.
Result = overspend on the wrong things, managed by an inadequate team...
The business problem should be solved by the business, then IT should transform the business system/process into a technical system by following well defined requirements.
This is the earlier post, BTW: https://news.ycombinator.com/item?id=23964905
Mushroom management: Managers keep the developers in the dark like mushrooms. Often consulting companies afraid of being undercut by their developers. It adds communication overhead and "telephone game" communication between the managers and developers, and very often devs don't understand why something is to be done a certain way and are less motivated or cut the corners.
2nd System syndrome: The first system someone designs is underengineered. The second one is often overengineered, which is worse than underengineering. Worst case is making such a person team lead. This isn't just engineering, but also management, sales, etc, as well.
Bikeshedding: If an objective seems simple enough, nobody can agree to it, because it's within the Dunning-Kruger zone of people who want input.
Duck decoy: Middle management feels like they have to give input and criticize to be useful. An engineer can set up a "duck" feature (search for Battle Chess) which is easy to criticize and easy to remove, to appease such managers.
Friendly fire: For some reason, not enough resources are allocated to a project. Often time/tight deadlines. Team A blames Team B for not fulfilling their role. Team B blames Team A later. Blaming often freezes progress as they have to make meetings to explain the situation and possible solutions and negotiate adjustments to the schedule/budget. This can lead to a deadlock. A common option is to bring in a consultant then blame the consultant. That way only two teams are frozen in place, while the third team makes progress unhindered. The consultant will also blame the in-house teams, but their role is to keep it minimum and buy more time.
Budgeting as needed: A budget increases and decreases according to its needs. This often results in departments requesting extra computers, resources, printer cartridges, etc to finish a budget so that their budget isn't reduced next year.
This creates an unfortunate positive feedback loop.
* Expecting strong performers to carry the weak without requiring the latter to step up their game.
* Requiring employee's to collect data (e.g. time-use tracking) that is never reviewed or analyzed.
Business managers at some point began thinking it was their job to destroy the individual professional. It is ridiculous, nothing gets done and no one can do anything. Imagine if a surgeon had to have a live feed of the operation and the entire hospital watched and told the surgeon they were doing it wrong. Imagine if the entire law firm came to the courthouse to sit behind the desk at a hearing, no one was in charge, everyone just spoke when they wanted, and every action was heavily attacked.
And something HN doesn't like to talk about: every hire has to be some sort of social case: handicapped, LGBTQ, under-represented minority, political refugee, or other.
75% of chief diversity officers are black women. There are virtually no other races represented.
Just some stupid stuff that started happening a few years ago.