É possível minimizar os Riscos no SCRUM?
Começo como uma historinha rápida. No passado eu tive um time tecnicamente excelente, fora da curva mesmo.
Lá naquela época eu observei que nas primeiras Sprints haviam itens de backlog para estudo de documentação das API das aplicações que teríamos interface. Achei aquilo legal, e só isso! Não pensei em riscos.
Até que um dia eu assumi um novo time com “dificuldades”.
Em suma, iniciei como Scrum Master em um novo time que já estava no meio de desenvolvimento de um produto,
Na minha segunda semana com eles, no meio de uma Sprint, o time chegou apresentando uma dificuldade.
Para tentar entender e resolver aquele problema específico, a pedido deles, eu agendei um debate com alguns profissionais indicados por eles. Eram colegas da gerencia, parceiros internos.
Após esse fórum, foi percebido por esses participantes que eram externos ao time que o problema a ser resolvido não era esse específico, era algo maior, genérico.
Foi ai que caiu a minha ficha, veio logo na minha mente aquele time top do passado, lá da historinha no início desse artigo, agora tudo fazia sentido.
Nesse time atual, cade os itens de backlog de estudos de documentação e API da solução que fazemos interface?
Verificando na ferramanta de acompanhamento, acessando dados do passado, vi que em algumas Sprints aleatórias tinham uma ou outra História de estudo. Mas era de acordo com a necessidade.
Não haviam histórias de estudos nas primeiras sprints de forma a adquirir um conhecimento efetivo das APIS de integração já no início, o que proporcionaria diminuir a probabilidade de incorrer problemas futuros por baixo conhecimento.
Então o resultado era o atraso no desenvolvimento que atrapalhava atingir o objetivo de algumas Sprint, causando em Histórias não entregues sendo arrastadas para outras Sprints.
Chegou-se a conlcusão que boa parte dos problemas estavam vindo das dúvidas e inseguranças do time. Afinal, havia pouco conhecimento das API de um determinado produto que fazemos integração.
Isso diminui a velocidade e a previsibilidade. Isso criou vários problemas no caminho, antes e pós a minha chegada. Isso gerou sérios riscos.
Claro que nem todos problemas foram só por isso, mas resolvendo essa questão, reduziremos os riscos de vários problemas futuros, vindo desse gap de conhecimento sobre as API da solução a qual iremos integrar.
É muito claro que essas documentações e API devem estar dominadas logo no início, deuma só vez. Dessa forma, qualquer feature o time consiga implementar de forma eficaz sem dúvidas ou inseguranças. Mesmo que ainda se tenha que colocar uma ou outra história de estudo em outras Sprint posteriores.
Nossa solução:
Em síntese, aproveitando que a empresa trabalhava com Safe e estávamos próximos as semanas da Innovation Planning, organizamos uma semana de estudos de documentação e API, de forma que seja entregue pelo time um documento mostrando o estudo e a análise,
Enfim, eu preciso resaltar, que tivemos um patrocínio forte, por que eu com duas semanas ainda era muito nova no espaço, para fazer o time entender a real necessidade desses estudos serem realizados de uma só vez.
Em conclusão, esperávamos que após esses estudos, consiguiríamos diminuir os riscos de não realizarmos as entregas a tempo, e que fossem aumentadas a velocidade e a previsibilidade, pois estávamos com uma solução, que se demorassemos muito, tínhamos o RISCO de perder o time-to-market.
Informações sobre a autora: Jacqueline Viana é Scrum Master e é apaixonada por agilidade.
Sou a Marina Da Silva, gostei muito do seu artigo tem
muito conteúdo de valor parabéns nota 10 gostei muito.
Obrigada, fico muito feliz em estar contribuindo com a comunidade ágil!!!