Anti-Patterns in Agile Product Development — Part V
If you have read the previous four episodes on anti-patterns in agile product development, I am glad that you have been with me, and while thanking you, I offer you the fifth (last) part.
In this part of the “Anti-Patterns” series, we will address issues related to the software development product team members.
Loose Cannon:
I didn’t find an excellent Persian translation for Loose Cannon; I preferred to translate it instead of the loose war ball, the Los war ball;)
You’ve probably had the experience that a developer can make important decisions that affect the whole product without consulting the software team members.
They are not in the position of Tech Lead’s main decision-maker, and they do not make their own decisions with anyone, and we will notice the changes made by them when the work is over.
They also try to get their opinion on everything (this is different from consulting). Suppose the other team members express their views in the right places. As a result, they cause the group’s growth, the culture of commentary, and the conclusion, not to make a fuss to express their opinion. Such a person creates another anti-pattern, which is GroupThink.
To solve this counter-model, if our real goal is to solve the problem, not to eliminate it, we must begin to find the root of the problem and ask ourselves why this person behaves this way. Ultimately, the answer to this question lies in the soft abilities of each team member, as well as their interest in solving problems, not eliminating the pain.
We also need to confront him about our behavior and its outcome. He must understand the destructive result of his behavior; the teachings of emotional intelligence tell us that if people do destructive behaviors, in most cases, they think they are doing helpful behavior and are not aware of the detrimental effects at all. I do not have.
If we can’t solve this problem with his help, we will soon see the adverse effects on team performance and product success. Finally, with the help of decision-makers, it may be necessary to decide the organizational level to address this issue, which can be related to teamwork training, emotional intelligence, behaviorism, etc.
Unfortunately, some companies and decision-makers choose the easiest and fastest way to do this and remove that person if this does not help the growth of the organization and that person. To achieve a win-win outcome, the organization must finally learn how to deal with different personalities, each with its counter-patterns.
Intellectual Violence:
Intellectual violence is another exciting topic in software product development teams. A developer imposes his opinion on the whole team, relying on his more profound knowledge in one area. He does this by destroying other commenting people, making the questions asked seem silly, insulting people’s personalities, etc.
If you use him for interviews to hire new developers, you’ll find that he destroys the interviewee’s confidence and makes him look stupid by asking confusing and bizarre questions. Unfortunately, I have to say. These people experience “pleasure” in their minds (based on the teachings of emotional intelligence).
With the presence of these people, you will see a decrease in the team’s morale, the formality of the feedback culture, and the loss of valuable ideas from other team members.
To solve this counter-pattern, in addition to what I explained in the previous counter-pattern, we need to implement policies at the team level, and the most important of them is that everyone has the right to ask questions, and no one can ask that question. Address “stupid.”
Everyone has the right to ask questions, and no one can call that question “stupid.”
Open team culture and freedom of expression can also exert a positive atmosphere over the effects of negative counter-patterns.
Conclusion:
Although I know you’ve come to some conclusions by reading this series, let’s conclude. The important thing has always been to use my critical method to find counter-patterns, to look for counter-patterns within myself to see them as soon as possible.
At the individual level, I have allowed all my friends and colleagues to give feedback about myself, my behavior, my way of working, and so on, and I have welcomed their input with open arms.
Open culture can be implemented at any level. If people resist this issue on a personal level, the top-down efforts of the organization will not work, and the meetings and feedback will all be formal.
Also, note that feedback, unlike what is left between us, is not only used in negative cases but is entirely positive, whether the input is concerning the negative or the positive. Open culture is a team that starts with the right words and accepts feedback instead of compliments and confrontations.
End of the fifth episode
Feel free to comment below. Please hit that clap button to help others find it if you enjoyed this article.
