This is a note to illustrate how 2 cross-functional teams can collaborate in effective and transparent way. We'll use example of Dev and DevOps teams, however that can be multiple Dev teams.

Often DevOps and Dev teams are 2 separate teams, each with it's own leadership, backlog and priorities. But in order to get stuff done and work effectively together these 2 teams still need to communicate and collaborate on a problem

The idea of this note is to cover couple of ways how Dev and DevOps can engage effectively in an organization.

Goal

This insight explains interaction points and process for:

• planning DevOps work within Dev workstream
• process for tracking DevOps work within Dev sprints
• tools to support this process
• ownership of task at each particular step

Engagement modes

Current insight includes 2 different engagement modes to consider:

• Ambassador-style engagement
• Developer-driven engagement

Ambassador-style engagement

• DevOps engineer is part of the Dev team
• DevOps engineer participates in team’s ceremonies:
  • Inception
  • Backlog Groomings
  • Sprint Plannings
  • Stand-ups
• DevOps engineer is responsible for identifying any DevOps related work
• Work that DevOps engineer does estimated and included in a sprint
• DevOps engineer still communicates with peer DevOps engineers and they share details and outcomes of their individual work within dev teams

Pros:

• DevOps engineer is part of the Scrum team contributing to team’s goals
• Day-to-day engagement between Eng and DevOps
• DevOps ambassador follows team’s process

Cons:

• Time-consuming engagement from DevOps side
• DevOps engineer focuses and gives priority to tasks in a sprint (regardless of outages, other team’s issues, etc)
• DevOps engineer may not always have “work” to do within each given Sprint

Developer-driven engagement

• DevOps engineers are working within their own workstream
• DevOps team manages the backlog and priority of the tasks
• Dev engages with DevOps on a basis of "work required"
• Work is documented and tracked in a tool of choice
• Dev gets a "buy-in" from DevOps on a solution

Pros

• Lighter engagement between Engineering and DevOps teams
• DevOps owns their board and priorities
• Allows for better allocation of work

Cons

• Engineering need to get a "Buy-In" from DevOps for a particular ask
  • To mitigate the "Buy-In", usually there's a process for managing requests to DevOps

Process for managing dependencies

• Dev team determines a need to engage DevOps - during Backlog Grooming or Inception (early in process, BEFORE development has started)

  Outcome: A need to engage with DevOps

• Dev creates a ticket in Dev sprint (current or future) to track DevOps engagement usually 2 points

  Outcome: Jira ticket to track within Dev’s Jira project

• Dev engages with DevOps via either Slack or Zoom call (if necessary)

  Outcome: Ready to execute DevOps Jira ticket with Due Date that leaves no decisions to be made (result of collaboration between Dev and DevOps)

• Dev uses “Blocked by” links to indicate dependency between Dev tickets in backlog and sprints

Recommendation

Choose Ambassador-style engagement when you want to empower your team to do what's needed to solve a problem and you trust that they will do the right thing. Make sure to put the feedback loop between peer DevOps engineers so they can share knowledge and learn from each other.

Choose developer-driven engagement model when you have scarce DevOps talent, when you want to have tighter control for what is being done and how.

This choice depends on a culture and circumstances of your organization.