Shocking, I know.
When I first joined the GOV.UK Design System, we used Trello to manage the team’s workflow. This worked well whilst the product was still in alpha and private beta, however once we moved into public beta, this became challenging.
Our aim with the GOV.UK Design System has always been to work in the open and encourage contribution to the code base and guidance so growth is community driven.
Hosting our work on Trello became an issue because all organisational Trello boards were private by default, and early contributors would raise feature requests or new components and patterns on GitHub. This was only really visible to the developers on the team who would then need to replicate this information in Trello.
Our tech lead Ollie mentioned that GitHub had a projects feature which had a very similar functionality to Trello. It felt like a good thing to try out and see if it’d work better for our users than Trello.
The first version of GitHub Projects we used had a standard swim lane structure which worked well for the Kanban system we were using on the team at the time. We were able to use issues in repositories to create user stories, labels to categorise work, and add users to stories.
However GitHub is primarily a code space and designed for developers. Using the platform was challenging for less technical members of the team. There were a few things we did to try and help with this, for example, build pre-populated issue templates for the team to use so they can structure user stories and don’t have to start from scratch each time.
We also manage multiple repositories and many team members find it difficult to identify which repository they should create an issue in. We tried to fix this with documentation but it’s not always checked.
GitHub released a new version of their Projects feature in late 2022 (I think!). From the early documentation released it looked like it would work a whole lot better for non technical folk. You could use different formats to display work, not just swim lanes. You could create custom fields, and filter data by those fields. You could also set up multiple ‘Views’ (essentially tabs) which display different data points (however we did find it’s easy to go overboard with this and we ended up having way too many at first).
The ‘Table’ format has worked well for our team. We’ve been able to replicate our squad and sprint structure within this and most team members find it relatively straightforward to use. Every team member is rota’d to facilitate stand up and I’ve not witnessed any folks struggling to “walk the board”.
However creating issues (either for user stories or epics) and using some of the enhanced features such as Tasklists is still proving challenging for non-technical folk. I also feel there’s a lot more Projects can do with data which would be useful to delivery and product managers. We think we might be able to use GitHub Actions to do some of this but we need to investigate further (another blog post for another time!).
I’ve mostly got my head around how to use GitHub for project management but have found this knowledge difficult to transfer to my colleagues. My current method is to host a fortnightly GitHub surgery where I help team members navigate GitHub and prepare for a new sprint. Only a handful of folk from the team have joined so far but I hope this increases over time.
I think there’s probably more I can do with documentation too. We recently created a Team Playbook and began migrating some content from our internal docs to the website. This is probably where I’ll draft something for the team to reference.
If you want to take a look at how we’re using GitHub Projects you can take a look at our sprint board here.
This is a pretty high level overview of how we’ve used it but let me know if there’s anything you’d like to know about in more detail and I’ll write about it.
