One of the best lessons I've learned as an engineer manager (and former engineer) is to let the engineers drive the process. Some teams will want to do scrum,

One of the best lessons I've learned as an engineer manager (and former engineer) is to let the engineers drive the process. Some teams will want to do scrum, some will want to do kanban, some will mix and match. Some of my teams have wanted a heavy process with actual planning poker cards, others just want a few standups and a simple retro. The important thing is to communicate the needs of the other teams they'll be working with, and not demand the methods. Team boundaries are in many ways like API boundaries -- as long as you implement the interface, who cares how you go about doing it. (As long as it isn't needlessly wasteful.) I'm happy to offer past experiences and ideas when teams get wedged, but in general I've found everyone is happier and more keyed in when they've built the process we're all going to be working by.