Holacracy Community of Practice Archive, 2015-2019 Community Holacracy Web Site

Eric, I think a domain could work too if the process is clearly identified (e.g., all roles in the circle have clear accountabilities tied to that process). However, I find that a policy is clearer and more flexible when there isn't really a clearly identified process for a role to 'own'. 

For example, at HolacracyOne we have the following policy:

Standard File Formats: 
All word-processor documents, spreadsheets, and presentation slides created by any role for ongoing use or reference may only be stored in a standard file format that's approved by Operations.

Instead, you might think of adding a domain on Operations for "Standard File Formats for Documents", but it's not that clear — it's not a clearly identified thing, with clear boundaries, for a role to own without creating confusion.

In my example with the Scrum process, I think you're right, the Scrum process is a more clearly identifiable thing that a role can own. If the Scrum process was referenced elsewhere in the circle's governance, and everybody clearly knows what it is and they're already using it, then I might go with a domain. But it looks like Dien is trying to introduce Scrum to the team, so maybe they don't even have a clear process for coordinating effort between roles at the moment. In that case, I can't think of a clear domain for a role to own —"Process for software development and supporting activities" is too broad and elusive IMO. Even in the policy, it's quite vague — I would recommend that Dien adapts it to something clearer and more specific to his context. 

I don't know if I'm nailing the distinction I want to make, so I hope that makes sense to you...