Process idea for making GitLab monthly releases faster and more consistent
Problem
Currently, GitLab releases every month (12 releases per year), which is good. We should keep pushing ourselves to ship and iterate.
Current handbook
In our handbook, we include important dates that help keep our milestones on track. We state that by the 22nd of the month, a draft of issues is created and we start capacity and technical discussions with engineering/UX on the 22nd of the month. Scheduling and priorities are finalized by the first.
Visually, the timeline would look as follows:
- You can see all the responsibilities for each function (PM/UX/FE/BE)
- You can see all work responsibilities done for milestone
XX.2
is highlighted in blue - You can see all work responsibilities that happens from
22nd till 22nd
(this includes work for future milestones)
This workflow shows that engineering (FE/BE) is often finishing up deliverables, doing code review, and product discovery all within a two week span.
"Product discovery" definition: A period in which PM, UX, FE, and BE work together to get to a proposal that solves the problem, is technically feasible, and is considered from a UX perspective. The deliverable being something that is clear for development to start working off from with a high chance of successfully delivering it at the end of a sprint.
More likely scenario
However, often times teams don't realistically start discovery work until the 1st when issues are finalized. There is a cascading effect, which causes a lot of tasks to be backloaded.
This simplification shows how tasks become even more backloaded over the course of a milestone when work shifts from the 22nd to 1st:
The following problems arise:
- Responsibilities might be hard to combine (e.a. providing attention to product discoveries when in feature freeze week)
- Merging at the end of the release is a heavy burden
There is also the chance for this timeline to become more backloaded, depending on whether a month has 28 or 31 days.
We might say that this means we should strive to start discovery on the 22nd (as currently documented), when a draft of issues is formed for the next release. However, that doesn't solve the problem that engineering is already overloaded with finishing up deliverables, doing code review, and product discovery within those last two weeks which ultimately leads to the more realistic timeline showcased above.
Proposal
- Idea to production in 4-week releases
- 2 weekly release cadence tick tock model (resulting in 26 releases per year)
- Potential for faster bug/regression fixes
- Alternating development teams per tick/tock with alternating responsibilities
- Less heavy merge periods as load is halfed
- Dedicated time for planning ahead of product discovery curve but within the same rhythm
- Dedicated cross team product discovery time ahead of development curve but within the same rhythm (devs are not restricted by other responsibilities)
gantt
dateFormat YYYY-MM-DD
Title Tick Tock alternating development teams releases
Section Release
11.7 :2018-12-17, 4w
11.8 :2018-12-31, 4w
11.9 :2019-01-14, 4w
section Cadence
Tock - 0 :2018-12-17, 2w
Tick - 1 :2018-12-31, 2w
Tock - 1 :2019-01-14, 2w
Tick - 2 :2019-01-28, 2w
section Product
Product Planning (tick2) :done, 2018-12-31, 2w
Product discovery (tock1) :done, 2018-12-31, 2w
Product Planning (tock2) :active, 2019-01-14, 2w
Product discovery (tick2) :active, 2019-01-14, 2w
section UX
Product discovery (tock1) :done, 2018-12-31, 2w
Review (FE & BE team 1) :done, 2018-12-31, 2w
Product discovery (tick2) :active, 2019-01-14, 2w
Review (FE & BE team 2) :active, 2019-01-14, 2w
section FE & BE team 1
Coding (In review) :done, 2018-12-31, 2w
Product discovery (tock1) :done, 2018-12-31, 2w
Coding (In dev) :active, 2019-01-14, 2w
Review (FE & BE team 2) :active, 2019-01-14, 2w
section FE & BE team 2
Coding (In dev) :done, 2018-12-31, 2w
Review (FE & BE team 1) :done, 2018-12-31, 2w
Product discovery (tick2) :active, 2019-01-14, 2w
Coding (In review) :active, 2019-01-14, 2w
cc/ @markpundsack @dhavens @tommy.morgan @timzallmann - Would love your thoughts here on this issue. Is this something that could help improve velocity while making time for proper discovery/requirements building?