Scrum/Agile with Operations-heavy teams
I am the Scrum Master for two different teams in my organization. One is a fairly traditional Scrum team focused primarily on development. The other isn't so much a Scrum team. It has no designated PO, and roughly 85-90% of the team's time is Operations-focused (depending on the day/week). This team utilizes kanban to track process improvements, larger monitoring requests, and a few other items. Prior to being assigned as this team's SM, I was a part of the team as a Developer, and we had no SM (at least officially; I somewhat filled that role). The only Scrum ceremony we use is the Daily Standup, but we also refine our backlog each week and try to identify stories/items that are high priority.
As an SM, I don't expect to be able to serve this team in a traditional way, but I want to help them be as Agile and effective as possible. Any thoughts on how I might best serve this team?
I'd serve this team the same way I would any other team: observe how they work, collaboratively identify problems, and help the team to come up with changes to solve the most important problems, then repeat from the beginning.
From your description, it seems like one good change would be a regular retrospective-like event to help the team with identifying, prioritizing, developing solutions, and monitoring experiments in their way of working. This could be an event on a regular cadence (either time-based or linked to another type of event) or just-in-time. Whether that's the most important or valuable first change depends on the exact situation.
As an SM, I don't expect to be able to serve this team in a traditional way, but I want to help them be as Agile and effective as possible. Any thoughts on how I might best serve this team?
Is there a need for them to be agile and effective...or just lean and efficient? What complexities are there, in this work, that would make it worth doing Scrum at all?
Is there a need for them to be agile and effective...or just lean and efficient? What complexities are there, in this work, that would make it worth doing Scrum at all?
I think there is a need to be Agile. For one, our customers (all internal teams) operate within an Agile/Scrum mindset/framework, and they are often our partners as well. We need to be prepared to pivot as they do to continue providing excellent service. Our work centers around business-impacting incidents, so our focus often gets shifted to preventing similar issues from occurring in the future through better monitoring and communication. We, therefore, have to constantly adjust priorities based on potential business-impact.
I am convinced Scrum is not necessary or even particularly helpful with this team. I do, however, agree with Thomas's comment above about introducing more opportunities for inspection and adaptation. The team does this informally and ad hoc currently, but they often miss opportunities due to operational emergencies.
Having a post-mortem or root cause analysis session after an operational emergency is a really good way to introduce inspection and adaptation or a continuous improvement mindset to the team. It will make these emergencies a little more painful since there is more stuff to do after the situation is adequately resolved, but this pain can help the team find ways to prevent similar emergencies in the future. The trick would be to establish a threshold for these events that doesn't totally overwhelm the team, but provides sufficient opportunities to reflect and improve. If they are successful, then the threshold can be increased to be more sensitive since the number of emergencies should (hopefully) be decreasing.