Project Management with GitLab

After giving Trello a second try, I can earnestly say it doesn't work for us. Kanban boards are a good way to schedule short-term tasks. But you wind up needing to supplement it with other tools to manage, among other things, the spec document and its revisions, ideas that need to be triaged, bugs, and low-priority issues that need to be looked at a few weeks/months later.

Maintaining a clear description of the high-level objective — the product and technical spec — is important. What are you trying to achieve? What problem does it solve? What are the performance characteristics? What are the acceptable metrics (response time, availability, etc.)? What is the infrastructure required? What are the technical components? Trello has no place to put a descriptive document with requirements and high-level implementation plan. It's just a Kanban board, after all.

Trello works out well as long as you operate within a work-week model. Tasks are added on Monday for the team, they go through the phases (Design > Dev > Test > Deploy) and finally get archived. On Saturday, you evaluate what was Scheduled v/s Done and you reschedule the left-overs for next week. Over time, as complex issues are picked up, things begin to slip. It gets extremely hard to quantify how much time was spent per task and how far the project has slipped.

In consulting, a critical aspect for us it to estimate and reflect on timelines. Traditional PM tools like Microsoft Project have advanced scheduling features that enable a fine-grained assesment of resources and output. I also spent a year working with Asana, and unless you are proficient at it, the "list view" of things can become overbearing. People end up dumping long lists of items without proper tags and forgetting about them. A task is assigned to someone else and your job is done. Related issues are almost never collated. In GitLab, since issues are tightly coupled with commits and specific lines in code, you can walk back to see why the change was made (and in response to what product situation). Asana and other PM tools do have integrations that enable this kind of tracking, but I'm yet to see them being used effectively.

Pivotal Tracker needs a notable mention here. It almost made the cut for managing the drawbacks of a simple Kanban implementation, but its pricing was beyond our reach.

There are countless successful open-source projects of all sizes that exist on GitHub. Quite often, GitHub issues + Slack/Gitter is the only project management stack being used and it works perfectly fine. Developers are quite comfortable with workflow tightly coupled with their codebase and measuring effort is straightforward. It's also evidently clear (from commits and forks) what each developer is working on.

GitLab has features that make project management possible in addition to source control and code review. However, all this doesn't apply to situations when your team has multiple projects with relationships across them, or if you need an overview of all projects.

1. GitLab Issues with due-dates

Project issues can have specific assignees and due-dates. These features make it no different from most PM tools. Issues are basically a comment thread so you can keep posting updates on the task. Any engineer who has ever worked with GitHub knows the UX.

2. Milestones with due-dates

Issues can be assigned a particular milestone — a release with specific features planned. The milestone usually has an overall due-date, so for a high-level overview of project status and progress, management can refer to project milestones.

3. Shared Kanban Boards for the Project

Kanban boards are a great way to visually oversee immediate work queues. They are simple and straightforward, but it takes some effort to keep them simple. The size of each queue (to-do, in-progress, etc.) can quickly get out of hand. It's also important to dequeue things that have to be worked on later because something more critical came in.

4. Tracking Progress with Gantt

In order to get a high-level perspective on progress, we use GanttLab with GitLab. Tracking project slippage is a lot simpler with the Gantt chart.

5. Labels and Filters

These features exist in every PM tool so there's not much to talk about. Issue list is quite expectedly noisy. Filters are its saving grace. Following are the labels we frequently tag issues with. Some of them (to-do, etc.) also form the work queues in the Kanban board.

6. Slack for Discussions

GitLab is hooked up to Slack for discussing solutions. All GitLab activity is logged in the #dev Slack channel, so everyone in the team gets constant updates on project activity. It can get annoying, so you may choose to Mute the channel. People are pulled into discussions with mentions when necessary.

Our Workflow

• Product Spec goes into the Wiki
  • Extremely detailed with mockups and sketches, so there's little scope for confusion
  • With versioning and revisions
• Issues are created from the Spec
  • Create fine-grained issues
    • For tasks that would typically take not more than 1-2 days
  • All issues have clear labels and a milestone
  • Usually end up with a large no. of issues, so correct labels are critical
  • Due-dates are set where applicable
  • Spec discussion/triage also takes place via GitLab issues (labelled appropriately)
• Issues are added to the Kanban Board "to-do" list and follow the dev cycle
  • If things get re-prioritized or deferred, due date is updated accordingly and issues are moved out
• Code: Milestone branch for current milestone is created
  • Follow the GitFlow branching model
  • Commits go to develop and are eventually merged into milestone-release branch
  • Once release is ready, milestone-release is merged into master
• Code: Issues from the to-do list are picked up and worked on
  • Commits for the issue are PR'd and reviewed (PR to milestone-release branch)
  • Issues are closed with a comment and moved out of Kanban Board
  • If changes are required they are reopened and rescheduled back to to-do queue

We don't have any non-technical staff at the moment. In many cases, this workflow just wouldn't work in organizations because non-technical leads would find it too complex. In reality, it's just another tool that has a learning curve. The decision you have to make is whether you'd rather have one person at the top adjust to the dev team, or the other way around.

While GitLab allows creating additional Kanban Boards in case you want to maintain your own task list separately, I often require reminders on my phone and desktop to keep things organized with my daily schedule. I personally have all daily tasks in Google Keep, but Google refuses to provide APIs for it. I have set up a few hacks with Selenium on my Raspberry Pi to sync my Kanban queue with Google Keep, but at the moment it's far from perfect.