There is a lot to discuss about the how and why of code. In some ways, that’s good too. But beyond that, you want your team to come to an agreement and then stick to the rules. Examples are formatting, indentation, naming and length of methods, functions and files. In most development environments you can enforce code standards, such as Rubocop in Ruby on Rails projects.

Your team needs to know if everything will still work after a change. This can only be achieved by a high level of test coverage. And the tests must also run after every change and before every deployment. Make sure that you have a CI - setup and that your team has enough time and love in tests. The rule: If there is no test, it is broken.

Yes, you can do everything yourself. And if your team is big and capable enough, it can be a good idea. But for smaller and agile teams, the recommendation is: use a cloud vendor like Heroku and don’t spend your time maintaining systems .

Pair coding is as healthy as yoga and fresh air. It solves many problems at once: Your team comes together, more than one person knows the code, mistakes are avoided early on and all this is positively charged. Allow pair coding and make sure that it is done.

Code review is necessary ! Firstly, everyone makes mistakes and secondly, everyone else can find them . Later, and after pair coding, it is the only place where everything can be coordinated again. Make sure that no code is deployed that has not been read by at least one person, and better still by several people together.

Code becomes obsolete. This increases complexity, costs, development time and team dissatisfaction. Schedule refactoring , right from the start! Once every second week is a good practice. In case you work with Scrum, then a certain amount of story points per sprint.

Make sure that knowledge is made available. That starts with the README: Everything that is necessary to run the application must be documented . Establish a developer blog and give the team room to talk about what they have learned.

Don’t delude yourself: only with pressure and deadlines software is not developed. Arrange deadlines, that’s healthy! But keep them soft and design your process in such a way that your team knows: Quality and functionality are in the foreground.

First, write down your user stories as good and foolproof as possible. Then, establish in your team the realization that there is no perfect story. You can expect your developers to complete and correct an incomplete or incorrect task description. Allow changes and make sure they come from the team.

Project managers love it when each task is assigned to a person. So you can always ask someone what the current status is… Don’t do that. Ask the team! Make it clear to the team that EVERYONE is responsible for making every sprint or release a success. As a result, you will be able to deal with most of the interpersonal problems in the team.