Centralized ops group continues to manage all the environments, not just production but also pre-prod.
Liaisons attend the team standup meetings, integrating the needs into the ops road map and performing needed tasks.
Assigning ops liaisons allows us to support more product teams than the embedded ops model. Our goal is to ensure that ops is not a constraint for the product teams. If we find that ops liaisons are stretched too thin, preventing the product teams from achieving their goals, then we will likely need to either reduce the number of teams each liaison supports or temporarily embed an ops engineer.
Operations is better able to plan and radiate any needed knowledge into the product teams, influencing the work long before it gets into production.
Ops can gain awareness of the dev activities, enabling better planning and preparation. We create conditions where operations can solve our current team problems or future problems before they turn into a crisis.
Having ops engineers attend our project team retrospectives, they can benefit from learnings. Deployment or release in this interval, ops should present the outcomes and resulting learnings, creating feedback for dev. Feedback from ops helps dev better understand the downstream impact of decisions they make.
Work identified during retrospectives is improvement work, such as fixing defects, refactoring and automating manual work.
Improvement of daily work is more important than daily work itself and all teams must have dedicated capacity for this. Without doing this, the productivity will definitely stop at some point under the pressure of technical debt.
Operations is part of the value stream, thus we should put their work that is relevant to the product delivery on the kanban board. Visibility is a key component in properly recognizing and integrating ops work into all relevant value streams.