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.