Every month on the 22nd a new version of GitLab is released. It always
includes major changes, with features, bug fixes and performance improvements.
We haven't missed a single month since our inception.
We are completely remote, save for the Experience Center in San Francisco that not a single
developer frequents (a 10,000km commute is a bit much for most). We do not have
predefined teams and almost everyone works independently (i.e. without someone telling
them what to do).
We do not practice any specific agile methodology, but meet the principles
of the agile manifesto quite well.
This is a start in describing the workflow that we've established over
the past year at GitLab, as it seems to work for us and might for you. It's
lightweight and self organizing. It might or might not scale.
A large part of everything we build in terms of features is based on feedback from the
community and customers.
When a request comes in from a customer (through support or sales usually),
the person receiving this request creates an issue to discuss it.
They are responsible for mentioning relevant parties. For most features that
is the product manager, CTO, and any developers or other people that might be
interested in this feature.
Next, anyone with an opinion responds to the issue. This is often done in direct
response to others, including more people in the discussion if necessary. The
point is to reach some form of consensus. Once this has been reached, the issue
is scheduled for an upcoming release (e.g. 8.1 or 8.2). Anyone can do this based
on the information in the issue and on how full the upcoming releases are versus
how important this is.
Everyone that has participated in the conversation will be updated with any status
change. Therefore anyone can freely schedule things. If someone disagrees, they'll
It's very hard to schedule things. We simply do not have a good way to estimate
whether something will be doable, besides estimating based on previous releases.
However, we prefer the scheduling to be hard over adding overhead with estimating
weights and velocity for the team. We might change our minds on this.
Working and Prioritizing
A developer can pick up any issue at any time they're working.
They simply assign themselves, marking it as "Ongoing" in GitLab's Milestone
Some issues have a clear owner in terms of knowledge and ownership of that part
of the code. Usually this developer has already been active in the issue. The
developer likely picks these issues. This is a self-organizing process.
A small part of the issues is promised to a customer. This means that we told the
customer: "Feature X will be done in release Y". We always intend to keep our
promise, so these issues get prioritized by everyone.
There is also a general guideline to prioritization of work. This does not
work as a hard rule and also depends on your skills and responsibilities:
- Emergency issues
- Security issues
- Data integrity (not losing data)
- Availability of GitLab.com
- Subscriber questions
- Regression issues
- Consultancy work
- Promised features
- Growth efforts
- Other work
Find this in our handbook.
People can choose their own issues, which can result in a situation where
issues that are not 'fun' are not being picked up. This can be solved with
proper handling of overflow issues, as described below.
Overflow of issues is something that happens every month. Meaning, not all issues
assigned to a release get completed or worked on.
In the past, we would simply move everything to the next milestone. This 'waterfall'
workflow didn't work, as unpopular things would get dragged on for many releases.
Nowadays, we (I) go through all leftover issues and investigate why they didn't get
done and what we can do with them.
This often results in dropping the issue as it's no longer relevant or moving it
up to a future release and pinging a developer to take ownership of it.
Managing overflow issues is a very hard balance between capacity and process.
Mostly we blame a lack of developer capacity with overflow issues
With every release, we try to reflect on what could have been done better.
For example, most recently Douwe and I proposed a different model to schedule
issues to prevent too many promised issues. Most developers had strong opinions
on this, which spawned this article. We ended up not making changes, choosing
speed and flexibility over process, but gained insight into how people feel about
the status quo.
Openness, Independence and Responsibility
As a developer you're required to operate independently and make decisions.
By making your own decisions, it reduces process overhead and unnecessary
It's your responsibility to report those decisions in the issue that you're working
from. This is the core of our workflow. People that were previously active in the
same issue, will receive your updates and thoughts without disturbing one another.
If there is an issue, they will respond in the issue. The whole process is asynchronous
Lastly, we're open.
This is something that runs deep within GitLab. To be able to work with the community,
with our customers, we have to work in a way that everyone can contribute equally.
We think this works well for everyone, but are always looking to improve things.
As we're growing very fast, we're not sure whether this will scale.
How does your workflow look and why does it work for you?