In my transition from collaborator to team leader I’ve figured out a few techniques that I find effective. What follows are what I’ve found to be some effective practices for running a software development team (this is for a purely dev team–I have some thoughts on QA as well, which I will address at a later date).
- Everyone has their own fork of the code repository (eg: How to fork on GitHub).
- Have a good branching scheme.
- Have a continuous integration system (like Jenkins)–fire off a new build every time a commit is merged to the main repository’s develop branch.
- Configure your compiler settings to treat warnings as errors.
- Use Test-Driven Development, or else waste time chasing down random bugs whenever someone introduces a change.
- On a team of 2, each developer should review the others’ commits and constantly check each others’ work (see: Pair Programming).
- On a team of 4 or more, a lead developer should be responsible for reviewing commits, running the latest build and doing basic verification of features in progress.
- The lead helps coordinate and unblock developers.
- The lead helps plan and schedule the user stories with the product owner and scrum master.
- The lead relies on the team to come up with designs, but provides guidance on the design–generally with an eye toward not over-designing, doing the minimum necessary without cutting corners.
- A user story is not complete without unit tests.
- When you find a bug, fix it and add a unit test to check it.
There is undoubtedly more than this, and I hope to expand on a few of these points in the future. As you move into a lead position your job is less about writing all the code and more about coordinating the code that others generate. I still write some code, but at least half my time is taken by supervising others’ code–making sure there is a cohesive design and that the pieces fit together. It is a different sort of problem than writing the code, but it is a fun challenge.

