I think it's a question of scale too. But I always read it as operations should be planned in/participate from the start. For example, I've been on successful

I think it's a question of scale too. But I always read it as operations should be planned in/participate from the start. For example, I've been on successful projects where a representative from "Ops" sits in on early project meetings, offering help on technologies and deployment. And then later helps with documentation, automation and deployment. I've also been on smaller projects, we're it might be just me doing dev and Ops,or where I do ops/architecture, and a few people help with development. The main thing I see,is that typical modern software is deployed as services, not packaged apps that the end user downloads,installs and run (or Ops download and install for them). At such a point,you need to consider security, backup, restore, monitoring etc. Not all services need high nines uptime, but needed uptime and how to achieve it should be factored into the requirements. I think one of the things many people get wrong with small projects/teams and scrum is to realize there may be more roles than people. You need the dba for the db, the network person for ingress, the dev for functionality. Sometimes that's one person with many hats. But ops is a "real job" - at some point, it will demand one or more full-time employees worth of time. For maintaining quality you might want specialization - for communication you might want to share responsibility across your team. Odds are, either way, for any given team/product/meeting some people should/will wear dev hat, others ops hat.