GitLab’s developers use a pull workflow so the assigned field is editable by anyone. The intended worfklow is to leave the issue unassigned (though tagged for a team) and when a developer is ready, they assign it to themself and work on it. Assignment is seen as a “leave this alone if it’s not you” sort of signal rather than “someone wants me to get this done.”
Pushing work, central control
The assigned field is just a field, one could make use of it as a manager control mechanism.
In the push pattern, a bunch of product owners go through their backlog and assign and bunch of tickets to a bunch of developers. The developers are then overwhelmed by items to touch and end up doing meta analysis about why they should be assigned elsewhere or reprioritized behind dependencies.
Some work gets done but it’s not the important / critical path stuff. It’s often the low hanging fruit or just Jira gardening since the assignments can’t be changed, things wait until the sprint planning to get shuffled. Weeks are lost.
This is the same failing that lead factories to the Lean concept where prior stage work isn’t released until the next stage is ready for it. In GitLab, the person it’s assigned to can remove themself which would be the same as putting down the flag, NOT READY FOR NEXT THING. The field is not locked down so there is no forced assignment.
Make developers work
But I want to make developers get stuff done!
Devs who don’t want to work won’t work regardless of the system so this isn’t some sort of panacea… but in the GitLab workflow, developers will pull an issue when they’re ready to work on it. They’ll create an MR immediately and get it to the point that it’s ready for review. All the work is visible. Contributions are tied to the committer, not the assignee.
When the work is done and the branch is merged, the issue drops off the list by being automatically closed and the developer moves on to the next item.
What about adversarial manager/developer relationships?
This obviously falls apart in an adversarial situation such as contractor oversight. Incentives are built around delays and hours and timesheet values. That system promotes overtime addiction and delays.
Everything is assigned so everything is being worked on.
Vs
only 2 of the 10 items in this sprint are assigned so only 2 items are being worked on
If it doesn’t matter, why write this article?
In a positive and functioning team dynamic, leaving the item assignent empty until it’s ready to be worked on creates an effective timeline of when the intention to work on an issue happened. Then the next official event is creation of the merge request which shows work actually starting. The next after that is the first commit to the MR which shows when something was created, it may not pass all the pipelines, but it’s something. Then we have milestones for the first passed pipeline and then approval and finally merge.
If your team follows different approaches, creates a lot of MRs at once, doesn’t commit until they’re sure pipelines will pass, or other behaviors, the cycle analytics reports will not ring true.
Policy resistence system malfunction
This page is important in terms of the system trap related to policy resistence.
Breaking out of the manager pushing work down dynamic is to switch to a pull approach by following one of the myriad Lean methodologies.