• sugar_in_your_tea@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    3 months ago

    No, separate groups. We basically have four separate, less-technical groups that are all involved in some way with the process of releasing stuff, and they all have their own motivations and whatnot:

    • PM - evaluated on consistency of releases, and keeping costs in line with expectations
    • PO - evaluated on delivering features customers want, and engagement with those features
    • QA - evaluated on bugs in production vs caught before release
    • support - evaluated on time to resolve customer complaints
    • devs - evaluated on reliability of estimates and consistency of work

    PM, PO, and QA are involved in feature releases, PM, QA, and support are involved in hotfixes. Each tests in a staging environment before signing off, and tests again just after deploy.

    It seems to work pretty well, and as a lead dev, I only need to interact with those groups at release and planning time. If I do my job properly, they’re all happy and releases are smooth (and they usually are). Each group has caught important issues, so I don’t think the redundancy is waste. The only overlap we have is our support lead has started contributing code changes (they cross-trained to FE dev), so they have another support member fill in when there’s a conflict of interest.

    My industry has a pretty high cost for bad releases, since a high severity bug could cost customers millions per day, kind of like CrowdStrike, so I must assume they have a similar process for releases.