Processes are an essential part of how teams and organisations operate, improve and grow. At their most effective they belong to the teams themselves, rather than being imposed on them by other people, representing the distilled and evolving practices of the team in question.
Teams nearly always need interfaces to other parts of the organisation and to customers, and these should be well-defined and understood. I like the concept of “link roles” that I’m pretty sure I have borrowed from Holacracy.
Here comes the health warning: don’t impose or expose your internal processes at these interface points; that’s the path to “computer says no” and frustration on both sides of the interface. Design your team interfaces to suit the people and teams you need to interface with. For example, customers typically don’t react well to having to follow a robotic and scripted process when what they really want is a conversation and a sympathetic resolution to their problem. There might be processes behind that conversation, but don’t expose those to the customer. Learn how to adapt your inner processes to the needs of the people interacting with your team via the interfaces you have declared. Some of these interfaces might be quick and transactional, others might be soft and exploratory.
So, the take-away is: think about your team and organisational boundaries like you would think about the boundaries of services in your code-base – and use the same principles to design them; e.g. don’t expose the inner workings of your class/object/function (team) to the caller (customer or stakeholder).