How do scrum teams handle cutovers?
So my product owner came to me asking how the team should manage cutover activities in scrum. I simply answered that the developers decide how they will execute the work since they have the skills and knowledge to build the product. After all they are a self-organizing and self-managing team. She did not seem too pleased with that response and said that it did not sound very agile? I then asked her why does she think that and she had no answer and tried to change the topic. I then asked her to elaborate on why she asked the question and she pulled up a cutover plan she created and wanted the team to use. I let her explain the cutover plan she created and asked her if she thought that giving the team a cutover plan that she created by herself with no input from the team was agile. She then said no and we started discussing another topic.
I just want to confirm if my response was sound? I've been a scrum master for awhile and I've never been asked any question about cutover activities before.
I'm not entirely sure what a "cutover plan" is but I am going to say that your response is heading in the right direction. The Developers decide how to turn Product Backlog Items into increments of value. However, the entire Scrum Team is responsible for achieving the Product Goal. I am going to make an assumption that at "cutover plan" has something to do with the delivery of product updates because that seems somewhat logical to me. In that case, I would expect that the entire Scrum Team would participate in defining those activities because it could involve work that is needed by the Product Owner and others outside of the Scrum Team.
This could be a good topic to bring up during a Sprint Retrospective.
I'm afraid that when I've encountered the term "cutover plan" it has, unfortunately, been a euphemism for go-live.
In Scrum however, once work meets the Definition of Done, the imperative is to release it. There is no excuse for putting empirical process control in delay.
The team aren't forced into making a release, if it is no longer the right thing to do once the Sprint plan has been followed. In a complex and uncertain world, business conditions can change overnight. The thing is, the Product Owner would need an excellent reason to stop the release of Done work from happening. It's that way round.
In Scrum, we go into Sprint Planning every time with the genuine, serious, honest-to-God intention of releasing at least one Done Increment of immediately usable quality that Sprint. Hence the cutover plan is the Sprint plan, every time.