For quite a while, we have leaned towards a Kanban-inspired approach to project management. Inspired by the lack of tools available for our specific needs, we built our own Kanban integration that works seamlessly with GitLab.
Sometimes, you realise you need a tool that doesn’t really exist yet. That’s what happened to us before we ended up developing our own version of Kanban as integration for GitLab (our version control tool of choice).
Kanban is a hugely popular agile method that is very well suited to our way of working. The name is Japanese and translates to “visual signal”. First developed by Toyota in the 1950s, it visualises the current state a project in a clear and digestible manner. Each task is represented by a card that moves from one status to the next. This makes it easier to prioritize tasks according to the current sprint’s needs.
So why did we need a custom Kanban integration? Back when we began the project, GitLab didn’t support board views for groups. And Atlassian’s Jira, a project management tool we were dabbling with, didn’t have many other features we were looking for. And so we decided to go all DIY and build a tool that would address our needs.
What makes our Kanban unique?
The basics of our implementation are classic Kanban stuff. In any given project, we organise the features, issues and bugs under “lanes” with titles such as “To Do”, “Doing” and “Done”. The lanes are then filled with task cards sorted by priority. Tasks that are selected to be worked on during a sprint are moved to the To-Do lane. At the end of the sprint, all of the cards have (hopefully) been moved to the Done lane.
To understand what would be the most important special features for our GitLab-integrated Kanban, we conducted a survey on our designers and developers. Based on the replies, we figured it would be useful to automate as much of the change management as possible.
Thus, adding a new issue automatically creates an issue to the “Doing” column, a new branch and a merge request starting with “WIP:” as well. The developer can then immediately check out this new branch and just start coding. When the changes are done and pushed to GitLab, a code reviewer is set and the “WIP:” prefix removed by simply performing a simple drag to the next column. What’s really cool with this is that the developer doesn’t even need to open GitLab at all to track the progress of any given ticket.
Another thing that is super handy for us is the ability to use filtering to display a certain subset of tickets in a project. For example, as a developer I may want to see all reported bugs assigned to me with a specific milestone in a specific group, sorted by priority. Gitlab, Jira or any other tool we researched doesn’t offer this feature in the exact form we needed it, so it’s great that our little tool now does.
Tools should fit your processes, not vice versa
Our Kanban is still very much a work in progress, but it has already streamlined and standardised our development processes. When everyone uses the same tools, different practices don’t emerge as easily and change management as a whole becomes easier.
As an example, previously many of our projects had different conventions on how branches should be named or labels to be used. Some projects used issue labels extensively and others didn’t use labels at all. The labels were just listed one after the other, making their maintenance a major pain. Our new Kanban automates all of this and thus, the issue labels are rarely if ever manually changed anymore.
Rather than forcing people to use a specific agile method, we like to adapt and combine methods from different schools of thought as needed, creating our very own Taiste way of doing.
All this is also in line with our mentality regarding processes in general. We believe in organic processes instead of formal ones: rather than forcing people to use a specific agile method, we like to adapt and combine methods from different schools of thought as needed, creating our very own Taiste way of doing.
And so, the best part of having our very own Kanban tool is modifiability – when our process develops and we realise we need a new feature, we can simply implement it. This is the beauty of being a creator instead of a user.