[jrowley]

This sounds challenging! First I’d recommend kanban as opposed to scrum for the team, as the team is so large it is probably hard for them to be really working on a single scrum board effectively.

2nd I’d make sure the team had space to do their operational duties, possibly on a rotation so that other members can focus more on platform development. It can be tempting to try to minimize the operational work, especially when coming from more of a product oriented team. But it is important to develop good process to support the recurring operational labor.

Finally within that team of 12 I’d identify the most senior devs and tech leads and work with them closely on these process changes. Try to understand their problems and ensure they understand the goals coming down from the VPs etc.

Sorry if this is basic / already in play. Good luck!

[davideberdin]

Thanks for the tips! I appreciate them :)

I've been noodling for a while regarding Kanban. Where do you see the main advantages in using it?

[jrowley]

I think scrum is great when you have following properties: - clear goals - not a lot of interruptions - tasks / projects are particularly timeline sensitive. - you want to measure output and plan initiatives far into the future

Scrum can also have a fair amount of overhead, all of the rituals, eg pointing tickets, refining the backlog.

Also daily standup / status updates for 12 people can be a lot of time.

When you have support queue, operational responsibilities and regular dev work all going on in the same time, you might find you're spending a lot of time trying to ensure some amount of work gets done in a sprint, while support burden / operations supersedes estimates, which then pushes work to next sprint. So the sprint effectively becomes meaningless, because there is always lots of carry over.

Kanban does require a mature, self motivated team too though, since deadlines aren't as clear necessarily.