Blog > Anti-Pattern and Management
Why Anti-Pattern and Management are Important
Anti-patterns happen where you don’t even expect that. Based on my personal experiences, most of the time when companies expand quickly or are acquired by a big corporation, the chance just gets higher. These changes sometimes come with a change in pattern and management and engineering team. There are patterns for the team that can connect to for a long time and changes that will require preparations that will not happen in a few official meetings.
How anti-pattern and management make changes:
Even though there might be written rules and processes, it’s accepted by the new management. However, there is a chance that is being overlooked and not being followed exactly as it should be. This can cause terms called “process clash”.
Process clashes can also happen as divergent goals among the new engineering team members. The newly added team members (due to acquisition or merger). Most of the time has more information than the existing group is not aware of. This is because in most cases the new team will have to learn about the product. And after a while transition, the existing group to a new one or just feel superior since added with upper hand management.
In this case, the divergent goals of anti-patterns management can alter the elicitation process that guides ongoing projects. The requirements will have different meanings for the different teams since the understanding of how to achieve them will be different.
However, avoiding mushroom management can help to reduce the chance of anti-patterns happening during transition or taking over a new company or project. Educating the team for changes, reviewing the existing process carefully, and bringing the issues to the attention of everyone if there are any, rather than assuming a group is not simply understanding or has no need to understand.
Here are some QA’s that will be beneficial to many of the dysfunctions explained above.
Should a request to add or change features be anonymous?
Creating a safe environment for discussion and team collaboration is the responsibility of good management. Hiding the information or identity of the source must be dispiriting while planning the company process and metrics. Actively seeking and inviting requirement information throughout the project lifecycle is an essential aspect of requirement management. Hiding the identity can devalue the base of the idea. In most cases, trust in the knowledge of the person can expedite the process of analyzing and validating the features or ideas.
Also, knowing the identity of the person is one of the ways that people can keep growing in a company by performing well. If there is no identity, more junk, and unthoughtful ideas also can get in line.
How could metrics abuse begin to develop in an organization?
Incompetence: Failure to understand the difference between causality and correlation, misinterpreting indirect measures, underestimating the effect of a measurement program. Malice: selecting metrics that support or decry a particular position based upon a personal agenda.
What is a typical example of a process clash?
A team planned and designed an idea into a product. While the product was in the development stage a new partner with more capital joined the company. The new team learned about the product quickly (maybe too quickly) and accept planning and structure. However, their idea about how the product and company will operate apparently was different from the original plan. Since they were not technical and could not understand the meaning of complex processes.
After a while, the process clash occurred since the new team was pushing product and business processes in their own way while the product was not supporting their ideas as well as a roadmap. Notice the company did not have proper guidelines or documentation to assist the new people joining the company. To help them understand the product and the roadmap in a more detailed way. So everyone who was joining was following their own rules to push the company forward.
What is a typical example of metrics abuse?
The engineering team is causing constant delays in deliveries. So the management sets some kind of rewards for engineers who speed up the process and finish more tasks they address monthly. However, by missing measuring the quality of tasks done as metrics. It’s going to be compulsory very soon that the pulled-in completed tasks just too fast and the bug report is spiking by customers. This is a clear example of metrics abuse by our engineers.
A typical example of divergent goals
A newly designed product is supposed to target a large size audience and use data analytics and complex event processing (CEP) tools to build the foundation of the system that needed to be injected with a huge amount of user behavior data. However, management is focusing on individual acquisition which would take years to collect the data systems needed. And hence data would be expired by then. In fact, the company must do a huge amount of advertising to flood the system with data. But the people in charge will suggest starting using personal social media networks and etc.
What a joke! I’ve personally experienced this issue and saw how the invested money and efforts were wasted rather than investing it in a more practical way for user acquisition.
How can CMMI use to identify and reconcile process clashes?
Capability Maturity Model Integration (CMMI) describes the principles and practices underlying process maturity. Process clash happens when there is more than one process happening in parallel to reach a goal. CMMI can enforce and use high and low-level requirements to identify these conflicts in the process. And align them in one unique and solid path that must adopt and used by the system and those who work for or manage the system.
Author: Cyrus Akbarpour
Copyright Silicon Valley Cloud IT, LLC.