I would recommend the following: Assume you can't get the process right to begin with. Therefore, the most important piece of your process is something that lets you modify it as you go.
Retrospective meetings (where the topic is how the work is getting done, not what is getting done) are a standard and useful way to do this (assuming the results lead to actionable change). The frequency of the retros themselves should be part of your discussion (pick something to start with ("every 2 weeks") and periodically decide if that's the right cadence). Length of sprints, styles of coding, amount of pairing, etc. -- all of these are variable based on the experience of the team and the problem being tackled. Pick reasonable defaults to start with and regularly ask yourselves if those defaults make sense given your experiences.
I could say more, but the above is the base minimum I've found for success across different teams, different problems, different companies. Cheers.
Retrospective meetings (where the topic is how the work is getting done, not what is getting done) are a standard and useful way to do this (assuming the results lead to actionable change). The frequency of the retros themselves should be part of your discussion (pick something to start with ("every 2 weeks") and periodically decide if that's the right cadence). Length of sprints, styles of coding, amount of pairing, etc. -- all of these are variable based on the experience of the team and the problem being tackled. Pick reasonable defaults to start with and regularly ask yourselves if those defaults make sense given your experiences.
I could say more, but the above is the base minimum I've found for success across different teams, different problems, different companies. Cheers.