Digital Project Management and Collaboration Using GitHub

Holly Davis is the Delivery Director at Deeson. You can find Holly on Twitter @ProjectDavis.

A year ago, I had never heard of GitHub and now I’m using it on several of my biggest projects and to my surprise, enjoying doing so!

A cropped version of the GitHub 404 page banner showing it's Octocat character dressed as ObiWan from Star Wars in a desert scene in front of a land speeder and hut.
It’s worth using GitHub if only for this each time you type with chubby fingers.

It started just under a year ago when I asked my project team what their preference would be for tracking issues, and the developers were almost evangelical about GitHub. I was aware that most of our active projects were being hosted and deployed from GitHub but didn’t realise it could be used for managing projects too!

So, we took the leap and instead of introducing something new into the mix we started using it to manage tasks, releases and bugs.

The results have far exceeded my expectations, i’ve seen some of the best examples of team collaboration between client, UX, developers, testers and PM, even users have used it to raise bugs or enhancements they’d like to see. This is invaluable for the product owner, who is able to respond to clients directly and add enhancements to the backlog and prioritise accordingly.

Using labels you can create issues for “discussion” i.e. we need a comment system, here are the options giving everyone visibility over the options and the opportunity to comment and be involved with the solution.

A screenshot of low-fi sketches uploaded to GitHub
If I was the client I’d totes sign this off.

GitHub wins on simplicity and its clean interface. Even some of our designers have adopted it for presenting low fidelity sketches to the client / team to review. It’s great to have communication in one centralised place rather than across emails and visible to all the team. You can set up email notifications when people comment or tag you in an issue.

It has also given me more visibility on work in progress. In our daily ODI scrums we have even introduced the reviewing of pull requests. This helps limit work in progress by ensuring pull requests are reviewed, merged and closed. If the same PR is there several days running, it can quickly alert you that something is wrong that you wouldn’t normally be able to pick up on as a non technical PM.

However, like any tool there are a couple of drawbacks. I have had to continue using spreadsheets to track time and velocity over sprints, as you can’t add estimates or track time spent on the issues themselves. However you can assign a milestone to tasks within a sprint which will give you a % indicator of tasks completed but isn’t that helpful if the one task you’ve not completed equates to half the sprint!

Lastly, there is no easy way to prioritise issues. For ODI we’ve added priority 1 and priority 2 tags which work well but i’d like the open issues to work more like a physical backlog where you can click and drag issues to prioritise.

In conclusion, I would recommend using GitHub to other Project Managers, particularly if you’re happy to track project progress outside of GitHub and just embrace it for the ace collaboration tool it is.

A screenshot of the Huboard tool showing a Kanban board.
Web project management things in GitHub? Developers, you cannot escape it! :)

If you’re thinking of using GitHub you may want to look at Huboard, a lightweight Kaban board which integrates with GitHub issues.

If that doesn’t fulfil your requirements you may find something that does on this Quora question “Which project management tools are deeply integrated with GitHub?“

Not convinced yet? Why not do some further reading, here are couple of other great blog post on the topic.

Have you been using GitHub to manage projects? If so, I’d love to hear your experiences.