Sempre abro meus cursos de Scrum dividindo a turma em grupos e pedindo que cada grupo elenque 3 perguntas que gostariam que fossem respondidas no decorrer do curso. Uma das perguntas que recebi foi um tanto interessante e curiosa: “Como unir o ITIL com Scrum?“.
No último dia de aula um dos alunos me cobrou: “Vitor, você ainda não falou sobre ITIL com Scrum!”. Resolvi então, entender melhor o contexto da pergunta, pois o ITIL cobre uma série de processos de gerenciamento de serviços de TI e precisava saber em qual processo esse aluno gostaria de visualizar a aderência.
O cenário descrito foi esse: “Minha empresa tem uma área de sustentação de TI que trata um backlog de melhorias acordado e priorizado com o usuário, porém, essa priorização sofre alterações toda hora, pois os incidentes são prioritários e geram atraso nos itens do backlog. Como o Scrum ajuda a resolver isso?”
Fiz algumas perguntas para entender o cenário: “Qual o volume de incidentes? A equipe que cuida desse backlog de melhorias, cuida também dos incidentes?”
Obtive como respostas: “Alto volume de incidentes e a mesma equipe cuida das melhorias e incidentes”.
Num cenário como este o Scrum em nada vai ajudar, pois por mais que se estabeleçam Sprints quinzenais (por exemplo), o Product Backlog será mutável, a prioridade irá mudar toda a hora.
Para funcionar precisamos quebrar alguns paradigmas: Sustentação é melhoria evolutiva eincidente é incidente. Vejo muitos gestores associarem a palavra sustentação à incidentes, problemas, erros: “Não vou pagar ou manter uma equipe só para acudir problemas”, dizem alguns gestores. Outros, por sua vez, incentivam esse tipo de prática: “Precisamos ter uma equipe para acudir o dia-a-dia”.
Minha opinião? Não existe essa história de “acudir o dia-a-dia”! Os sistemas devem ter vida própria, dependendo do mínimo de intervenções humanas. E a sustentação sempre irá existir, uma vez que todo o software vive em constante processo de evolução para atender as necessidades de negócio, necessidades dos stakeholders e necessidades tecnológicas. Um sistema não nasce e fica imutável para o resto da vida.
“Tá bom Vitor, mas como o Scrum resolve isso aí?”
Antes de falarmos em Scrum, vamos dar uma reestruturada na equipe. Alocar um ou dois membros da equipe para atuar somente nos incidentes. Atuar no incidente significa “tirar o boi do meio da estrada”, porém, alguém precisa garantir que o “boi não vai parar no meio da estrada novamente”. Quem garantirá? Cada vez que um incidente for detectado, cria-se um item de investigação e atuação na causa-raiz para ser catalogado no Product Backlog, priorizado pelo Product Owner e cuja atuação será do restante da equipe de sustentação.
O Product Backlog conterá somente itens de melhorias evolutivas e itens investigativos levantados pela equipe de incidentes. Estas melhorias e itens investigativos poderão ser desenvolvidos em Sprints fixas, gerando entregas únicas e evitando a geração de intermináveis e ingerenciáveis Ordens de Serviço ou RFCs (Requests For Changes).
Este conceito de pessoas atuando pontualmente em incidentes (“bombeiros”) e pessoas atuando em Sprints abrangendo melhoras evolutivas é abordada de maneira soberba no livro “Scrum e XP Direto das Trincheiras” de Henrik Kniberg.
“Mas Vitor, como não desmotivar o cara que fica resolvendo só incidente?”
É interessante utilizar um sistema de rodízio, cada semana ou cada mês troca-se o responsável pela atuação em incidentes. Porém, a abordagem de incluir um item investigativo no Product Backlog garante que a causa-raiz do incidente seja analisada e resolvida e, com isso, a tendência é que os incidentes diminuam drasticamente até não haver esta necessidade da equipe de “bombeiros”.
