A Chit-chat of a Scrum Master and developers over a cup of tea.
Have you ever thought, what if you and you were doing it all wrong?
If yes, then this article is for you.
It has been a while since I wanted to make another article about managing developers. However, ideas were very blurry and sometimes, as we all know the theoretical knowledge conflicts with the real world. Moreover, we do see that the best practices fail to work in our companies, and at the end of the day, we face serious management problems.
After long consideration, I got this idea of not writing ideas from my experience, taken from various sources or acquired as a result of discussing with PMs/SM, but talking to the developers themselves to understand issues from their perspectives.
Not to bore them, ( you know how much they hate to be bothered) I asked them the following questions:
- If you left your personal wishes aside and brought only your professional “ego” forward, what would you want to change in the flow used by the companies you’ve worked in?
- What do you think has most disturbed you from coding more error-less in the overall process?
- What would make you more productive?
One crucial issue should be mentioned that the ideas provided in the article are collected from various developers, who’s names are changed btw, and who work in different companies. Fortunately enough, I have a large circle of developer friends who were glad to help me. Hence these ideas that should not interfere in your trust of these or that company I am associated with.
So let’s deep-dive in our chit-chatting.
Mark, a developer who worked in different companies and got his ideas based on his experience:
Firstly, I think it is essential for the team to have the right size, i.e. not very small and very large so that it does not mix up the flows.
Secondly, The coding style standards should be kept so that to prevent the mess in the code, and code reviews should be held correspondingly.
Thirdly, roles should be defined in the team to avoid misunderstandings.
Fourthly, the tasks should be informative enough to complete them even when the developer is not very much aware of its business value.
Last but not least, the most important thing is having a pleasant atmosphere in the team.
Daniel- an experienced software engineer who cares about the company’s achievements as a whole.
The most important thing is that taking into account developers’ opinions about how the wanted changes might affect the product, that, being concentrated on their profits, some companies fail to do.
Sometimes all that managers care about is being able to push the development team to do what the partner wants so that they keep them attached and showing off “how cool managers they are”.
And I am not implying that the developers are always right as sometimes we fail too. However, by making trade-offs, the business will get its benefits and provide its best value and not just multiple functionalities that have a horrifying coding background.
Annie, a girl in tech who knows what a great team looks like
When I compare the companies I worked in, I realize that the thing that makes me more productive is having a great team leader who empowers the other team members so much that they want to work harder. This encourages the team and keeps motivated consistently, especially when the work done is being appreciated and not taken for granted.
The next issue is code review that not only makes your code more “bug-less” but also grows you professionally as other professionals are carrying it out.
Another thing that is worth mentioning is keeping the meetings as short as possible, even the sprint plannings that take a tremendous amount of time.
And lastly, it is crucially important that the team members truly love the projects they are working on. So, before applying to the job make sure that your company offers the projects that appeal to you.
John, an engineer who makes overviews of several companies
In my opinion, the most problematic issue in our companies is the constant urgency. Businesses want everything done in the shortest timescales that deteriorate the quality of the codes. Hence, a logical amount of time should be spent on coding.
Also, It is highly essential to follow the defined project architecture. In this case, minor changes are acceptable, but if the client wants some global parameter to be changed in a rush, without giving time for rewriting, this crushes everything.
Moreover, in some companies managers sometimes reduce estimations provided by the development team to tickle the client. And this is affecting not only on a technical level but also the internal relationships of the team.
The next issue is having appropriate documentation of the project so that the developer is not lost in finding answers to his/her questions.
Another not less significant aspect is to have well-defined tasks and bugs that have all the user cases included. Sometimes you can see that the bug and the feature are overlapping with one another and you can be confused whether it is a bug or a new feature, as it was not defined well enough by PMs/POs in the tasks before.
What comes to the meetings, I would say, sometimes people lose the targets of the meetings, and everything becomes a mess. As a result, people start to complain, especially when not relevant devs are in the room too.
Erik- senior ML engineer
The first point to mention is to have code reviews in the team to reduce bugs.
The next thing is concentrating on just one task, not multiple ones simultaneously when you are always context switching.
Another issue for the companies is to differ “upworking” from a stable company workflow. When you are representing a product, you should take your time and develop to the best of your capability. Here it is noteworthy to mention that each year global refactoring should be done to optimize the code and discuss its changes, besides small refactoring processes.
The last and the most crucial point is having a knowledgeable team lead, who has global programming as well as organizing skills.
…Jack, a software engineer who has recently changed his workplace.
Look, when the reason I am currently far more productive is that there is always something to do, and I am working more than I should, and I am not complaining about it. And also we always know what the next thing we are going to do as we have several sprints groomed beforehand is. And we still have the ongoing sprint full of work that sometimes is hard to complete. And to finalize the feedback, it is extremely important that only sprint tasks are fixed, and nothing changes during the sprint as compared with other companies.
Interesting right? I was surprised by their eagerness to provide such detailed feedback, and I was not expecting to have such a load of information that might not fit into just one article. Hence, to conclude you can see below the summary of the feedbacks taken from both the people mentioned in the article and the ones who also took part in the interview:
In short, what if we stop bureaucracy for a while and hear what they say. It might change lives, might it not?
