Moving CI/CD planning to be focused around a single prioritized list
As brought up by @dhavens in our last ~"CI/CD" team meeting, here's an outline for the idea of switching planning to use a single list of items in priority order.
Summary
The idea here is to forgo planning the entire release up front, and to work off of a single prioritized list (per team). In short, when an engineer is ready to take on a new issue for them to work on they take the item closest to the top of the priority list that is relevant to them. In other words, if a backend engineer, who is a reviewer on gitlab-runner, is ready to take on another issue, then they take on the next gitlab-runner or backend gitlab ce/ee issue and not an issue about refactoring a frontend component :)
Bugs, security issues, backstage work and feature work are all combined into one prioritised list.
There is another flavour of this approach that would have separate lists for each discipline (FE, BE, UX) but the idea is essentially the same, just implemented a bit differently.
What it looks like day-to-day
For an engineer
Not too different from how things are now: engineers have issues assigned to them and they work through them. Each engineer probably has several issues assigned at any given time to allow for the ebb and flow of things being in discussion or review.
The main difference is that work that’s not currently started on (and by started on I mean code being written), isn’t assigned. Unlike our current way of working we don’t assign multiple issues to an engineer and they start then when they can. Issues are only assigned when work begins.
When an engineer has capacity to start on another task, either due to existing tasks being finished or needing to wait for them to be reviewed, they take the next relevant issue off the top of the prioritised list.
For a PM
The Product Manager aims always have the “right” things at the top of the priority list and have them ready to be worked on. The day-to-day of this involves mostly keeping an eye on how much is left in the “ready to be worked on” section of the list and making sure that the relative priorities are being adjusted accordingly. For instance, if the next ten prioritised issues are security bugs in the runner, then a rails developer would need to go down to the 11th issue to pick up a relevant issue for them. The Product Manager needs to work with the Engineering Manager to make sure there’s an appropriate balance of things that are ready.
Again, ready in this sense means that the issue is completely ready to be worked on and needs minimal, if any, consultation from other specialties on the team (BE, FE, UX, PM). For example, a FE issue isn’t ready if the UX/design hasn’t been completed and a BE issue isn’t ready if there’s still discussion needed between FE and BE about what data needs exposing to the FE.
For a designer
Designers would experience a bigger change in day to day interactions with issues because they need to work ahead of the FE and BE engineers. If there’s an issue that’s coming up on the prioritized list that’s “add X widget to MR page” then the design of that new feature needs to be in place before the engineers can work on it.
There’s at least 2 ways for this to work out:
- A separate issue for the designer “design for feature-X” which is a prerequisite for “frontend for feature-X”
- A higher level issue (“add feature-X”) that gets recycled - aka: once the design is complete it gets put back in the prioritized list based on it’s priority relative to the other items in the list as determined by the PM.
Either way, the designer would be explicitly working ahead of the engineers to prepare the feature. Doing so in close collaboration with the PM would then help with the planning of the release and overall design of the feature.
There is also probably a third way for it to work out where once the design work is done we take a process shortcut by not putting it back in the list and assigning it to the next available, appropriate developer.
For an EM
The EM needs to be looking farther down the list with the PM with an eye for relevant technical debt - what are things that the PM would like to ship in the next month or two? What technical debt or backstage work is needed to unblock those items or make them faster to deliver. Working to prepare those items ahead of time with the goal of not being blocked or held up for feature delivery by known technical debt.
Additionally the EM needs to be keeping an eye on the top of the prioritised list to make sure that it reflects the capacity of the team (eg: isn’t all gitlab-runner items).
What it looks like week-to-week/release-to-release
For the PM & EM
Obviously, having a prioritised list is the key to this working. This might seem daunting as we have over 3,100 issues with the CI/CD label attached. However realistically what needs to be prioritised is the top of the list. Exactly how far down the active prioritisation needs to go is something that we’d have to determine over time, but probably 3-4 times the number of members on the team is a good start.
At some regular cadence, weekly, bi-weekly, etc. the PM and EM would need to share their inputs on the priority changes to make sure that the rest of the team was able to focus on the upcoming issues.
For the kickoff call, the PM could look at the top of the list and estimate that the top n items would be delivered. Where n is a number that we would estimate at first and the refine over time.
For engineers / UX
At some regular cadence, the engineers and designers would need to spend some time going through the items near the top of the list to make sure they’re as well understood as possible - fleshing out any technical limitations or requirements ambiguities.
In a co-located synchronous team this would probably look like a once every week or two session where the issues were discussed in order. For an asynchronous, distributed team developers could set aside certain blocks of time, say an hour, two to three times a week to participate in the asynchronous discussions for the items in the backlog. Because the issues would exist in a prioritised list it should be easy to see which discussions should get attention first.
Things We Could Measure To Decide If This Is Useful
- Amount of time spent planning a release
- Amount of MRs delivered in a release (throughput)
- Amount of time it takes for an issue to get completed (cycle time)
- Number of issues delivered in a release
- Number of bugs fixed in a release
Yes, this shares a lot of similarities with a Kanban style model.
No, this doesn't conflict with other discussions that are happening around scheduling or planning mechanics.
Yes, we're totally free to try something like this out if we want to experiment.
Please jump in and discuss and let me know your thoughts!
CC @grzesiek @matteeyah @steveazz @tmaczukin @nolith @dosuken123 @jlenny @dhavens @filipa @winh @dimitrieh