Agile for a small team

This is the situation: the team is very small, just 3 people in the engineering department. It’s a young startup in a early stage with a very tight budget and the engineering team is building the product as a side project, aka in the spare time.

If it wasn’t enough the team is spread in different cities, so being in the same room frequently is impossible. It’s pretty obvious that the team cannot follow a regular scrum approach to development.

But what can we do to maximise the productivity ?

Always keep in mind that quality of software is not a variable, you can negotiate time, resources and features, you should never negotiate quality. This is expecially true when you’re building your core business.

Resources as I mentioned before are very tight so it’s not a variable too. What we can work on is time and features. And since we’re talking about spare time, aka time stolen from our kids and families, the biggest variable we can work on is features. I’ve covered how to slim the features list in my previous post.

But we can also try to work on the process. The team as I mentioned few posts ago, is amazing. And this helps a lot! At the moment we have stripped out all the usual meetings so we don’t have a daily scrum meetings (obviously), a planning meetings or the retrospective.

We’re using Slack for team communications and a #development channel for the engineering team. We’re reporting progress on a weekly basis in a specific channel asynchronously and we manage the tasks in Trello (which is amazing for a small team like that).

We have a almost 100% unit test coverage (I just don’t care about integration tests), and we work using the github’s feature-branch/pull request approach.

Who created the pull request cannot merge it until someone else thumbs up (the reviewer).

The pull request approach works great, but you better be careful and follow some tips:

• Keep it small: If you have a 100 files with 2000 lines of code in your PR it’s very likely that the reviewer will just thumbs up without reading it. Avoid that situation and commit frequently, document the pull request and the code.
• A PR should include only one feature: Be clear and give your PR a single responsibility.
• Avoid format changes: Agree with your team about a code style and stick to it. And don’t forget a newline at the end of the file. You better configure your editor for it.
• Make sure tests are green: If you have a CI, make sure it report the status in the pull request, if you don’t have it please do it manually.
• Write code so other people can understand it: assume that if your colleague cannot understand what this PR is about, is not your colleague’s fault.
• Make a checklist for reviews: The team should write down a checklist for every reviewer to go through, and when you create the PR help the reviewer checking everything first.
• Be positive when discussing: The review process exist for a reason, it encourage confrontation and discussion. Just be positive and try to understand each other. In case it’s necessary ask a third person.

As I said this team is small and the budget is almost unexistent, but things will (hopefully) change in the future. We’re ready!