Feature Branches with Code Reviews

We have been trying to find a process for doing code reviews for a little while. Because most of our current projects are in github, it made sense to try and use some of the github features to help in this process.

I have been using issues for stories and milestones for sprints for a while. And it works out nicely because I get a pretty neat gamificationy results.

So I started using a feature branch in order to have the ability to make pull requests on my own project and get a discussion thread before code is merged into the trunk (production).


This discussion is a great way to get a reasonable code review before merging code. Right now we’ve decided to only do this for non-trivial changes, but with a very high bar on “trivial”.

Forcing Client Involvement Through Production Releases

What I take away from agile is the idea of putting something in front of a client as quickly and as often as possible. Of course things are going to have flaws, and things may be unfinished, but having the client see what you’re doing gets a sort of course correction done that doesn’t happen in a vaccuum. People tend to understand this, but they don’t often abide by it.

The problems I’ve seen lately have been in the instance when there is no client directly involved in the process. In that case, a product manager is assigned to take on the role of client, someone who mostly understands what the client wants and basically be their advocate. But the product manager, being an employee and not a client, doesn’t want to risk releasing an incomplete project for fear of how that will look or how the client will react to that. Therefore purposely not involving the client in the only part of the process where the client could give direct feedback — in production.

As long as it’s explained to the client that they are dealing with an alpha, and we welcome feedback on things they feel are necessary, it seems they could be used at that part of the cycle to offer feedback and keep features that will never be used from being added to the project and keep the project from straying too far from something they don’t want.