[Dúvida] Orientação para aplicação do scrum

Olá, Willian!

Que interessante ver como você está tentando adaptar o Scrum às necessidades específicas da sua equipe de bioinformática! Vamos analisar suas adaptações e ver como elas se encaixam no framework Scrum.

1. Sprints Quinzenais: É totalmente viável ter sprints de duas semanas. O Scrum é flexível quanto à duração das sprints, desde que sejam consistentes e permitam entregas incrementais de valor.

2. Divisão da Sprint: Dividir a sprint em duas partes (serviços de rotina e desenvolvimento) pode ser uma boa estratégia para organizar o trabalho, mas é importante garantir que a equipe esteja alinhada com os objetivos da sprint como um todo. No Scrum, o foco é entregar um incremento de produto potencialmente utilizável ao final de cada sprint.

3. Backlog Adicional para Serviços de Rotina: Ter um backlog separado para serviços de rotina pode ser útil para organização, mas é importante lembrar que no Scrum tradicional, tudo deveria estar no Product Backlog. Talvez você possa considerar manter um único backlog e usar tags ou categorias para diferenciar os tipos de tarefas.

4. Reuniões Diárias Assíncronas: Esta é uma adaptação interessante. No Scrum, as reuniões diárias são importantes para a comunicação e alinhamento da equipe. Se a reunião síncrona não é viável, o formato assíncrono pode funcionar, mas é crucial garantir que a comunicação seja clara e que os impedimentos sejam resolvidos rapidamente.

Em relação a outros métodos, você pode explorar o Kanban, que é bastante flexível e pode ser mais adequado para equipes que lidam com fluxos contínuos de trabalho e tarefas de rotina. No Kanban, você pode visualizar o fluxo de trabalho em um quadro, limitar o trabalho em progresso e focar na melhoria contínua.

Espero ter ajudado e bons estudos!

Meus 2 centavos de conhecimento...

Willian, algumas sugestões que apliquei e funcionaram muito bem, equipe de 8 desenvolvedores.

Reuniões assíncronas me deram dor de cabeça muito rápido porquê o kanban (Trello gratuito e meu querido) dava a ilusão de que estávamos sempre evoluindo sendo que a turma de um horário estava sobrecarregando a outra. Sem contar que Daily simplesmente não funcionava direito, sempre terminávamos com algum assunto pendente esperando a turma seguinte.

Dividir a equipe em duas, sustentação (serviços de rotina) e desenvolvimento. Cada uma com sua sprint e um product backlog em comum (afinal, é o mesmo produto). Isso facilitou muito minha gestão e quando surgia uma emergência ou queria treinar um dev, eu realocava os profissionais entre as sprints. Como era um pessoal júnior, essa constância ajudou muito no aprendizado deles e no final cada um assumiu uma posição na equipe que se adequou melhor.

No caso da equipe de sustentação (serviços de rotina) o tempo extra pode ser utilizado otimizando e criando melhorias.

Para a equipe de desenvolvimento, eles não perdem o foco durante 1 semana atendendo outras demandas e a produtividade deve aumentar.

Nos dois casos, você tem mais controle e a equipe mais clareza do que precisa ser feito.

Outra opção, criar sprints de 1 semana para dividir melhor os momentos, assim o que foi feito na primeira semana (serviços de rotina) tem a review na sequencia e não ao final do desenvolvimento (quando todo mundo já mudou a chave na cabeça)

E falando como um PSM, Scrum puro é um unicórnio, muito difíicil a melhor opção ser exatamente o que está no GUIA, o próprio manifesto te incentiva a adaptar e testar, manter o FRAMEWORK vivo. Você pode não utilizar o SCRUM puro (Scrumbut) mas vai atingir seus objetivos.

Minha opinião, vale a pena ser teimoso e insistir em ter os eventos (Daily, Review, etc), esses são os momentos mais ricos em informação. Se precisar ajustar um pouco, sem problemas.

Espero ter ajudado e boa sorte.

Oi, Daniela. obrigado pela resposta

Oi, Thiago. Obrigado pela resposta. Vou estudar essa mudança para dois times independentes para ver como o time desempenha. Estou acrescentando alguns juniors na equipe agora. Acho que vai ser uma boa hora para esse teste.