Unified GitHub‐Centric Kanban Development Process - dneff/adventofcode GitHub Wiki

Unified GitHub-Centric Kanban Development Process

Overview and Goals

We propose a Kanban-based software development methodology that uses GitHub’s native tools exclusively to manage the entire development lifecycle. This unified process is designed to scale from small teams (3 developers) to large multi-team programs, ensuring consistency without sacrificing flexibility. Key GitHub features – Issues, Projects (Kanban boards), Pull Requests (PRs), Discussions, Actions, Milestones, and Releases – are mapped to each stage of development. By leveraging these inbuilt tools, teams can adopt Agile practices (like continuous delivery and iterative improvement) without external project management apps. The goal is an integrated workflow where ideas are tracked as GitHub Issues, work is visualized on GitHub Projects boards, code changes go through PR review and GitHub Actions CI/CD, and Releases and metrics are all handled within GitHub. This alignment reduces context-switching and overhead, allowing contributors to focus on code and collaboration. Crucially, the process supports both feature development and maintenance/bug-fix workflows, with clear role responsibilities and governance to enforce quality. The preferred flavor of Agile is Kanban, emphasizing continuous flow and pull-based work management, but the process also accommodates Scrum-like elements (e.g. optional iterations or milestones) for teams that need timeboxing.

Key outcomes from this methodology include: a detailed workflow (diagrammed below) showing how GitHub tools interconnect; process documentation mapping each GitHub feature to standard development practices; onboarding guides so new teams or members can ramp up quickly; a governance model for cross-team consistency (drawing on Team Topologies principles); and a metrics/reporting framework using GitHub’s native analytics to monitor progress and quality. The following sections detail each aspect of the methodology.

GitHub Tools Mapped to the Development Lifecycle

To implement a full development lifecycle using GitHub, we map common SDLC phases to GitHub’s features:

Ideation & Requirements – GitHub Issues (and Discussions): Use Issues to capture user stories, requirements, bugs, and enhancement requests. Each Issue represents a unit of work or problem to be solved. Issue Templates and Forms standardize data capture (e.g. separate templates for “Bug Report” vs “Feature Request”) to ensure all necessary information is provided. For open-ended brainstorming or Q&A, GitHub Discussions can be used, or Issues labeled as “discussion” for non-actionable ideas. This keeps early dialogue within GitHub rather than scattered in emails or chats.
Backlog Management & Prioritization – GitHub Projects (Kanban Boards): All Issues flow into a Project board that serves as the team’s Kanban backlog. The board is organized into columns (e.g. New/To Do, In Progress, In Review, Done). GitHub Projects (v2) supports flexible views (board, table, roadmap) and can aggregate issues from multiple repositories, which is critical for cross-team or cross-repo initiatives. Issues can be prioritized by ordering in the “To Do” column or using custom fields (like Priority). The Kanban board provides a clear visual of WIP (Work In Progress) and status for each item, ensuring teams pull new work only when capacity allows (supporting Kanban’s WIP limits concept).
Planning & Estimation – GitHub Milestones and Fields: While Kanban favors continuous flow over fixed iterations, teams can still use Milestones to group work by a time horizon or release. Milestones in GitHub allow setting a target due date and tracking progress of issues toward a goal (with an automatic progress bar showing issues closed vs open). For teams adopting Scrum-like cadences or needing estimates, GitHub Projects’ custom fields can be used – for example an “Estimate” numeric field (story points) and an “Iteration” field to simulate sprints. GitHub Projects’ iteration fields let you schedule recurring time-boxed iterations and even view past iteration velocities. These fields can feed into charts for velocity or burndown if needed. (In Kanban, iteration fields might be optional, but can be useful for forecasting and retrospective metrics.)
Development & Implementation – Git Branches and Pull Requests: Developers create a feature branch for the Issue they are working on (GitHub even allows creating a branch directly from an Issue, which links them). The development happens on that branch. When ready, a Pull Request is opened to merge the code. The PR is linked to the Issue (e.g. via keywords like “Closes #IssueNum” in the PR description) so that the Issue will be automatically closed upon merge, if appropriate. (Teams may decide whether to use auto-closing keywords – some prefer automatic closure, while others hold the Issue open for further validation.) Each Pull Request serves as a code review and integration checkpoint: it shows diffs, enables discussion via comments, and allows reviewers to request changes or approve. Code Owners can be configured to auto-request reviews from specific team members (or teams) based on file paths, ensuring the right people review each change. GitHub Discussions or Issue comments are used for any design deliberation related to the change, keeping conversation tied to the artifact (and reducing meetings).
Continuous Integration & Testing – GitHub Actions (CI workflows): When a PR is opened or updated, GitHub Actions workflows trigger automatically to run tests, linters, builds, etc. The process should include a robust CI pipeline defined as code (YAML workflows in the repository). For example, an Action workflow might run unit and integration tests, perform static analysis, and even run security scans on each PR. These checks report status back on the PR (pass/fail). Branch protection rules in GitHub can require that all checks pass and at least one approval is given before a PR can be merged into the main branch, enforcing quality. Using only GitHub’s services means we rely on GitHub Actions for CI (rather than Jenkins or others). Actions can also update the Project board – for instance, when a PR is marked “Ready for Review,” an Action could move its linked Issue card to an “In Review” column automatically. This reduces manual upkeep on the board.
Deployment & Release – GitHub Actions (CD) and Releases: Once code is merged to the main branch, GitHub Actions can trigger deployment workflows. The process should integrate with the organization’s existing CI/CD pipeline, now implemented via Actions. For example, merging to main could kick off an Action that builds a production artifact, runs final tests, and deploys to an environment (cloud or on-prem). GitHub’s Environments feature can be used here: you might define environments like “Staging” and “Production” with required approvers (e.g. an SRE or QA lead) before deployment proceeds. This introduces a manual control step using native GitHub capabilities (approving a deployment via the Actions UI). After a successful deployment, teams should utilize GitHub Releases to tag the version and publish release notes. A Release in GitHub can include auto-generated changelogs or curated notes, plus attached build artifacts if applicable. Milestones can be closed at this point if they corresponded to a release. The Release object provides a history of what was delivered when, and ties back to issues and PRs.
Maintenance & Support – Issues, Branches, PRs (Hotfix Workflow): Production issues or bugs are tracked as GitHub Issues (often labeled “bug”). The workflow for a hotfix is similar: create an Issue, possibly create a branch off a stable release tag or a maintenance branch, then open a PR for the fix. The PR triggers tests via Actions, and upon merge, an Action can deploy the fix. Teams may maintain separate long-lived branches for supported releases (if needed), but the process remains within GitHub. Also, GitHub Security features (if using GitHub Advanced Security) can alert on vulnerabilities (Dependabot for dependency updates, code scanning for security issues) – these alerts can generate Issues automatically. Handling these is part of the maintenance workflow.
Project Management & Communication – GitHub Projects, Milestones, and Discussions: The Project board is the real-time source of truth for project status (which is always up-to-date with issue/PR data by design). Team members and stakeholders can see what’s in progress and what’s done. The Project README/Description can serve as a mini portal: it can outline the team’s workflow, definitions (e.g. what each column means), and link to key resources. Teams should update status on high-level items by using Project fields or the GitHub Discussions feature for announcements. GitHub Discussions is particularly useful for open-ended conversations and FAQs – for example, a “How do we approach X?” thread, or an architecture Q&A that involves multiple teams. Using @mentions is encouraged to bring the right people into Issues or PR discussions. GitHub Teams (the grouping of users, not Projects) can be mentioned by team alias to notify a whole group at once (e.g. @org/sre-team), which is great for cross-cutting concerns or when handing off work.

Diagram – End-to-End Workflow: The following diagram summarizes how GitHub tools link together in the development lifecycle (from idea to release):

flowchart
    A[New Idea / Requirement] --> |Create| B["GitHub Issue (backlog)"];
    B --> |Triaged & Added<br>to Board| C["GitHub Project Board<br>(Kanban)"];
    C --> |Pull from 'To Do'| D[Issue In Progress];
    D --> |Create branch| E[Feature Branch];
    E --> |Open| F[Pull Request];
    F --> |"Run CI & Tests<br>(GitHub Actions)"| G[Auto Checks];
    F --> |Code Review| H[Reviewers];
    G --> |All checks pass| I;
    H --> |Approved| I[Merge PR to Main];
    I --> |Auto-close linked Issue| J[Issue Closed];
    I --> |"Trigger CD (Actions)"| K[Deploy to Environment];
    K --> |If all good| L["GitHub Release<br>(tag & notes)"];
    L --> M["Project Board Updated<br>(Done)"];

(The diagram illustrates the flow: ideas become Issues, which are managed on a Kanban board; developers create branches and PRs for each Issue; PRs undergo CI (Actions) and review; upon merge, the Issue is closed and deployment occurs via Actions, culminating in a tagged Release. The Project board and Issue states are updated throughout via automation.)

Kanban Workflow on GitHub Projects

The core of this methodology is a Kanban-style workflow implemented via GitHub Projects. Each team (or project) will have a Kanban board with standard columns such as: Backlog, To Do, In Progress, In Review/QA, Done (teams can adjust naming, but consistency is encouraged). Work items (Issues) flow continuously through these columns without fixed sprints – new issues can be added anytime, and completed work is released frequently. Here’s how the Kanban process operates with GitHub tools:

Backlog & Triaging: New Issues land in the Backlog (not yet prioritized). A triage owner (e.g. the Product Owner or Tech Lead) reviews incoming issues, ensures they have a proper label (feature, bug, enhancement, etc.), and sufficient detail (thanks to templates). They then move the Issue card into “To Do” when it’s ready to be worked. Optionally, priority can be indicated via labels or a custom field (e.g. P1, P2) and the board can be filtered or grouped by this field for planning. Unprioritized items remain in backlog until ready.
Pull-Based Work: Developers (and other contributors) pull the top item from To Do when they have capacity, rather than being assigned a large batch in advance. They assign themselves to the Issue (so others see it’s in progress) and drag it to “In Progress”. This signifies the start of work and can trigger an automation (e.g. setting a Status field = “In Progress”). At this point, the dev creates a corresponding Git branch. If using naming conventions, include the issue number in the branch name (for traceability).
Development & Integration: As code is written on the branch, frequent commits are pushed. When the feature or fix is ready (or at a good checkpoint), the developer opens a Pull Request. The PR description should link the issue (using “Closes #123” or “Fixes #123”) to tie them together. This not only helps traceability but can auto-close the issue on merge if desired. The Project board can automatically show the PR linked to the Issue. We also recommend using a Pull Request Template (stored in the repo) to remind contributors to include details like “Issue link, summary of change, testing done, screenshots (if UI change),” etc. This ensures consistency in PRs and speeds up reviews.
Code Review & QA: Once the PR is open, it enters the “In Review” stage of Kanban. The assignee or automation moves the Issue card to In Review. Reviewers are notified – either manually tagged or auto-assigned via CODEOWNERS or team mentions. They perform code review on the PR. Meanwhile, GitHub Actions runs the test suites and any other checks (these results appear in the PR’s Checks section). Reviewers ensure the code meets standards, and QA engineers (if separate) might run additional tests or review the deployed feature on a testing environment. If issues are found, feedback is given via PR comments and the developer continues pushing fixes (the Issue stays “In Review” or could move back to “In Progress” if significant rework is needed, depending on team norms). This stage is complete when: all required reviewers have approved the PR, and all required status checks (CI) are green.
Merge & Deployment: An approved PR can be merged into the main branch (often using “Squash and merge” or “Merge commit” as per team preference). GitHub branch protections can ensure only authorized users can perform the merge and conditions are met. On merge, if using auto-close keywords, the linked Issue is closed by GitHub. Even if not auto-closed, the team should mark the Issue as done. The Project board card then moves to “Done” – this can be automated with built-in Project workflows (e.g. when Issue state changes to closed, set Status=Done and auto-archive or move it). A GitHub Actions CD pipeline kicks off on the merge to main: building the production artifact and deploying it. Ideally, this deployment is automated to a staging environment first, where final verification can happen. Using GitHub Environments with protection rules, a manual approval by a Tech Lead/QA can be required before deploying to production. Once approved, the workflow continues to deploy to production.
Release & Documentation: After successful deployment, a version tag is created. The team uses GitHub Releases to publish a release entry – which may be done by an automated Action (for example, every merge to main that bumps a version could trigger an Action to create a release with release notes). Alternatively, for a collection of changes, the team might do this at the end of a timebox (if they choose to have a cadence like weekly or biweekly releases even in Kanban). The release notes should link back to the Issues and PRs included, which GitHub can partially automate if the PRs were linked. At this point, the Done column on the board (or the closed issues list) represents completed work that’s been delivered. The team can periodically clean up or archive done items to keep the board focused.

Work-in-Progress (WIP) and Flow Management: In Kanban, controlling WIP is key. GitHub Projects doesn’t enforce WIP limits natively (as of now), but teams can agree on limits per column. For example, “no more than 3 issues In Progress per developer” or a total cap in Review to avoid bottlenecks. The facilitator (Scrum Master or Lead) can monitor this and raise an alert (manually, or possibly via a script/Action that counts cards in columns). The focus is on finishing work in progress before starting new work, to maintain flow. Lead time (issue start to finish) should be tracked and improved continuously.

Maintenance Workflow: For production issues or urgent fixes, the process is similar but may have a swimlane or separate board. Often, teams dedicate a column like “Blocked/Waiting” for items that are waiting on external feedback or cannot progress, and a “Ready for Deployment” column if using a staging/prod promotion step. Maintenance bugs might be marked with a “Bug” label and could skip queue if critical (Kanban allows expedited lanes). The CI/CD process is the same – albeit sometimes hotfixes might be cherry-picked to a release branch. Even in those cases, everything is tracked via GitHub Issues/PRs (the fix issue might link to both a hotfix PR for production and a PR to merge the change back into mainline).

By using GitHub Projects as the central Kanban board, we ensure one source of truth for status. The board and issues stay in sync with reality because GitHub automatically reflects issue/PR changes on the project (e.g. assignees, labels, and status updates reflect across tools). This eliminates the need for separate status reports – anyone can check the board or issue list to know what’s going on. For higher-level tracking, an organization might also maintain an aggregate board or roadmap view that draws in issues from all team boards for broad initiatives (GitHub Projects allows a single project to ingest issues from multiple repos/teams). This is useful for product managers to see cross-team progress. For example, an “Organization Roadmap” project might have each major feature as an issue with a custom field indicating the owning team. Teams update those or link their detailed issues to the parent feature. This way, we can plan and track multi-team efforts while each team still works in their own space – a balance of autonomy and alignment.

Roles and Responsibilities

A clear definition of roles ensures everyone knows their responsibilities within this GitHub-centric process. We outline key roles and how they use the tools:

Product Manager / Product Owner: Responsible for defining requirements and prioritizing the backlog. They create or curate GitHub Issues for new features or changes (often using templates to ensure acceptance criteria are captured). They manage the backlog ordering on the Project board (moving items into “To Do” for upcoming work, deciding what is done next). They also use Milestones to target release dates or group issues for a release. The PM/PO regularly reviews open Issues and Discussions (engaging with stakeholders there), and updates issue descriptions or labels for clarity. They ensure that when an Issue is closed, it indeed meets the acceptance criteria (possibly by reviewing the linked PR or deploying preview). The PM might not code, but they will comment on issues, provide clarifications, and approve that a story is complete. In this process, they’re essentially the backlog owner on GitHub.
Developers (Engineers): Responsible for implementing code changes to satisfy issue requirements. A developer picks up an Issue from “To Do,” self-assigns it and moves it to “In Progress.” They create a branch, commit code referencing the issue (to auto-link context in GitHub), and open Pull Requests. They are expected to write meaningful PR descriptions and follow coding standards. Developers also review their peers’ code – acting as Reviewers on others’ PRs. They should update the Issue with pertinent comments if needed (e.g. if scope changes or questions arise). Once their PR is merged and issue closed, they may verify in the integrated environment (especially if there’s no separate QA). In maintenance cases, developers also investigate bug issues, possibly adding debugging notes or steps to reproduce in the Issue. Essentially, developers engage with GitHub Issues for every task and rely on PRs and CI to deliver quality code.
Tech Lead / Team Lead: Often a senior developer who not only writes code but oversees the technical direction and quality. In GitHub terms, they might be repository Admin or Maintainer. They help enforce standards by setting up branch protection (requiring PR reviews) and CODEOWNERS files for critical areas. They review many of the high-impact PRs and mentor others through PR feedback. The Tech Lead also helps triage issues – ensuring bug reports are valid, or refining feature requests into well-scoped GitHub Issues. They may define the labels taxonomy (standard labels for type, priority, etc.) and ensure consistency across the project. In this process, the Tech Lead plays a governance role on their team’s usage of GitHub: they might create the initial Project board (using an org-approved template) and make sure automations are set up. They also monitor the board for bottlenecks and facilitate improvements (if “In Review” column is piling up, they might jump in to review or allocate more reviewers). In cross-team contexts, Tech Leads of different teams coordinate via GitHub Discussions or an Architecture repo to make sure integration issues are handled.
Quality Engineer (QA/QE): If the organization has dedicated QA, their role is integrated via GitHub as well. QEs might pair with devs or work slightly downstream. They use GitHub Issues to log any defects they discover (during development or in production). For features under development, a QA might create a sub-task issue for writing test cases or doing test execution – or they simply ensure the definition of done on the main Issue includes QA verification. They might be added as reviewers on PRs to validate that tests are adequate or to run manual tests on a deployed environment (their approval can be required via branch protection or environment deployment rules). QEs also use the Project board to track testing status – e.g. they could add a label “QA Verified” or move an item to a “Validated” column after testing. Essentially, QA participation is through Issues (for test plans, bug reports) and PRs (reviews), all within GitHub.
Site Reliability Engineer (SRE) / DevOps: The SRE or DevOps experts focus on infrastructure, CI/CD, and reliability concerns. In our GitHub-only setup, they codify pipelines in GitHub Actions workflows. They might maintain a separate repository for shared Actions or workflows templates that teams reuse. SREs ensure that each repo’s Actions are set up to build and deploy correctly, possibly using organization secrets and environment protections. They also may be code owners on critical infrastructure files (e.g. deployment scripts, Dockerfiles) so that any PR touching those triggers their review. SREs can use Issues to track infrastructure work (like “Upgrade Kubernetes version” or “Improve logging in X service”) and those issues go through the same board process. For cross-team infrastructure changes, SREs can coordinate via an Issue in a central “Platform” repository or via Discussions. They also handle incident reports through GitHub Issues if appropriate (post-mortems, etc.), linking them to the code changes that resolve them. In summary, SREs contribute by automating the pipeline with Actions and overseeing operational aspects, all integrated in GitHub.
Security Engineer: Security teams are considered Enabling teams (per Team Topologies) that provide expertise. They leverage GitHub’s security alerts and may run additional scans via Actions. Security issues (e.g. vulnerabilities, audit findings) are filed as confidential GitHub Issues (possibly in a private repo or with limited access). The Security engineer works with dev teams by opening security-related PRs (for example, to update a vulnerable library or add a security feature) – these follow the normal PR process with the added requirement that a security expert must review or that tests for security pass. They might also participate in code review for high-risk areas (via CODEOWNERS or just by being requested on PRs). Security policies or threat models can be documented in GitHub wikis or markdown files in the repo, and discussions around them can happen in GitHub Discussions to keep a history. In interactions, the security team often operates in a facilitating mode (coaching dev teams on security) or as a service (providing tooling like a static analysis configuration that devs consume). All such interactions happen via the GitHub workflow – e.g. a dev team requests a security review by tagging @Org/SecurityTeam on an Issue. The security team then responds within that Issue or PR, ensuring no context is lost outside GitHub.
FinOps / Cost Management: Though less common as direct code contributors, FinOps (financial operations) specialists ensure the product is cost-efficient. They might use GitHub Issues to raise awareness of cost anomalies (for instance, if a certain feature causes cloud cost spikes, they could file an Issue “Optimize X to reduce cost”). They contribute by analyzing telemetry outside GitHub but bringing actionable work into GitHub as Issues for dev teams. They might also request certain changes in CI (like building cost reporting into deployments). FinOps folks would likely be part of cross-functional Discussions on GitHub (e.g. a discussion thread on “Cost Optimization ideas”), collaborating with engineers. This ensures even cost-related improvements follow the same track: discussed and tracked in GitHub, implemented via code changes (PRs), and verified in the pipeline.

Role-Based Permissions & Teams: GitHub’s native access control supports our role definitions. We recommend using GitHub Teams (within the org) to manage permissions and mentions, instead of ad-hoc individual permissions. For example, create a Team for each functional role in a project: dev-team-abc, qa-team-abc, sre-team, etc. Assign repository access at the team level (developers typically have write access to their repos; QA might have triage access to file issues; SRE and Leads might have admin or maintain permissions). Using Teams has two benefits: (1) Easier mention & notification – e.g. tagging @Enterprise/DevTeam sends notification to all devs in that team; (2) Consistency in permissions – when someone new joins or leaves, you just update team membership, rather than editing dozens of repo ACLs. It also aligns with Team Topologies idea of well-defined team boundaries: each team has control of their repo, and others contribute through those defined channels (like PRs) rather than direct writes. We also suggest avoiding giving individuals broad Admin access; instead, manage through teams to reduce risk.

Each team should also define its own responsibilities and interaction rules – essentially a “Team API” as described by Skelton & Pais (Team Topologies). In practice, this can be a markdown document in the repo (or an entry in the README) stating: the team’s mission, the primary point of contact, how others can request work (e.g. “open an issue and label it X”), service expectations, etc. This clarity helps other teams know how to engage via GitHub without confusion, reinforcing effective interaction modes (for instance, a platform team might say: “if you need a new API feature from us, file an issue in our repo with the ‘request’ label, we will triage weekly”). Such conventions ensure cross-team work stays within the GitHub system and follows a standard process, rather than ad hoc emails or meetings.

Automation and Templates for Efficiency

To minimize manual overhead, this methodology employs templates, automation workflows, and integrations – all using GitHub’s native capabilities – so that developers spend less time on “busy work” and more on actual development. Key automation and template strategies include:

Issue Templates & Forms: We provide structured Issue templates for common types of work. For example, “User Story/Feature Request,” “Bug Report,” and “Task/Spike” templates. Each template pre-fills the issue with required fields or questions. Issue Forms (GitHub’s YAML-driven form templates) can present a user-friendly form for reporting issues. This ensures even non-technical stakeholders can raise issues with all needed info (such as steps to reproduce a bug, expected vs actual behavior, environment details, etc.). Using these templates leads to higher quality backlog items and less back-and-forth for clarification. (See image below for an example of a GitHub Issue Form for reporting bugs, with fields for contact details and problem description.)

Example of a structured GitHub Issue Form for a Bug Report, ensuring standardized information is collected (reporter’s details, description of the problem, steps to reproduce, etc.). Such templates streamline triage and resolution by providing developers the context they need upfront.

Pull Request Templates: A PR template (stored in .github/PULL_REQUEST_TEMPLATE.md) prompts contributors to include certain information in every PR. For instance: a brief summary, the linked Issue number, testing notes, and a checklist for done criteria (e.g. [ ] Tests added, [ ] Documentation updated, [ ] Reviewed by peer). This standardization speeds up review and ensures essential steps aren’t missed. It also educates new contributors on the expectations. The template is automatically loaded whenever a PR is opened, reducing cognitive load to remember what to write.
GitHub Actions Automation (CI/CD & Project Workflows): We utilize GitHub Actions not just for CI/CD, but also for project management automation (sometimes called IssueOps). IssueOps is a practice of using Issues/PRs as triggers for automation. For example, we can configure Actions that respond to certain Issue labels or comments: if someone comments “/approve” on an issue, it could trigger an Action to add that issue to the Project board or even kick off a deployment. Concretely, our process includes Actions workflows such as:
- Auto-labeling and Triage: When a new Issue is created, an Action can auto-assign a label based on its content or template (e.g. label “bug” if it came from bug template). Similarly, it could auto-route it to a specific project board if we have multiple boards.
- Project Board Automation: While GitHub Projects has built-in automation for simple things (like moving a card when an issue closes), Actions enable more advanced flows. For example, when a Pull Request is opened and linked to an Issue, an Action can move the corresponding Issue card to “In Review.” Or if a PR is merged, an Action can post a comment to the Issue “This has been released in version X” and then close it. We can also auto-archive items on the board that were done >30 days ago to keep it clean.
- CI Pipeline: The Actions workflow for CI runs on each PR to handle build/test. If tests fail, Actions can update the PR with a status or even comment on the PR with summary of failures for visibility. If all checks pass, an Action could even automatically tag the PR as “ready-to-merge” (though actual merging would still be manual or via a bot if we decide).
- CD Pipeline: Actions deploy code after merges. This can integrate with cloud providers via their GH Actions plugins. We set up separate workflows for staging vs production. Manual approvals are done using environment protection rules (not an external tool, but within GitHub’s UI). This ensures deployments are auditable and traceable in the repository’s Actions log.
- ChatOps Integration: (Optional) While we aim to use GitHub exclusively, some teams may have Slack or Teams. GitHub Actions can send notifications to those channels on certain events (e.g. “Deployment to production completed” or “High priority bug created”). This uses outgoing webhooks from Actions. It keeps stakeholders informed in real-time without requiring a separate dashboard tool.

Using these automations, the workflow becomes self-maintaining to a large extent. The Project board doesn’t rely on someone manually updating every card – instead, actions like closing an issue or merging a PR automatically reflect on the board. This addresses a common pain point in project management: data gets out-of-sync. Here, GitHub is the single source of truth and the automation ensures status updates propagate instantly. As the GitHub Docs note, “Projects automatically stay up to date with GitHub data” for fields like assignees, labels, milestones, and we build on that with custom triggers for our specific process.

Built-in Project Workflows: GitHub Projects (v2) has built-in workflow automations that we configure. For instance: Auto-Status – when an Issue is moved to a certain column, set a Status field; Auto-Archive – items automatically archive when closed and 30 days old; Auto-add to Project – all new Issues in repo X with certain label go into the project. These are enabled via the project settings without code. We use these wherever possible to reduce the need for custom scripts. The guiding principle is to eliminate manual steps if a rule or trigger can do it, thereby minimizing the chance of human error (e.g. forgetting to move a card or notify someone).
Reusability via Templates: To help scale this process across many teams, we leverage GitHub’s ability to share configurations. We maintain an Organization-wide repo template that has the standardized .github folder (with issue templates, PR template, CODEOWNERS, etc.), a sample project board setup, and common labels. New project repositories can be created from this template to already have the structure in place. Additionally, GitHub Projects themselves can be copied or made into templates. We offer a Kanban board template pre-configured with our custom fields (like Priority, Status, etc.), so teams don’t need to build from scratch – they can just instantiate the template board and adjust if needed. This drastically reduces onboarding time for new teams (less configuration work).

In summary, by using templates for issues/PRs and automating routine tasks with Actions and project workflows, the process reduces overhead. Developers and leads are freed from “janitorial” PM tasks – they don’t have to manually update every status or remember to ping someone, as the system handles it. The result is a more efficient workflow that is also more enjoyable (people can trust the tooling to keep things organized). As GitHub’s own guidance says: “You can automate tasks to spend less time on busy work... The less you need to remember to do manually, the more likely your project will stay up to date.”. This ethos is at the heart of our methodology.

Onboarding Guidelines for Teams and Contributors

Introducing this unified GitHub workflow to multiple teams requires a clear onboarding plan. We tailor onboarding documentation primarily for developers, but also for all technical contributors (QA, SRE, Security, FinOps), since they will all interact via GitHub. The onboarding process ensures that new projects or teams can adopt the methodology quickly and confidently. Key elements of onboarding include:

Onboarding Documentation: A comprehensive guide (likely as a Markdown file in a central repository or an internal wiki in GitHub) is provided. This document walks through the process steps, perhaps in a tutorial style. It maps common tasks to how they are done in GitHub. For example: “How do I start a new feature? (Answer: create an Issue using the Feature template, then create a branch and PR… etc.)” or “How does our deployment work? (Answer: via GitHub Actions, see workflow.yaml in repo).” Screenshots or screencasts can be included to familiarize users with the Projects board and any custom fields we use. We ensure this guide is easily accessible (linked in each repo’s README or in the Project README).
Initial Project Setup Checklist: For a new project adopting the model (or migrating an existing project), we provide a checklist:
1. Repository Configuration: Create the repo (or use existing), then apply the org’s repo template which includes .github configurations (issue templates, PR template, label set). Verify that issues are enabled, and GitHub Actions is enabled.
2. Create Project Board: Create a new GitHub Project (if at org level or repository level depending on scope) using the “Kanban template”. This will populate columns and fields as per our standard. Add the repository (or multiple repos) to the Project so its issues can be tracked. If multiple teams share one board, ensure all relevant repos are added.
3. Define Team in GitHub: Set up a GitHub Team for the developers and link them to the repo with appropriate permission. Also set up teams for other roles if needed (QA, etc.). This ensures mentions and assignments work from day one.
4. Configure Branch Protections: Apply default branch protection rules: require PR review from at least one senior dev, require CI Action to pass, perhaps require linear history (if we enforce squash merges). Set up CODEOWNERS file if not already, to enforce critical reviews.
5. Add Environments (if deploying): Define “staging” and “production” environments in the repo Settings > Environments. Assign required approvers (e.g. Ops team lead) for production.
6. Integrations: If the team uses any integrations (Slack notifications, etc.), set up the necessary Action secrets or OAuth apps. However, as per constraints, avoid external PM tools – keep it mostly GitHub-native.
This checklist ensures nothing is missed during setup. Many steps can be automated or scripted for consistency (for instance, the org could have a tool or Action that creates a new project skeleton).
Training and Mentoring: Beyond documentation, we encourage an initial kickoff session for the team. This could be a live demo of creating an issue, going through to making a PR and seeing the CI pipeline run, and using the project board. We also might pair new team leads with an “Agile champion” or someone from an Enabling Team who is expert in the methodology. They can shadow the team’s first sprint/iteration to ensure the practices stick (answering questions like how to handle edge cases in GitHub, etc.). The enabling team could be a Developer Experience group that maintains the methodology – they effectively act as coaches.
Quick Reference Guides: For day-to-day ease, we provide quick references: e.g. a one-page “GitHub Workflow Cheat Sheet” covering common commands (like linking issues, closing keywords), our label meanings, and how to do certain operations (like revert a PR via GitHub UI if needed, or how to add an item to the board). This helps team members new to GitHub or new to some features (like Projects v2) get up to speed. It also includes any naming conventions (branch names, commit message conventions using prefixes or emojis as some teams prefer). The cheat sheet can be pinned in the repo or distributed as part of onboarding.
Inclusive of All Contributors: Onboarding docs explicitly cover each role’s engagement:
- For Developers: how to use issues and PRs, how to run pipeline locally if needed, how to write good commit messages and PR descriptions.
- For QA: how to file a bug in GitHub (with template), how to track test progress (maybe using task lists within an issue for test cases), how to sign off a story (possibly by adding a comment or label “QA passed”).
- For SRE/Ops: how to access pipeline logs in Actions, how to deploy if needing manual triggers (like rerun a workflow), how to add new secrets or config via GitHub.
- For Security: how to raise a security issue (maybe using a private repo or a special label that restricts visibility), how to review code for security in PRs, what security checks are automated vs manual.
- For External Contributors (experts outside the immediate team): we clarify that contributions should come via Fork & Pull Request if they are not in the org, or via branch & PR if they are internal. We outline the expected etiquette: e.g. discuss major changes in an Issue or Discussion first, ensure to follow the templates, and that the owning team will review and merge. This is essentially an “internal open source” model – outsiders contribute through the same GitHub PR mechanism, preserving team code ownership and knowledge sharing.

Given that experts from other teams may jump in (as per Team Topologies enabling interactions), the onboarding guide encourages that when collaborating across team boundaries, do so through GitHub. For example, if a platform team member wants to help a stream-aligned team, they might open a PR in the stream team’s repo or open an Issue suggesting the change, rather than directly making changes unnoticed. The guide emphasizes respecting the workflow: every change goes through PR and review, even if done by an outside expert, to maintain transparency and learnings for the owning team.

Team Topologies Context in Onboarding: We include a section explaining how our GitHub-centric process supports the Team Topologies model. We describe the four team types (Stream-aligned, Platform, Enabling, Complicated Subsystem) and note how they typically interact in our org. Then we map that to GitHub practices:
- Stream-aligned teams – own their repositories and boards; other teams should file issues or PRs for requests, not bypass the process. They collaborate with platform/enabling teams through issues/discussions when needed (collaboration mode), but in general consume platform outputs via documented usage (X-as-a-Service mode) to minimize hand-offs.
- Platform teams – provide tooling (perhaps a shared library or CI pipeline config) via their own repos or as GitHub Actions that stream teams consume. The platform team’s backlog is driven partly by stream teams’ requests (which are GitHub issues in the platform’s project). This is the “X-as-a-Service” mode: stream teams open an issue, platform team delivers a solution which the stream team uses with minimal further collaboration. If deeper collaboration is needed (e.g. on a new capability), they may temporarily work closely via a shared project board (collaboration mode), but that is time-bound.
- Enabling teams – like security or QA coaching groups – mainly communicate via discussions and short-lived issues. They might open Issues to suggest improvements or join planning discussions in the target team’s repo (facilitating mode). Our process encourages enabling team members to contribute by PR if it’s a one-time change (e.g. adding a CI check) or by providing guidance documented in GitHub (like commenting on an issue with recommendations, or adding to the wiki). We discourage them from injecting work in an unmanaged way; instead they should either pair with the team (collaboration) or provide a service that team can use. The Team API documents help here – they outline how an enabling team engages (like “Security team will do monthly threat model meetings, and all security issues should be reported in the security repo” etc.). All these still revolve around GitHub as the medium for record-keeping.

By educating new teams on these interaction modes, we set expectations that even cross-team work will be tracked in GitHub. This reinforces consistency and ensures that, for example, a platform request won’t be lost in an email – it will be a GitHub issue that is visible and managed.

Gradual Rollout and Support: Finally, the onboarding plan may involve phasing the adoption. A pilot team (or a new project) adopts the methodology fully. We gather feedback after a few cycles to refine the process docs. Then we roll it to more teams, possibly with the pilot team’s lead acting as an advocate. This peer knowledge sharing is important – it’s easier for developers to learn from fellow developers’ experiences. We also set up a GitHub Discussion (at the org level) or use an internal chat channel specifically for “GitHub Process Q&A” where people can ask questions or suggest improvements. This community approach helps sustain the methodology beyond initial onboarding.

Governance and Cross-Team Consistency

To ensure that this process remains effective and consistent across a large organization, we define a governance structure using GitHub itself as the backbone. The aim is to balance team autonomy with organization-wide standards – teams should feel ownership of their work but within a common framework that enables collaboration and quality.

1. Central Engineering Practices Guild: We establish an internal guild or Community of Practice that owns the methodology. This group (comprising senior engineers, product managers, DevOps, etc.) meets periodically to review how the GitHub-based process is working, gather feedback from teams, and evolve the standards. All decisions or updates from this guild are documented in a central repository (e.g. an “Engineering Playbook” repo on GitHub) and communicated via GitHub Discussions or Issues. For example, if the guild decides to introduce a new Issue label for tracking technical debt, they will announce it and create a Pull Request to the relevant config files in the template repository. This way, changes are version-controlled and transparent. The guild also curates the repository template and project template – updating them as best practices evolve (like if GitHub releases a new useful feature, e.g. a new field type or an Action, the guild can incorporate it).

2. Standardization via Templates and Labels: As mentioned, having a default set of labels, fields, and workflows is a key part of governance. We maintain a list of recommended labels (e.g. bug, enhancement, critical, question) and encourage all teams to use them for consistency. GitHub allows org admins to pre-configure labels in new repos, or we can script label creation via the API. Consistent labels make it possible to query issues across the org (e.g. see all critical bugs open). Similarly, we standardize fields in GitHub Projects: for example, every project should have a “Status” single-select field with values: “To Do, In Progress, In Review, Done” – even if teams use columns, the underlying field unifies nomenclature. Also a “Team” field could exist on issues if a project covers multiple teams. This standardization means metrics and reports can aggregate meaningfully across teams. The governance body ensures these stay aligned. If a team truly needs a different process, it’s discussed in the guild to see if it benefits others or remains an exception.

3. Code Review and Quality Gates: Quality control is enforced by policy using GitHub settings. Each repository should have:

At least 1 or 2 Required Reviewers on PRs (possibly more for sensitive code). Using CODEOWNERS ensures the right people review specific areas (e.g. any change to /docs might require a tech writer review; changes to infra/ require DevOps review).
CI Checks as Required: The main test workflow must pass before merge. Optionally, a coverage report or static analysis can be a required check if those are integrated.
Semantic Commit/PR Titles: We can integrate a linter that enforces conventional commit messages or meaningful PR titles, which helps in automated changelogs and consistent history.
No Direct Push to Main: All changes go through PRs (except perhaps emergency fixes by admins, which should still go through PR retrospectively). GitHub branch protection will block pushes to main and require PR process.
Security Scanning: If using GitHub Advanced Security, enable code scanning and secret scanning on the repo. Set these to run via Actions or daily. Any findings can generate Issues that must be resolved. Also enable Dependabot for dependency updates; those come in as PRs that the team should review and merge in a timely manner (this can even be automated if tests pass).

These rules are part of governance – they are configured initially and should be audited periodically. The governance group or an automated tool can run compliance checks (for example, using the GitHub API to list repos and see if branch protections are in place). Non-compliant repos get flagged and the respective team lead is pinged to correct it. Over time, this ensures high quality across all codebases. It’s essentially embedding quality in the process via GitHub’s features.

4. Cross-Team Collaboration Protocols: When multiple teams need to work together (e.g. a big feature that touches components owned by different teams), our methodology suggests a protocol to avoid chaos:

Identify a “lead team” or create a temporary shared project board for the initiative. That board can intake issues from all relevant repos, giving a unified view of progress. Each team’s issues are still worked by that team, but linked to the overarching feature.
Use GitHub’s linking capabilities: for example, Team A’s issue “Backend support for Feature X” and Team B’s issue “Frontend UI for Feature X” can be linked (using issue links or simply referencing each other) so anyone can navigate between them. Discussions that involve both teams can be held in a GitHub Discussion visible to both or on the parent Project board.
Align on naming and Milestone: possibly use a common Milestone named “Feature X” across repos to group issues, and track milestone progress. GitHub’s milestones progress view can show how close we are to completion.
If one team depends on another’s deliverable, they note it in the Issue (maybe using the new GitHub Issues linking as “blocked by”) and that automatically can reflect on the board. GitHub Issues now allow marking dependencies which is helpful.
The enabling or platform teams involved should act through consultation: e.g. the platform team join the feature’s Discussion and possibly contribute PRs, but respecting code ownership (the stream team reviews those PRs).

This structured approach, documented as part of governance, reinforces Team Topologies best practices – it prevents confusion about how work passes between teams. Essentially, cross-team work still goes through the same GitHub motions (issues, PRs) but with agreed communication channels (like a shared discussion or project). The governance group might collect lessons from such multi-team projects and update guidelines accordingly.

5. Metrics and Reporting Oversight: Governance also means ensuring we measure what matters. The process defines certain metrics to track (detailed in the next section). The governance team is responsible for reviewing these metrics periodically to identify bottlenecks or outliers. For example, if Team X’s cycle time is significantly longer than others, perhaps they need support or have process issues. Because all teams use GitHub uniformly, we can gather data easily via the API or GitHub Insights. Part of governance might involve an automated dashboard (possibly an internal tool or just using GitHub Projects’ insights) that leadership can review. However, we stick to native tools – GitHub Projects Insights can create charts and these can be shared with stakeholders. If a more complex analysis is needed (say calculating DORA metrics like deployment frequency), an internal script could pull from the GitHub API and output a report, but we wouldn’t integrate a non-GitHub product for it. The point is the governance group pays attention to these metrics to drive continuous improvement across teams.

6. Continuous Improvement and Feedback Loop: Finally, governance means adapting the process as needed. We encourage teams to give feedback openly – perhaps via a GitHub Discussion or by filing an Issue in the “Engineering Playbook” repo for any pain points or suggestions. Retrospectives can include feedback on tooling (“It’s cumbersome to update field X in Project board” etc.). The guild will triage these and implement improvements (like adjusting an automation or providing training on a misunderstood feature). In true DevOps spirit, the process itself is subject to iterative improvement. We track action items for process changes as GitHub issues in the guild’s repo, ensuring they are addressed.

By having this governance structure, we ensure cross-team consistency: every team speaks the same “language” in terms of process and tools, which makes it easy to collaborate and reallocate people if needed (a developer joining another team finds a familiar setup). Yet, teams retain some autonomy: they can still decide their work priorities, they can add custom columns or fields if absolutely needed, etc., as long as the core essentials remain consistent. The governance is not about rigidity, but about providing a framework in which creativity and efficiency can flourish without each team reinventing the wheel.

Metrics and Reporting (Using GitHub Native Analytics)

To gauge the health of our development process and drive improvements, we rely on metrics derived from GitHub’s native analytics. Because all work is tracked in GitHub, we can extract quantitative insights about our delivery performance and quality. We avoid external reporting tools; instead, we use GitHub’s built-in Project Insights, the Insights tab on repos, and custom queries to measure key indicators. Here are the main metrics and how we obtain them:

Cycle Time / Lead Time: This measures how long it takes for an issue to go from creation (or start) to completion. Using GitHub data, we can approximate this by capturing timestamps: when an Issue is moved into “In Progress” (we could use a Date field “Start Date” that an Action sets when the issue first moves out of To Do), and when it’s closed. GitHub Projects can filter items by date and we can create charts of duration. For example, we might use a number field “Cycle Days” that an Action calculates upon closure (by subtracting start date from close date). Then using Projects Insights, create a histogram or trend of Cycle Days over time. Alternatively, if using iterations, GitHub Projects with an Iteration field can help measure how many iterations items stay open. Our goal is to shorten cycle times, so we monitor this for regressions.
Throughput / Velocity: In a Kanban context, throughput (issues completed per week or per month) is analogous to Scrum velocity (story points per sprint). We can measure throughput easily via GitHub Projects Insights charts. For instance, we can set up a bar chart with the X-axis as weekly intervals (or iteration periods if defined via an Iteration field) and Y-axis as count of issues completed (filtering items where Status = Done in that week). GitHub’s charting lets us sum a numeric field too. If we use story point estimates on issues, we can create a Velocity Chart: X-axis = Iteration, Y-axis = Sum of “Estimate” field of issues completed in that iteration. This would show, for example, Iteration 1: 20 points done, Iteration 2: 25 points, etc. Over time, teams can see their average. Even without formal sprints, we can group by month to see monthly output. These charts are accessible on the Project’s Insights page and can be saved for reuse. We will likely include a “Done date” or use the closed timestamp for filtering. The LinkedIn example demonstrates creating such velocity charts within GitHub Projects.
Work in Progress (WIP) and Flow Efficiency: We keep an eye on how many items are in progress at once. Because everything is on the Kanban board, one can manually see WIP, but we can also track it historically. For instance, using the GitHub API, one could snapshot daily how many issues are in the “In Progress” column. A simpler approach: create a Project Insight line chart where X-axis is time (weeks) and Y-axis is count of items filtered by “Status = In Progress”. This requires that we use a Status field or consistent column name. This will show if WIP is trending too high, indicating context switching or bottlenecks. Flow efficiency (ratio of active time vs waiting time) is harder to get natively, but we can approximate by analyzing how long issues sit in each column. We may do this analysis offline by exporting project data (GitHub Projects can export to CSV). For governance, occasional deeper analysis might be done, but day-to-day, simple WIP count and aging of cards (highlight which cards have been in progress > X days) is sufficient.
Issue Burndown or Aging (for maintenance): Although Kanban doesn’t use sprint burndown, we still care about how quickly we address issues, especially bugs. We can utilize the Milestone progress view for any milestone (which shows X of Y issues closed). If we create milestones for, say, each release or quarter, we get a rough burndown view of that scope (GitHub doesn’t natively plot a burndown chart over days, but we can manually infer it or use external export). For a more Kanban-esque metric, issue aging reports can be made: list of open issues sorted by creation date, highlighting those older than, say, 30 days. This could be tracked via a GitHub query or an Action that comments on stale issues (GitHub has a common Action for marking stale issues). Ensuring old issues are either resolved or re-prioritized is a metric of backlog health.
Deployment Frequency: Since all deployments go through GitHub Actions, we can count how often we deploy. One metric could be “# of production deployments per week”. If each production deploy corresponds to a GitHub Release or a tag, we can count those. Alternatively, if we mark each production Action run with an outcome (could log to an issue or use an environment that records last deployed at), we can extract that. This metric ties to DevOps Research and Assessment (DORA) metrics for high performance IT. A high frequency (with small batch sizes) is what we aim for. GitHub’s Actions logs and possibly the environment page (which shows recent deployments) give us this info. We might automate a weekly summary (an Action that runs on schedule, checks how many deployments happened last week, and posts it on an internal dashboard issue).
Change Failure Rate / Quality: We want to know how often deployments or releases cause issues (rollbacks, production bugs). We can approximate this by tracking production bug issues count. For example, if within a week of a release, X number of high-severity bugs were reported, that’s a post-release defect rate. Using labels, we can mark bugs with discovered version. Or use the GitHub Releases to attach issues to a release. The Releases page itself can show associated issues closed (if linked). We can supplement with a convention: e.g. add a label regression for bugs that are re-openings or caused by recent changes. Then measure “% of issues closed that were reopened” or “# of regressions per release”. Another angle: track Actions workflow success vs failure. If deployments fail frequently (Action fails) that indicates pipeline issues or quality gates catching problems late. We can monitor Action run success rates over time.
Team-specific Analytics: GitHub’s repository Insights tab offers some basic stats: contributor activity, lines of code changes, etc. While not directly a process metric, it can highlight outliers (e.g. sudden drop in commits could mean a bottleneck). We focus more on project-level metrics above, but these are available for leads to review. Also, for PRs we might track Review turnaround time (how long a PR stays open). This can be derived by querying PR created vs merged times. If PRs are often open for many days waiting on review, that’s a process issue. A lightweight way to track: use an Action or external query to get average PR lifetime.
Using GitHub Projects Insights: A big benefit of the new Projects is the Insights feature with configurable charts. We will set up commonly needed charts for each team’s project, such as:
- Issues by Status (Pie or Bar) – snapshot of distribution in To Do / In Progress / In Review, to visualize WIP.
- Throughput Trend (Line chart) – e.g. issues done per week over last 8 weeks.
- Lead Time Distribution (Bar chart) – grouping of issues by how many days they took (could use a manually recorded field).
- Workload by Assignee (Stacked bar) – maybe to see if work is balanced or one person overloaded. This can use the built-in grouping by assignee.
- Bug vs Feature Ratio – e.g. count of issues closed that had label “bug” vs “feature” per month, to gauge how much effort is spent on maintenance vs new features.

These charts are created and saved so team dashboards are one click away for any stakeholder. They can even be shared read-only if needed.

Importantly, all these metrics are achieved within GitHub. We do not integrate an external analytics tool (which is a constraint). If something extremely custom is needed, we use the GitHub API and perhaps analyze data in a Jupyter notebook internally, but results can still be posted back to GitHub (for example, commit a Markdown report in the repo or comment on an issue with findings). The LinkedIn article example shows how one can estimate velocity using GitHub Projects alone, showcasing that GitHub’s native tools have become quite powerful for project analytics.

Reporting: How do we report these metrics? We envision a few channels:

Project Dashboards: Each team’s project Insights serve as their dashboard during stand-ups or weekly reviews. Team leads can also screenshot or export charts for quarterly reviews if needed.
Executive Summary: The PMO or the governance guild might maintain an organization-level dashboard (maybe using GitHub Pages or a Markdown in the playbook repo) summarizing key metrics across teams. This could be updated monthly. Since cross-project data isn’t automatically aggregated in GitHub’s UI, we could use a combination of GH API calls and manual collation to gather, say, throughput of all teams or highlight the top risk (like longest open issues).
Automated Reports: We can schedule GitHub Actions to post reports. For example, an Action could run every Friday to compile “This week’s deployments: 5 prod deploys, 2 failed, avg lead time 3 days, X issues closed, Y opened.” and then open a Discussion or issue with that info for record keeping. This is a form of ChatOps/IssueOps usage – making GitHub itself report on itself.
Reviews and Retrospectives: In sprint retrospectives or monthly Kaizen meetings, teams will use these metrics to discuss improvements. For instance, if cycle time spiked in last month, they dig into why (maybe a large refactor issue skewed it, or waiting on external approvals). Having the data readily visible in GitHub makes it easy to incorporate into these meetings.

By measuring and exposing these metrics, we encourage a data-driven culture. Team members can see the impact of changes (e.g. “after we introduced automated tests in CI, our bug reopening rate dropped”). It also ties into team autonomy: teams can self-improve by watching their own metrics. And because all teams share similar metrics, it fosters healthy comparison and best practice sharing (“Team A consistently completes more points – what are they doing that we can emulate?”). Since everything is derived from the unified GitHub process, we ensure apples-to-apples comparisons.

Finally, it’s worth noting that we avoid vanity metrics (like “number of commits”) and focus on those that reflect value delivery (cycle time, throughput, quality). The metrics framework is aligned to Agile/DevOps principles and provides early warning for issues in the workflow. And all of this is accomplished with GitHub’s native capabilities, proving we don’t need external tools to manage even enterprise-scale reporting.

Conclusion

In summary, this comprehensive methodology harnesses GitHub’s native ecosystem to create a unified software development process. By using GitHub Issues for tracking tasks and bugs, GitHub Projects for an interactive Kanban board, Pull Requests for code collaboration, Actions for automated CI/CD, and Discussions for open communication, we cover the full lifecycle from planning to release within one platform. The process is designed with Kanban agility at its core – emphasizing continuous flow, fast feedback, and adaptability – while still accommodating structured practices like milestones or iterations when needed.

We defined clear roles and responsibilities so every contributor (developer, QA, SRE, security, etc.) knows how to participate via GitHub, ensuring that even cross-functional inputs follow the same workflow. The inclusion of templates and automation significantly reduces the manual toil: consistent issue/PR templates improve quality of information, and GitHub Actions plus built-in project automations keep the board and status in sync without constant human updating.

To roll this out across multiple teams, we provide thorough onboarding guides and training, and we leverage an inner source mentality – sharing common templates and encouraging contributions via PRs from any team in a controlled way. We align the approach with modern Team Topologies principles, meaning teams interact in predefined ways (collaboration, X-as-a-Service, facilitating) which our GitHub-centric process naturally supports (through issues, PRs, and discussions rather than unmanaged channels). This ensures that as teams work together, they do so in a manner that reduces friction and maintains clear ownership.

A strong governance framework underpins the process: standardizing key elements (like labels, fields, review requirements) across teams and using GitHub itself to monitor compliance and improvements. Quality control is baked in via required reviews, CI checks, and code owner rules on every code change, yielding a consistent level of rigor across the organization.

Finally, we established a metrics and reporting strategy using GitHub’s own analytics features, demonstrating that we can measure velocity, throughput, lead times, and more without resorting to external tools. These insights will drive continuous improvement and accountability, as teams can see their progress in real-time and leaders can aggregate data for strategic decisions.

By adhering to this GitHub-exclusive methodology, the enterprise stands to gain greater transparency, improved collaboration, and streamlined workflows. Developers and technical contributors remain within a single ecosystem for planning, coding, testing, and releasing, which minimizes context switching and tool fatigue. The consistency across teams reduces confusion when coordinating large initiatives, and new team members or entire teams can be onboarded with minimal friction because the process is well-documented and standardized. Importantly, this approach scales: a small 3-person team can implement it and work efficiently, and a large program with 5 teams can also implement it, with GitHub enabling both autonomy and alignment through its features (e.g. separate repos/boards but the ability to roll-up information).

This unified process turns GitHub into the central hub of software development at the organization – a one-stop shop where ideas become code, and code becomes customer value, all tracked and managed in one place. With the flexibility of GitHub Projects and the power of Actions automation, the methodology supports continuous delivery and DevOps practices out of the box. It respects the constraint of using no external tools, yet it achieves the outcomes of traditional project management and ALM suites by cleverly using what GitHub provides.

By implementing this, the enterprise will have a repeatable, governable, and developer-friendly software development process that can evolve as GitHub’s platform evolves (we remain adaptable to new GitHub features). The end result is higher efficiency, better quality, and more predictable delivery – all accomplished with the tools that developers already love and know, making adoption a welcome improvement rather than a burdensome change.

Citations

Rules to Better Scrum using GitHub (Issues and Projects) | SSW.Rules

https://www.ssw.com.au/rules/rules-to-better-scrum-using-github/

Rules to Better Scrum using GitHub (Issues and Projects) | SSW.Rules

https://www.ssw.com.au/rules/rules-to-better-scrum-using-github/

Rules to Better Scrum using GitHub (Issues and Projects) | SSW.Rules

https://www.ssw.com.au/rules/rules-to-better-scrum-using-github/

Creating and editing milestones for issues and pull requests - GitHub Docs

https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/creating-and-editing-milestones-for-issues-and-pull-requests

Creating and editing milestones for issues and pull requests - GitHub Docs

https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/creating-and-editing-milestones-for-issues-and-pull-requests

Best practices for Projects - GitHub Docs

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects

Best practices for Projects - GitHub Docs

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects

Rules to Better Scrum using GitHub (Issues and Projects) | SSW.Rules

https://www.ssw.com.au/rules/rules-to-better-scrum-using-github/

Rules to Better Scrum using GitHub (Issues and Projects) | SSW.Rules

https://www.ssw.com.au/rules/rules-to-better-scrum-using-github/

Best practices for Projects - GitHub Docs

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects

Using environments for deployment - GitHub Docs

https://docs.github.com/en/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/using-environments-for-deployment

Managing environments for deployment - GitHub Docs

https://docs.github.com/enterprise-cloud@latest/actions/deployment/targeting-different-environments/using-environments-for-deployment

Best practices for Projects - GitHub Docs

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects

Best practices for Projects - GitHub Docs

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects

Best practices for Projects - GitHub Docs

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects

Best practices for Projects - GitHub Docs

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects

Best practices for Projects - GitHub Docs

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects

Rules to Better Scrum using GitHub (Issues and Projects) | SSW.Rules

https://www.ssw.com.au/rules/rules-to-better-scrum-using-github/

Best practices for Projects - GitHub Docs

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects

Best practices for Projects - GitHub Docs

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects Best Practices for Managing Multiple Teams with GitHub Issues and Projects (V2) · community · Discussion #137358 · GitHub

https://github.com/orgs/community/discussions/137358 Best Practices for Managing Multiple Teams with GitHub Issues and Projects (V2) · community · Discussion #137358 · GitHub

https://github.com/orgs/community/discussions/137358

Rules to Better Scrum using GitHub (Issues and Projects) | SSW.Rules

https://www.ssw.com.au/rules/rules-to-better-scrum-using-github/

Rules to Better Scrum using GitHub (Issues and Projects) | SSW.Rules

https://www.ssw.com.au/rules/rules-to-better-scrum-using-github/

IssueOps: Automate CI/CD (and more!) with GitHub Issues and Actions - The GitHub Blog

https://github.blog/engineering/issueops-automate-ci-cd-and-more-with-github-issues-and-actions/

Best practices for Projects - GitHub Docs

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects

Best practices for Projects - GitHub Docs

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects

Planning and tracking with Projects - GitHub Docs