What standards, guides, etc. do you settle before starting to build a project with a small team?

The first thing you should do is establish practices that the group likes. How you name your variables, how you organize your code, how you style it, how you split the files, essentialy everything regarding "writing code" and its conventions. Find the common ground the team agrees upon so that everyone is on the same page and you all follow the same patterns when writing code. This alone will help tremendously.

We have good experiences with paper prototyping when requirements are unclear and the team is still fresh. People can get to know each other, rules can be settled, first design ideas can be put into the product/service and stakes are low so there is also low stress and high creativity. In that phase you can already learn the characters of the people and take this into account when later stakes become high and coding starts to get serious.

Naming convention, programming paradigms (functional, object, or procedural), software design patterns, simple coding rules and realistic deadlines plays a lot in gettting things done in programming and software development. A programming project is not necessarily to challenge, (as some programmers like I was did think)) but to allow to explore your inner posssibility of problem solving techniques and purpose-driven solution within laid-out schedule, resources and the team available.

I think collaboration expectations come first — code reviews, etc. Since the project really will have a clear beginning and end (as far as we know, right?) make sure everyone knows that you're not going to approach this the same way Microsoft would.

With code, set some standards and patterns you know you have a good idea about, but let everybody know it's normal that you can't figure out everything upfront. You'll need to figure out what works for you as you go. Setting up a time to touch base on patterns that are and aren't working on a regular cadence will help.

Good luck! I guarantee you're doing better than you realize. The truly disorganized process wouldn't even be lead by someone thinking about these things at all.

If there is an existing style guide or set of conventions someone else has established in the tech you're working with, you may consider using that as the basis for your approach. That might make the team more bought in and help you make decisions.

But make sure to set expectations that it's not sacred and you may need to break patterns pragmatically.

It might seem silly, but I really like seeing if the team is up to having a team name and theme. The team theme is surprisingly useful when writing test code, because instead of boring personas like personA and personB, you can write code for, say, mario and peach instead. Really helps with creating a sense of identity and injecting a little bit of fun.

Love how well thought out this is! After reading through the comments before I scheduled a meeting with the team and I realized that having clarity really brought the team together.

It was like day and night. Thank you for this!