Background
I am a software developer in a small team of half a dozen people. I am the member that has joined most recently (around 18 months) but am somewhat older than most of my colleagues.
We work for a prestigious German brand with international reach (from another Western country) and our (new but successful) project is used in multiple countries, so there is pressure to deliver a reliable, quality product. There is some time pressure to add on more functionality, ASAP.
We have quite an informal structure and flat management hierarchy and are very much self-directed. We get along well with the German management we work with directly - there may be the occasional cultural differences, but manage to resolve them as it is not a surprise. Our team itself also consists of different ethnicities/cultures, and although we use English as a lingua franca, only 1 colleague is a native English speaker.
We work mostly from home, with some office time each month. We are fairly stereotypical introverted software developers. While at the office, we will socialize some, but only about superficial everyday stuff: sport, news events, weather, that sort of thing. Almost never regarding deeper theoretical or philosophical underpinnings of our trade.
Problem
Individuals in a team have widely varying backgrounds regarding training, prior experience, interests, knowledge, how we look at problems and come up with solutions. In practice that means the way we do our work has not a unified style: everyone has a different style with can often be discerned just from reading the program code (every unit may contain contributions from multiple people added at various times). In software there are many ways of working, philosophies, methodologies, paradigms, or whatever you want to call them - let's call it the work culture of the team. (This may include things like an Agile methodology, Clean Code and code formatting conventions, Object Oriented and Functional Programming, all the way up to architectural decisions).
The problem is that we as a team are not "all on the same page" regarding many of these issues. As an example: Colleague A has read Clean Code and follows it slavishly, colleague B has read it but has some (what she terms "common sense") reservations regarding some parts, but still applies others, while colleague C has never heard of it. Another example: Colleague D still does everything in indexed for loops and builds messages with string concatenation, while colleague E keeps up with developments and uses more modern, clear and concise features from later revisions of the programming language like streams iterators and string interpolation (sorry to non-technical readers for the technical terms, they are just for illustration). In a recent discussion between me and a colleague we agreed that new additions should follow "the pattern" but could not come to an agreement at what exactly "the pattern" is.
The net result, some of the team members feel, is that the software becomes harder to maintain and more prone to errors as time goes by, since there is no "unified culture" how to approach the work. The fear is it will take longer and longer to add features and fix bugs, because reading and understanding someone else's intentions takes longer. But, we have been warned that things will speed up as more users use the project.
As well-paid professionals, our employer has the (often unspoken) expectation that we do work professionally and according to good industry practices/standards (unfortunately, there are so many of them these days (<- irony), none of which are followed that well to my experience).
I understand that realistically a single person, especially not with leadership authority, won't change everything in one fell swoop. Step-by-step influence in the right direction may be the only possible way and certainly not a certainty.
What has been tried
- This team follows an Agile methodology, which in theory includes some "ceremonies" where team self-reflection and self-correction ("without fear of retribution") should be part of the weekly cycle. In practice we tend to gloss over those occasions so as to be able to get back to more urgent, or at least more interesting, work. Under the topic of "what can be improved" some great suggestions were put forward and actions initiated, but it then petered out/silently disappeared through negligence during day-to-day work.
- There is opportunity for training sessions, where in the past, ways have been presented on how to effectively apply some techniques that (should) form part of our work culture. These have been received enthusiastically, but then ignored during day-to-day work.
- Because of the above, various team members that do feel a change is needed, are now hesitant to suggest anything further and "just do their job".
- I have - I feel - a good rapport with one other colleague, we have worked together well on aspects on some occasions, and often share frustrations with what is wrong - but even among us we don't instantly agree on everything and it takes literally hours to discuss differences, without necessarily coming to a conclusion or compromise (language and culture differences may come into play). I shudder when I multiply that effort for the other team members. Talking and convincing is not a strong point of any of us.
- I get the feeling that people in general are resistant to change. It is easier to continue with "business as usual", it is a comfort zone and our project is successful despite it. People often don't see the big picture of the forest, how things will likely tend to go in future, when they see the single trees of the work of immediate concern in front of them.
Question
So how does a single person, not necessarily with good political convincing skills or reputation as an expert, approach a group and effect consolidation of differing opinions? How do we come up with "the pattern" and get everyone to follow it, and formalize it so that newcomers are also able to follow it - without reinventing the wheel where others have written tomes on software development? Note that in many cases, I don't care whether methodology A or B is followed, as long as the group can agree on a choice, and somehow stick to it.
Related
- How to tell my team that they are doing their work in the wrong / poor way? (closed) seems superficially like a similar question, but the specifics differ and so I feel the answers don't apply.
