Sprint efficiently with GitHub

As with everything we do here at Red Badger we try and iterate and improve each of our disciplines during an application's or project’s life cycle. One of the items that we have been exploring is the use of GitHub and what it can bring to the table in regards to agile. Not only this, a view that in today's world being able to iterate faster and being able to react to feedback from customers and building features as productively as possible whilst maintaining quality is key.  

There is a fantastic presentation from Zach Holman from GitHub who explains how they use GitHub to build GitHub. It really opens the eyes to the fact that simple tools with no more and no less = happier developers and more effective development.

So with this mantra we decided to switch to try out and only use GitHub tooling for user stories, issues and managing the sprints. During the process of writing this blog post GitHub have announced the way that in which the team works aptly named GitFlow allows everyone to follow the process via the GitHub website.  

Having tried out this process the team and I agree that it is a satisfying and effective way of working especially when applied to agile methodologies.

agile_git_blog

It is important to note that we follow a branching model of the ever popular. If you haven’t read this article and are working with git as version control I would highly recommend giving it a read.

Within your development team at the start of the project just getting your team together and making sure the team understands this before work begins it will 100% give you a smoother application development cycle. To make this process even easier there are Git extensions to help you out. 

Next we need to explain and break down the components in relation to GitHub tools and how we use them to relate to agile terms:

Sprints

Within GitHub we would create milestones that represent the sprints and the current sprint we were working through.

User Stories

Within GitHub we would then create a branch that relates to each user story. For example a story/statistics branch for a user story related to statistics development within the application.

Reviews/Collaboration

At Red Badger we also strive to bounce off each other for ideas and improvement on code we produce. For that very reason once a user story is ready for the team to review and collaborate we submit a pull request to the develop branch. Once everyone is happy it is merged and the pull request is closed.

One area which was not explored which in a future project I think would also be great is to use the ability for designers to contribute to an empty pull request (which you can’t do in GitHub as it stands). This way developers can create user stories (pull requests) and collaborate all in one place (it is worth noting emails are supported within GitHub discussions, keeping designers in familiar territory when collaborating around a user story).

Issues

Bugs are always going to happen so we used the standard issue features within GitHub provides us with the most effective way of keeping a developer's workflow focussed on the sprint whilst also allowing bugs to be assigned accordingly. We gave access to our project manager who can also assign them to a realistic milestone for them to be resolved.

You really don’t need over engineered complicated bug tracking software. GitHub have the right ethos in my view when it comes to the effective yet simple features they deliver to manage issues/bugs.

The upshot of using these tools in this manner on the project allows us to manage releases effectively within the team with every little disruption. Especially having this layer on top of your standard build tools such as Travis CI that gives you instant feedback and continuous delivery directly integrated with GitHub.

The only one downside that isn’t cracked is that that traditional burn down charts for project managers are not integrated within the whole process. If we can solve the backlog planning and estimation with integration to GitHub we are on to the perfect solution for a self managed team without duplicated laborious project management “chores” each day.

It is all about keeping developers in the zone, doing what we love to do best.