Implantação do SCRUM no laboratório - Parte X

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Sexta-feira foi o nosso último dia da dinâmica de uma semana de SCRUM.

Por algumas das pessoas terem provas e trabalhos, ficamos bastante desfalcados. Além disso, um dos grupos teve que deixar uma user story de lado, por solicitação do coordenador, para realizar outra mais crítica.

Nem todos acabaram suas user stories. Mesmo assim, tentei fazer algo parecido com um sprint review (demo), mas foi feito da forma mais precária possível... por quê? Como não utilizamos index cards para detalhar as user stories, não deixamos claro o que seria o DoD (definição de finalizado - Definition of Done). Ou seja, não havia como mensurar ou quantificar se aquelas coisas prometidas estavam feitas de acordo.

Ou seja, a sprint review foi apenas uma formalidade. Não funcionou para nada.

A retrospectiva, por falta de tempo, também tive que adaptar de uma forma mais ágil do que já é! Ou seja, não foi uma retrospectiva, mas quase um feedback.

Juntei todos na sala de reuniões, expliquei que aquela retrospectiva era uma das partes mais importantes do SCRUM e expliquei que teríamos aquela reunião em grupos, não com todos como estava sendo. Falei que são levantados os pontos positivos, negativos e as sugestões de melhorias para o próximo sprint. Então pedi para cada um falar.

De positivo, quase todos disseram que se tratava de uma metodologia legal. Concordaram que a comunicação melhorou bastante, além de todos saberem o que tem que ser feito. Dos comentários um foi bem interessante: um falou que achou o fato das tarefas terem responsáveis muito boa. Por quê? Pois assim as "mijadas" (broncas) seriam endereçadas às pessoas certas. Na hora eu não havia entendido que era isso que ele tinha dito, quem em avisou foi o meu colega, posteriormente.

De negativo, algumas coisas foram levantadas por desconhecimento do SCRUM e outra por falta de crença na mesma! Um falou que achava difícil levantar user stories até o fim do projeto, pois elas mudariam durante o projeto. Então eu expliquei que ele havia entendido errado, pois as mudanças são inerentes aos projetos, principalmente de TI. E mostrei que nós levantamos as user stories, mas só nos preocupamos em detalhar aquelas que iremos fazer. As outras podem sofrer as mudanças que quiserem! Outro comentário foi de que eu e o meu colega estávamos muito ocupados fazendo as reuniões, e isso tirou um pouco a nossa disponibilidade para conversar ou tomar decisões com eles. Expliquei, então, que essa semana foi anormal. Nós estávamos ocupados por estarmos coordenando a implantação e que depois, com os papéis definidos, isso acabaria e nós teríamos muito mais tempo.

O meu colega levantou a última questão que ele achou negativa, mas falou em "private" comigo, após a reunião. Ele disse que estava descrente quanto à reunião diária. Disse que muitas pessoas poderiam acabar "enchendo o saco" de ter que falar todo o dia. E sugeriu a idéia de termos as reuniões na 2a, 4a e 6a. Eu falei que posteriormente, se identificarmos esse descontentamento, podemos analisar isso. Mas, sinceramente, DUVIDO que alguém reclame... a não ser que ele próprio não tenha gostado :)

De melhorias, além de questões de infra-estrutura (um espaço maior para a taskboard e um armário para guardarmos o material dos projetos e também nossas coisas) eles deram duas sugestões para o SCRUM.

O primeiro foi para termos o chart burndown. Como eu esperava, a equipe que já tinha conhecimento do SCRUM, gostou de ter o gráfico representando o andamento. Eu defendo este gráfico, não tanto como informativo, mas mais como agente motivador. É realmente legal ver o nosso andamento graficamente!

E a segunda sugestão foi de termos uma coluna intermediária, após o "DOING", que se chamaria "VERIFY". Teríamos então:

TO DO --- DOING --- VERIFY --- DONE

O "verify" serviria para alguém, possivelmente o Scrum Master ou líder técnico, checar se a tarefa/user story estava finalizada de acordo com o esperado. É bem interessante e faz com que os SM se tornem mais presentes no dia-a-dia... mesmo que ele não tenha conhecimento técnico, pode dizer "ok" ou "não ok". Basta que as tarefas sejam explícitas no que irão produzir.

Então encerramos a reunião e demos fim à nossa dinâmica. Prometi para a semana que vem realizarmos as reuniões para levantarmos o product backlog e já começarmos os sprints. Principalmente porque a diretoria está ansiosa por resultados... mas isso é comum né?!

Muito saiu do meu planejamento durante essa semana. Não consegui praticar as coisas com as equipes como eu queria. Tivemos um review e retrospectiva muito aquém do que devíamos ter... mas no mundo de tecnologia, tempo é algo precioso. E eu tenho que considerar isso. Se não dá para usar o tempo como gostaríamos, temos que nos adaptar de alguma forma.

E com o décimo capítulo, encerro essa "Implantação de SCRUM no laboratório". A partir de agora, irei descrever o dia-a-dia, mas também voltarei a discutir outros assuntos.

Espero que estes posts possam servir como referência e até lições aprendidas para muitos que anseiam em implantar o SCRUM em suas empresas e organizações. Não temam! Se algo ocorrer errado, adaptem. Essa é a palavra-chave.

Abraços!