Anti-patterns are essentially common ways that projects can fail and we want to avoid them as much possible but the best way to avoid them is to know – what they are? how they arises? and how to fix those?
Anti pattern is generally occurring situation in a project and they are of many kind. Anti-patterns are certain patterns in software development that is considered a bad practice.
Here I will discuss about the anti-patterns under management category. It generally revolve around people, in which project can fail due to the behavior or individuals.
Analysis Paralysis:
Usually happens when your team gets stuck in the specification phase of requirement. Clients and Product managers stuck in deciding the product requirement and direction of product is unknown. So when we are paralyzed in analysis, project end up being delayed unnecessarily.
This becomes more frustrating for developers as they wants to start work but they are afraid of choosing the wrong path. sometimes they have to sit ideal, this can be improved by following agile principle in your project and by deciding incremental releases.
Encourage Teams Collaboration
Product developed by one team could be totally different and incompatible to other team, so to avoid such inconsistencies, encourage discussion across the team if multiple teams are working in same product. It is more easier if there is not lot of office bureaucracy and management hierarchies, people can talk directly.
Vendor Lock-in
This is something when product team decide to build something for single vendor and depends fully on them, either by using technology chosen by vendors or the features according to them. If in future technology is not supported then difficult to enhance product. Eventually staffs are willing to leave the company because of its preservative nature and dealing with old technology that might outdated soon.
Over-Engineering:
Over-engineering is the practice of creating a product that is more complex than it should be. as a result product is not compatible and sometime can use lots of resources as well. Giving extra features would be confusing for users and product might gets overloaded and unstable because of over-engineering.
Gold-Plated:
Gold-plating is usually a result of the software development team putting extra features in order to impress the clients but sometimes, in un-mature team, team wants to go above and beyond their requirements. If team completes its work early then they try to impress client by adding extra features but client just ends up confusing and disappointment.
Micromanagement:
Micromanagement is common and its very real issue that many developer have to face. Micromanagement is something when someone in the management position tries to involve in every little details of the project and usually CCed on every email and tends to have talk, offer their opinion with everyone for all little change.
Micromanages wants to know what their team is doing and where the developers are at every minute. Generally this is the unwanted fear, insecurities and stress manager is taking.
Loose Cannon:
A loose cannon is a person who makes significant project decisions without consulting the rest of the team. They might also cause problems in their workplace by asserting their opinions on nearly any topic. Instead of helping to make progress, the loose cannon often impedes it. By raising small concerns and questioning every little thing. If the person makes their point often enough, others in the group will often concede just to avoid making a fuss.
Slowly, productive and openly conversing teams can turn into a bitter mess. To make things worse, the loose canon can make everyone so apathetic to issues that groupthink sets in as well.
When a loose canon makes decisions without consulting the group, they can create more work for other team members, and cause major headaches for everyone involved. This isn’t heroics, like I discussed earlier in this lesson. It’s recklessness.
There isn’t really a quick fix to the loose cannon. And the solution often depends on why the individual is acting the way they are. A loose cannon can tear through a development team and quickly derail productivity. As difficult as it can be, it’s important to deal with the behavior of a loose cannon as quickly as possible.
Intellectual Violence:
Intellectual violence is as much about the developer’s inner world as any of the other anti-patterns I’ve described. Intellectual Violence can be used by loose cannons, making meetings unbearable. Intellectual Violence is a situation where a person uses their advanced knowledge in an area to intimidate others. This might manifest itself as a developer talking down to team members when they ask questions about a technology they aren’t familiar with.
As you might imagine, behaviors like this can cause team members to feel unappreciated and unimportant. Because of this, your team’s morale can drop, and you can be missing out on some key ideas, or at least clarifications.
To address an intellectual violence problem, try talking to the individual in private. Ask them to reflect on how their behavior affects others on the team.
So what you need to do as a manager is really understand different people’s personalities. And understand how you can break through some of those silos and the trust of your team members so that they can understand that knowledge and information when shared is really when it’s going to be most valued. To allow your team and your resources to really trust each other and create that safe environment so they will share. And so what you want out of your team is to ensure and enhance sort of that understanding of each other’s personalities so that they feel comfortable in a safe environment.
