Anti patterns in software organisations
In software organisations, we can observe a multitude of things happening. Some support software engineering efforts, and some rather disrupting productivity. While many of those are in common over multiple organisations it is impossible to go into every single one of those.
I think it would be very easy to write many articles alone on why your scrum is broken. Nevertheless, I want to make an effort and highlight some I want you to look out for.
If you are interested in anti patterns around software development in other areas, please check out my other stories.
The anti patterns listed here will be a mixture of organisational, managerial and leadership observations.
Anti patterns
Body ballooning
Why stay a ruler of a small kingdom if you could easily rule a bigger one? That or different thoughts might be what drives some managers to do body ballooning. In organisations where power and influence are heavily determined by the number of people, a manager is supervising that might be what you can find.
Observing that anti pattern, supervisors don’t just hire for nothing they also tend to go for more labour-intensive solutions to problems, as well as choosing inefficient techniques over efficient ones.
As a result, they manage to justify the need for more bodies and ‘balloon’ their little kingdom.
Empire building
While body ballooning can be a tool to do that, the signature of this anti pattern is rather the extension of a position of power without comprehensible measures for other.
Other observations to look out for can be discrediting people, mobbing, or further activities that aim at manifesting the status quo and strengthening the own position.
You will detect strategic avoidance of responsibility and all traces that could lead to blocking decisions would be spirited off carefully, so nobody can find them. In return, that person can not be held accountable for mistakes and delegate failures down the chain. The chosen scapegoat is often somebody who actually implemented one of those non-traceable decisions like a project manager or software engineer.
Warm body
A warm body is a software engineer that has very little, doubtful to no contribution to a code base or software project.
That can often happen when a project under time pressure is staffed to address complex or time-consuming parts of that project. With complex software products and non-trivial architecture the temptation to fix things with a larger number of engineers leads easily to increased costs without the wanted benefit of speed, but decay in quality and velocity of the project.
Team sizes should never be driven by architecture or design. Resources are not a good fix for bad design decisions, neither hardware nor the resources people can provide.
Single head of knowledge
The one person who is the only one knowing anything about a tool or piece of software throughout the whole organisation.
Obviously, once that person leaves the company you will be in big trouble. She takes the knowledge with her. The company literally bleeds out.
The most interesting part though is, how that problem is being created. It is a clear symptom of insufficient knowledge management, collaboration or of a person who purposefully put herself in that position to maintain a certain aspect of non-interchangeability.
Activities like pair programming, mob programming, and mob testing can help mitigate that risk. Everything that brings people together. From pull requests to refinement sessions, bring people and their knowledge together to prevent a single head of knowledge.
Mushroom management
Like a good mushroom, with mushroom management employees are kept uninformed and in the dark. Communication channels between management and everybody else are either not working well or sealed off on purpose.
People are kept in the dark and fed bullshit. In the end, an employee has no chance of understanding the general state of the company and the work seems disconnected from any purpose.
This whole analogy also leads to not giving anything about expert empowerment. Management is there for a reason and that is decision-making. Employees should be happy if they are informed about decisions.
The ultimate culmination and success of that management style are when management has no idea about their employees, skillsets and traits. Resources go in, nothing comes out and the comparison of management people are drawing is that of a black hole.
Yet another meeting will solve it
That’s what that meeting is called, that is scheduled when something is delayed. Resulting in delaying even further, because that meeting is needed.
We all have seen it happen. Problems with schedules and timelines? Let’s solve it by adding another meeting to the timetable. What a show.
Net negative producing programmer
That is simply an engineer that is neither performant nor productive. That is the one person once removed increases productivity more than adding a productive one.
While removing those people is a tough response, it also is a sign to the organisation about hiring and training practices that need critical auditing.
Management by numbers
Similar to painting by the numbers, management by the numbers puts too high an emphasis on numbers and quantitative management. The high focus on costs leads to leaving other factors like quality and speed behind.
Engineers quickly are seen as a commodity and exchangeable goods. It completely disregards employee motivation or fluctuation and will end in higher costs in the long-term as opposed to a short-term investment in this management method.
Engineers are likely to be perceived as an exchangeable resource for a production line that produces software. A software factory. Which in return disregards the big creative and artistic part of creating software which comes with autonomy and freedom to create and design.
Fear of success
Think of a football team that is only defending their own box, and not breaking a sweat thinking about attacking. That is like being a team with a prevailing atmosphere of fear.
Management makes sure that this atmosphere exists. We know very well, that constructive creation has no place in a culture of fear. People start to assume failure no matter the quality of their work because it is probably not good anyways in their eyes.
Companies trapped in fear appear paralysed. Even if success can be witnessed by any means, people quickly draw the conclusion that it will be viewed as suspicious by peers. Good employees can be seen as a danger because they threaten the position of their supervisors.
Typical things to witness: “Let’s do that in secret. I know it is the best solution, but I don’t want the boss to know”
Faux system architects
Management often realises that there is a notable difference between the capabilities of the engineers. They often detect engineers that appear to have overwhelmingly good capabilities in dealing with people, especially with people having below-average qualifications.
That person then gets promoted and put in office, garnished with high expectations and is often called an architect or some different technical supervisor.
When those people are chosen specialists' opinions are disregarded and management decides by themselves, despite the fact that they are incapable of making a well-informed decision.
This results in the faux system architect being set up for failure and also leaving other engineers, more suited ones, back wondering if there is actually any chance of useful promotion at all.
Crocodile management
That’s a part-time project manager. That person can easily be compared to a crocodile, because he only surfaces, opens its chaw, and descents again. Only taking care of tiny details that haven’t been taken care of by other members of the project team.
Programmer interrupt
E-mail, Slack, questions, meetings, quickly here, quickly there. Anything you can think of, that keeps an engineer from working. There are studies that state, that every interruption takes 10–15 minutes until focus is back to keep on working efficiently, while only one two-hour block to work without interruption is available per day.
The higher mental focus is for the engineer, the more expensive interruption gets. Typically you see developers escaping into “tunnels” by putting on headphones, disabling notifications for messages and e-mails, muting their mobile phones and many things more.
While I am sure there are many more anti patterns around. I hope that collection helps you already working in a more efficient way with the engineers around you.
