Gitlab values on iteration#
Article: https://handbook.gitlab.com/handbook/values/
Notes#
The article is lenghty, here are the headings with my comments:
Start with a goal in broad strokes
Don’t wait.
Iterate toward global maximum
Set a due date
Cleanup over sign-off
Start off by impacting the fewest users possible
Reduce cycle time
Short iterations reduce our cycle time.
Work as part of the community
Minimal Viable Change (MVC)
Make a proposal. Instead of gathering opinions or brainstorming, make a concrete proposal and gather feedback.
Everything is in draft. Documents are rarely marked as a draft, because nothing is set in stone and everything is in draft.
Under construction. Call out that the current feature state is not final, point to the long-term plan and open a feedback issue.
Low level of shame
Cultural lens
Focus on improvement
Be deliberate about scale
Resist bundling
Make two-way door decisions
Changing proposals isn’t iteration
Embracing Iteration
Make small merge requests
Always iterate deliberately
Not iteration:
Reducing quality
Avoiding or reducing documentation
Compromising on security
Delivering something that’s not the recommended path or on by default
Shipping something of no value
An excuse to focus on unimportant items
Changing or lowering goal posts
Revisions you don’t ship or publish
An excuse to impose unrealistically tight timelines
An excuse to avoid planning
Imposing long hours
Expecting others to fix your work
Conclusion#
Gitlab’s iteration culture runs contrary to traditional software engineering workflows and to ADR process. ADRs go through draft, proposed, accepted states before the work begins. Once the ADR is accepted, it’s immutable. Gitlab process includes the doc stating the final goal, but the work is done in small iterations, that don’t require approvals or consensus. On the other hand, each small change has to go through merge request approval. This allows async autonomous work but requires bigger amount of documentation and context setting.