Tradicional para o Scrum: Como foi a minha transição e um exemplo prático em projeto de staff
Você pode estar se perguntando como posso fazer essa transição do modelo tradicional (cascata) para o scrum. de forma descomplicada nos meus projetos?
A ideia de falar sobre isso veio pela necessidade que tive de entender o assunto e poder aplicar nas iniciativas na área de staff, onde não trabalhamos com implantação de software. Mas antes de começar, vou resumir como funcionam as duas formas de gerenciamento de projetos.
O modelo Cascata (modelo Waterfall) segue uma sequência de fases definidas, em que só pode iniciar uma nova fase se a anterior estiver concluída e o cliente só pode te avaliar e testar ao fim do projeto e a solicitação de qualquer mudança é muito complexa em função do tempo. O modelo Scrum, ao contrário do cascata, permite que você possa fracionar o projeto em partes nas quais o cliente pode avaliar, testar e solicitar mudanças ao longo do projeto. No entanto, é importante você identificar qual se encaixa melhor com o modelo de negócio e gestão de sua empresa.
O Despertar
Terminei meu MBA em Gestão de Projetos no final de 2018, mas bem antes disso eu só ouvia falar em scrum e na minha concepção na época, era que só poderia ser aplicado em projetos de desenvolvimento de Software, até porque foi daí que surgiu esse framework, visto que a taxa de sucesso da entregas dos projetos eram muito baixas em função do tempo que se gastava construindo sem feedbacks rápidos dos usuários.
Em 2019, tive a oportunidade de participar de um projeto de software na empresa que trabalho, em que o objetivo era criar uma ferramenta interna, para o acompanhamento do progresso da carreira dos funcionários e dos times.
Nesse projeto eu tive contato direto com o Scrum, que foi o momento em que eu comecei a entender como funcionava esse framework e que, basicamente, na prática, era o que tínhamos contato com o cliente, frequentemente, momento em que ele avaliava os entregáveis que realizávamos, sempre nos dando feedbacks, sugerindo melhorias, mudanças e, consequentemente, nós reduzíamos o retrabalho que poderia ter sido gerado, caso o cliente tivesse que esperar por uns 6 meses pela entrega final, para avaliar e querer mudar algo.
Trabalhando com o Scrum, fiquei muito interessada no assunto e foi o momento em que tomei a decisão de estudar e, consequentemente, realizar o exame para a certificação, para que eu pudesse atestar os meus conhecimentos. Como eu sempre trabalhei na área de staff, eu queria aplicar o scrum nos projetos internos também e para exemplificar esse framework para os times, eu “Adaptei” o que cada item do scrum significava no nosso contexto, para que eu pudesse promover essa mudança de uma forma simplificada.
Na Prática
Vejam abaixo um exemplo de objetivo de entregável, no qual realizei as adaptações:
Na área de viagens tínhamos o objetivo de criar uma nova forma dos funcionários pagarem as despesas com viagens sem que fosse através de solicitação de adiantamentos, pois esse processo trazia vários problemas internos. Aqui vou exemplificar quem é quem em cada papel e os artefatos do Scrum, relacionado ao objetivo descrito acima.
Papéis e artefatos
- Ter uma opção para pagar despesas de viagens é o nosso Produto.
- Que pudesse já parametrizar com o sistema de reembolsos que já se tem, que fosse aceito em vários tipos de estabelecimentos e de fácil utilização são incrementos.
- O Gestor da área é o proprietário do produto e avalia e acompanha o que está sendo entregue.
- O Scrum Master é aquela pessoa que você sempre pede ajuda com os impeditivos do dia a dia, nesse caso era o Líder da área.
- Os Funcionários nesse caso são a parte interessada, porque afinal de contas eles que irão utilizar o produto.
- As pessoas envolvidas em entregar os itens do backlog (itens a serem entregues) é a equipe de desenvolvedores que, no nosso caso, é o time da área de viagens que estava envolvido nesse entregável.
- Criar processo de solicitação, de cancelamento, de políticas, de treinamento são o backlog do produto que nada mais é do que tudo que precisa ser feito.
Cerimônias
- Antes de tudo precisamos reunir o time e definir o que precisará ser realizado nas próximas duas semanas e qual será o entregável, no Scrum isso é chamado de Planejamento da Sprint, sendo que do resultado dessa reunião se tem um Sprint backlog (os itens).
- Daily nada mais é que uma reunião que é realizada diariamente para identificar se está tudo correndo conforme o planejado, aqui é o momento em que o Scrum Master trabalha com o time com o feedback loop, identificando impedimentos que possam vir a impactar o andamento do projeto e podendo ser corrigido o caminho para o qual se está indo e não deve ser usada como uma reunião de status ou para resolução de problemas.
- Para saber se estamos no caminho certo se faz uma reunião a cada 15 dias, que no Scrum tem o nome de Revisão da Sprint com todos os envolvidos para colher feedbacks sobre o que está sendo entregue, neste momento falamos sobre possíveis alterações e discutimos sobre novas ideias.
- Pensando em melhoria contínua e fortalecimento do time, é importante termos um momento no qual todos possam discutir sobre a Sprint que passou, o que foi bom, quais foram as dores que surgiram nessas duas semanas e qual o plano de ação para melhorarmos o que está ruim, assim todos em conjunto podem propor ideias para fluir com o trabalho e no scrum esse momento tem o nome de Retrospectiva.
- E por fim, colocar o cartão corporativo em produção no caso é lançamento do Produto.
Conclusão
Viram como fica mais simples entender quando quando fazemos as adaptações para o nosso cenário, mesmo que não sejam projetos de desenvolvimento de software?
A mensagem que eu quero deixar aqui é que podemos implantar o Scrum em processos, serviços, projetos, etc. mesmo quem atua em outras áreas ou outros tipos de negócio. De uma forma geral, esse framework nos proporciona analisar e mensurar para acompanharmos se estamos na direção certa, e se não tivermos, podemos realizar os devidos ajustes e corrigir sempre que necessário, sem causar grandes perdas financeiras.
O mais importante é que você e todos do time entendam mais sobre o conceito, pois assim será mais fácil a aplicação e a utilização no dia a dia em qualquer área ou setor de uma empresa.
Gerente de Pesquisa Clínica / LATAM / Liderança de Equipe / Gestão de Projetos / Docência
4 aMuito bom, Bruna!
Product Owner | Product Manager | APM
4 aParabéns Bruna! É muito importante ver esse tipo de conteúdo exemplificando a transição de metodologia em projetos que não são de software. Com certeza ajuda muito!
Process Mining | Data Analytics | Continuous Improvement | Project Management | Lean Six Sigma Green Belt
4 aQue legal ver um exemplo diferente assim, muito didático e mostra também o quanto a metodologia pode ser expandida para os mais diversos tipos de projetos. Parabéns pelo artigo e compartilhe mais casos 😊