Este é um post gigantesco. É a coletânea dos 10 posts que fiz sobre como introduzi práticas ágeis (SCRUM) no meu antigo emprego no laboratório de pesquisas. Apesar de longo, tenho certeza que vale inclusive a impressão. Eu não tive uma descrição tão minuciosa quando estive procurando ajuda 🙂 Espero que gostem.
Assim como fiz na minha experiência, na empresa, vou fazer o mesmo para o laboratório: irei descrever como irei implantar a cultura do SCRUM no dia-a-dia das pessoas. Muitas pessoas já me solicitaram para fazer isso, e acho que é uma ótima idéia e que irá inspirar muitos a fazerem o mesmo.
Só lembro que eu não sou o dono da verdade nem minha implantação está livre de erros. Irei adaptar apenas de acordo com a minha visão, no ambiente particular que trabalho e com meus objetivos específicos. Portanto, não sigam isso como “a verdade absoluta” ou “como fazer o mesmo na minha empresa”. Usem como referência, não como manual 🙂
Irei marcar a reunião de apresentação na próxima quinta-feira, o que me dá (contando apenas os dias úteis) quatro dias para me preparar.
A minha idéia será de realizar uma apresentação do SCRUM. Mostrar a nossa situação atual (caótica) e apresentar a proposta do SCRUM. E deixar bem claro o que eu pretendo atingir: comunicação, comprometimento e produto.
Além disso, minha idéia é acrescentar o conceito do gerente-minuto. Como irei fazer isso?
O SCRUM será adotado para gerenciar e organizar o laboratório. Mas os processos falam muito em EQUIPES e pouco em INDIVÍDUOS. É exatamente isso que eu quero atacar com os conceitos do gerente-minuto, que são três (para relembrar): objetivos para cada indivíduo, feedback positivo e “disciplinador” (ainda não achei um termo melhor).
Após a apresentação teórica, quero realizar uma dinâmica mais abrangente do que aquela dos aviões. A idéia é fazê-los praticar pelo menos dois sprints como o SCRUM sugere, ou seja, estimar, priorizar, fazer e repensar. Tudo isso usando os modelos de artefatos que irei criar (index cards, planning poker, burndown chart, post-its, etc).
Após a apresentação, a implantação se seguirá aos poucos. Não quero mudar radicalmente o dia-a-dia deles, mas sim fazê-los vivenciar aos poucos os benefícios do SCRUM. Dessa forma, menos informação eles terão para absorver e, por consequencia, poderão digerir com mais facilidade. Até porque eles notarão rápido os benefícios dessas mudanças.
Enfim, terei quatro dias para criar todo o “background” (ambiente) para que tudo flua da forma correta. E prometo descrever isso aqui.
Fiz uma lista de “coisas para fazer” até o fim da semana, para garantir o sucesso da implantação. Aqui estão elas:
– Marcar reunião. Aqui é óbvio, né. Se ninguém souber da reunião, não haverá implantação 🙂 Já sei os dias e horários em que a maioria pode.
– Mapear recursos, projetos e responsáveis. Esta tarefa tem o objetivo de identificar quais são os recursos reais do laboratório (sejam eles humanos ou físicos), identificar os projetos ativos (data de início e fim, objetivos) e responsáveis (stakeholders). Dessa forma já será possível, inclusive, identificar superalocação e subalocação de recursos.
– Mapear os canais de comunicação. Identificar o que está sendo usado para a comunicação nestes projetos, do tipo documentos, emails, avisos, quem responde pelo que, etc.
– Levantar infra-estrutura e solicitar o necessário. Aqui é simples: ver o que temos e solicitar o que não temos. E isso vale para o material SCRUM (flipchart, post-its, canetas, lápis, etc).
– Preparar material para a reunião. Ajustar os powerpoints da apresentação e da dinâmica sobre SCRUM 🙂
– Discutir as idéias a serem implantadas com os coordenadores. Isso é importantíssimo, né. Evitar que eu fale uma coisa na reunião e os coordenadores digam “Mas isso é impossível!”. Já pensaram?
– Preparar o coach. Aqui é um ponto bem importante. No começo, terei que ser uma espécie de “Master Scrum Master” hehehe. Vou ter que atuar junto a todos os grupos para mostrar, no primeiro sprint, o que um Scrum Master precisa fazer. Nesse período, pretendo já definir quem será o Scrum Master da equipe (caso consiga) e treiná-lo para assumir a função. Tenho quase que certeza que eu acabarei sendo o Product Owner, pois os coordenadores possuem pouco tempo disponível para dispender.
– Revisar a apresentação e dinâmica. Repassar tudo o que foi escrito e pensado.
– Encomendar comes e bebes para a reunião. Isso é importante, garantir um coffee break ou confraternização ao final da reunião. Motiva o pessoal.
– Apresentação. Minha idéia inicial: começar às 14h30 e até as 15h45 fazer a apresentação. 15 minutos para um break. Das 16h as 17h a dinâmica. Depois, a confraternização. Muitos tem aula as 17h30, então é preciso garantir que tudo corra nos conformes.
– Adequação do ambiente. Aqui é apenas revisar com cada grupo de projeto se eles entenderam o que foi passado, esclarecer dúvidas mais pertinentes e pessoais e preparar tudo para que na semana seguinte (terça-feira, já que segunda é feriado) já possamos iniciar nosso SPRINT ZERO (para ambientá-los).
Este é o meu plano. Pode ser que mude alguma coisa até o fim da semana. Mas acredito que será pouca coisa.
Santo de casa não faz milagre, já dizia o ditado.
Mandei um email para os meus chefes, explicando da apresentação e da dinâmica. Já fizeram cara feia pelo fato de durar o dia todo. “Acho que poderia ser 1 hora de reunião apenas”.
Ou seja, eles querem que eu apenas faça a apresentação, sem a dinâmica. Dai eu começo a me perguntar: alguém realmente vai aprender isso se não tiver contato nenhum com as ferramentas?
A dinâmica seria algo bem simples. Apenas algum problema para cada grupo resolver usando o SCRUM. Index cards, planning poker, reuniões, retrospectiva, taskboard… eles teriam pelo menos um contato com essas ferramentas.
Mas, já vou ter que adaptar isso para uma nova realidade.
O problema é que os males perduram. A visão de que “reunião é perda de tempo” é a pior delas. Quero só ver a cara dos coordenadores quando eu falar que teremos reuniões diárias, reuniões para avaliação, reuniões de estimativas, reuniões de retrospectivas…
Conseguir o comprometimento da direção. Esse é o maior desafio, sem dúvida alguma.
Bom, acabei fazendo do limão que me tocaram, uma limonada.
A dinâmica de 1h que estava prevendo para fazer durante o dia da apresentação, foi adaptada de uma forma mais eficiente e produtiva.
Eles terão a semana que vem inteira para escolher uma ou duas estórias dos projetos deles mesmo e irão trabalhar com o SCRUM em cima delas. Iremos fazer todo o ciclo em uma semana, e ao final eles estarão entregando alguma coisa produtiva realmente, ao invés de apenas um produto “fantástico” que eu iria criar para eles.
Vai ser bacana, eu acredito.
Só aquele meu cronograma para mapear tudo…. bom, foi pro lixo. Os incêndios do dia-a-dia prejudicaram bastante. Então o negócio é apenas fazer a apresentação e fazer o que eu tinha planejado (o mapeamento) na 6a feira mesmo.
—–
Hoje um dos guris levou outro puxão de orelha. Mas confesso que foi merecido. A pró-atividade dos funcionários é ZERO. Eles seguem estritamente o que passamos, sem questionar. O guri teve 3 semanas para fazer alguns testes. Eu esperava que ele tivesse bastante coisa, mas ele havia feito apenas CINCO testes!!! Enquanto ele ia apresentando, eu quase fui me escondendo na cadeira.
Um erro meu, de não estar mais junto a ele para cobrar e solucionar os problemas que ele teve, mas erro dele também pela pró-atividade e comprometimento em níveis bem abaixo do que o esperado.
Véspera do dia da apresentação!!! Os tambores batem (tum-tum-tum-tum!).
Hoje tirei o dia para fazer duas coisas:
E foi o que eu fiz. Chamei todos os membros e questionei eles o seguinte.
Por fim, listei as atividades de cada um desde janeiro até hoje (menos de 3 meses de trabalho, contando que fevereiro não houve atividades).
A idéia central era que ELES respondessem essas perguntas. Eu queria saber o que passava na cabeça DELES sobre os projetos em que atuam.
Meus caros leitores, vocês não tem noção do que eu descobri.
São seis “projetos” que o pessoal está envolvido atualmente. Destes seis, três NÃO são projetos, pois são demandas que surgiram para “tapar” algum buraco ou apagar algum incêndio.
Destes seis “projetos”, as pessoas envolvidas não sabiam a data de término em CINCO deles. E em DOIS eles não tinham certeza de quando havia sido iniciado.
Destes seis “projetos”, cinco deles não tinham certeza em quem eram os envolvidos. Dois deles não tinham certeza dos responsáveis. Um deles não sabia ao certo a equipe que atuava com ele. E um deles não tinha um gerente de projetos definido.
Destes seis “projetos”, em dois deles eles não tinham noção ao certo de quais eram os objetivos gerais do projeto (não sabiam ao certo o que tinham que entregar ou porque estavam fazendo aquilo). Quatro deles não citaram objetivos específicos, apenas o objetivo geral (criar um protótipo é um geral, por exemplo. Mas existem marcos até chegar lá…).
Por fim, destes seis “projetos”, identifiquei que em pelo menos três deles haviam pessoas que já haviam atuado em pelo menos outros DOIS projetos nesses 3 meses. E três recursos já haviam atuado em até QUATRO projetos em três meses.
Um recurso levantou que “felizmente” algumas demandas externas haviam diminuido. Outro citou que trabalhou em atividades ligadas à organização e outras que não tinham qualquer relação! E duas pessoas citaram que ao encerrarem um dos projetos anteriores, reclamaram da ociosidade! Isso mesmo, eles tiveram uma ociosidade forçada!
O que dizer disso?! A falta de comunicação é total!! TOTAL! É um problema crítico que deve ser resolvido para ontem!
Caros leitores, desafio vocês a pegarem um dia e fazerem essa mesma entrevista nas equipes das suas empresas. Vocês vão se assustar!! Mas ao mesmo tempo, vão ter TODOS os argumentos para implantarem a mudança que quiserem.
Depois de ter me assustado com o mapeamento, sentei na cadeira e ajeitei a minha apresentação de SCRUM. A primeira versão tinha 25 slides e tratava do SCRUM de uma forma bem macro, abordando apenas alguns pontos chave. A versão final agora tem 45 slides.
“O que, 45 slides? O pessoal vai morrer de tédio!” você deve ter pensado 🙂
Não. A idéia principal é a de não expôr o SCRUM apenas. Mas sim mostrar algumas situações. Então usei uns 10 slides só com exemplos de taskboards (para mostrar como é fácil identificar o status do projeto – 1o dia, 2o dia, ultimo dia, falta de prioridades, atividades não-planejadas que matam o projeto) e outras com exemplos ilustrando impedimentos, o backlog, o burndown chart… enfim.
Essa não é a versão final, pois preciso ensaiar para ver se consigo finalizar em uma hora. Caso contrário terei que cortar uma ou outra coisa.
Mas realmente acredito que ficará uma apresentação bem abrangente e bem dinâmica, apesar de aparentemente parecer longa. O negócio é refinar ao máximo as frases, para não ficar aquela enormidade de texto.
Tcharam!
O dia da apresentação chegou.
Procurei chegar um pouco mais cedo no trabalho, com o intuito de já ir adiantando a preparação do notebook, projetor, etc. O horário era 13h45.
Entrei no auditório do prédio, instalei algumas coisas e fui verificar se estava tudo ok com a apresentação. Nisso chegou o meu colega que será o meu braço direito nesse processo todo. Conversávamos enquanto eu fui fazendo isso. O horário era 13h55.
As 14h05 chegou a primeira leva do guris. Um terço deles, dá pra dizer. Às 14h15 chegou a segunda leva. Às 14h20 chegaram os coordenadores e o resto do pessoal.
Enfim, comecei a apresentação às 14h30. Era o horário que eu queria ter marcado, MAS um dos coordenadores falou que era melhor começar as 14h…….. :/
Como eu havia pensando, avisei no início que quem tivesse dúvidas que escrevesse em um papel para perguntar ao final da apresentação. Por que? Para evitar que gerasse uma discussão paralela no meio da apresentação.
A apresentação transcorreu muito bem. Achei que eu ficaria um tanto perdido em algum momento, mas o único momento em que eu senti que me embananei um pouco, foi ao explicar a tirinha dos “porcos e galinhas”. Acho que quis explicar demais e acabei enrolando. Nada que afetasse.
Procurei colocar algumas interações com o grupo, para não ficar só uma falação. E foi legal para descontrair.
Ah, como eu mencionei no post anterior, coloquei um slide para falar a respeito dos resultados da minha “pesquisa com os grupos” de ontem. Iniciei falando sobre o que é um projeto, quais são as suas características… e daí expus o motivo daquilo. Os problemas que estavam acontecendo lá e que eu consegui identificá-los de forma explícita.
A apresentação original estava prevista para ter 25 slides. Mas, comecei a perceber que ela poderia vir a ser uma referência para o pessoal, posteriormente, ao ser impressa em PDF. Portanto acabei deixando ela bem completa, com alguns exemplos para contextualizar situações.
No fim, acredito que todos ficaram satisfeitos. Notei, na prática, que alguns itens estavam fora de ordem (falava sobre previsto x realizado antes de falar de sprint, por exemplo). Mas, como eu disse, nada que fosse tão ruim a ponto de deixá-los perdidos.
Acredito que vendi o peixe! Ao final da apresentação, todos se mostravam dispostos a experiementar o SCRUM… a vivenciar a dinâmica que aplicaremos de 6a a 6a feira. Agora terei BASTANTE trabalho pois atuarei como coach, scrum master e product owner ao mesmo tempo! Mas vai valer a pena!
Conforme o planejado, hoje foi o dia em que sentamos com cada uma das equipes (definimos que teremos CINCO projetos) e definimos quais seriam as user stories que eles teriam que cumprir até o fim.
Usei bastante o conceito do livro “User stories” do Mike Cohn, onde ele geralmente descreve uma user story com “Um usuário [pode/deve] [fazer algo de alto nível]“.
Ou seja, por exemplo:
* Um usuário pode clicar em diversos pontos do simulador e o sistema irá apresentar as curvas paralelas resultantes (user story de um dos projetos)
* Um usuário pode passar diversos objetos na antena e o sistema apresentará os resultados
Como somos um grupo de pesquisa e a maioria dos projetos envolve hardware ou software de baixo nível, precisamos adequar as User Stories à nossa realidade. A maioria dos livros tratam as user stories como software de mais alto nível (“Um usuário pode buscar pelo nome de um livro” ou “Um usuário pode excluir seus dados pessoais”). Então temos que tentar buscar uma forma de manter o conceito mas adaptando ao máximo para nossa realidade.
Tivemos dificuldades em abstrair isso, mas é assim que a gente aprende: na prática!
Só não conseguimos fechar as user stories de dois projetos. Um pelos membros não terem aparecido e o outro pelo assunto ser muito técnico e nebuloso. Iremos tentar achar alguma parte que possamos apresentar.
Como eu disse, a idéia é fazê-los vencer essa etapa e não sofrer uma nova derrota.
No fim do dia, eu e o outro gerente também discutimos a respeito da nova ordem de comunicação que implanteremos. Atualmente vivemos algo como três níveis de hierarquia:
A comunicação correta seria de que os gerentes fossem um filtro. No máximo, na minha opinião, as equipes pudessem consultar os coordenadores. Porém, é comum os coordenadores comunicarem diretamente com as equipes, deixando os gerentes de mãos atadas.
Hoje ocorreu um caso típico: soubemos que um dos recursos de um projeto seria desligado do laboratório e passaria para a empresa parceira. Fomos os últimos a saber, lógico. E contávamos com ele para o nosso planejamento.
Com o SCRUM, a nossa idéia é criar mais um nível hierárquico, algo assim:
A primeira coisa que você deve estar pensando, aposto, é: “Pô, eles tão tornando tudo mais burocrático aumentando a hierarquia”. Eu digo que não, e vou explicar o porque.
Primeiro, pois na nossa visão estaremos deixando os coordenadores apenas como “chickens”, ou seja, apenas como envolvidos no projeto e não mais comprometendo eles. Nossos coordenadores já estão com demandas e tarefas até o pescoço! São professores universitários, então eles tem que orientar doutorado, mestrado, dar aulas, corrigir TCC, auxiliar os projetos, etc. Muita coisa!
Segundo, pois isolando os coordenadores, estaremos obrigatoriamente dando os poderes de decisão aos product owners. A minha idéia é que eu e o outro gerente nos transformemos nestes product owners. Porém, lógico, para que isso aconteça, precisamos encontrar scrum masters adequados. E isso vai demandar tempo.
Terceiro, pois criando mais uma hierarquia, deixamos muito mais difícil a comunicação direta entre os coordenadores e as equipes, o caso mais problemático. Em contrapartida, se isso ocorrer, serão DOIS níveis que estarão sem essa “informação”.
Ainda assim, acredito que valerá a pena. Os coordenadores trabalharão como clientes ou com os clientes. E caberá aos P.O.’s fazerem essa interface com as equipes e manter os clientes/coordenadores informados do andamento das coisas.
Enfim, iremos apresentar essa proposta de mudança e eu tentarei expôr exatamente o que estou dizendo aqui. Precisaremos do comprometimento deles em acatar isso e não cobrarem as equipes diretamente, ou pior, dar demandas diretamente. Os recursos estão ficando escassos, se eles nos jogarem mais este problema no colo, a situação ficará difícil!
Também ao final da reunião expressei ao outro gerente qual é o meu plano para longo prazo, para o laboratório: torná-lo uma referência dentro da universidade. Como iremos fazer isso?
Bom, um passo de cada vez. Primeiro vamos nos tornar produtivos. Depois vamos buscar começar a aparecer de alguma forma. Os frutos começarão daí.
Terça-feira de manhã iremos adequar todo o laboratório com as taskboards prontas para receberem as user stories e atividades. Terei que comprar todo material de escritório necessário. Vou bancar do bolso, nesse primeiro momento. Depois eu peço um reembolso 😉
Hoje foi o primeiro dia da “dinâmica”.
Primeiramente, me deparei com alguns problemas operacionais. Comprei post-its (rosa, amarelo, laranja e um reciclável) e três cartolinas. As cartolinas eram pequenas… só vi na hora em que coloquei os post-its. Nada que atrapalhe para ESSA semana, mas para as demais, teremos que rever algumas coisas.
Bom, eu havia marcado para a partir das 14h começar a fazer as reuniões. 15h30 começamos, pois foi a hora que pelo menos UM dos grupos estava totalmente presente.
Eu cheguei as 13h. Fiquei montando os cartazes (taskboards) e pensando em formas de usar o processo no resto da semana. Essa demora para o pessoal chegar já me desmotivou um pouco. Eu noto que eles estão bem interessados em aplicar o SCRUM, mas por ser um laboratório de pesquisa, eles também se sentem descompromissados. É a velha reclamação sobre comprometimento… é dose, não sei mais como usar argumentos e conversar a respeito.
Nessas 1h30 (+/-) que fiquei sozinho, refleti sobre a dificuldade que terei em atingir os objetivos que pretendo. Por um lado eu encaro isso como um baita desafio… é aquela coisa de que temos que superar os limites com os recursos que temos, de ser posteriormente reconhecido por isso. Porém, ao mesmo tempo bate o desânimo em contar com pessoas que faltam um pouco com suas responsabilidades.
Bom, a reunião acabou sendo prejudicada também pois não consegui imprimir as index cards e nem as cartas para o planning poker. Então foi tudo improvisado. O feriado me atrapalhou um pouco e hoje de manhã acabei não tendo tempo de fazer isso.
A agenda foi a seguinte, com cada grupo: homologar as user stories, estimá-las com planning poker (só para eles saberem como funciona), gerar as tarefas e depois agendar a daily scrum.
Definimos que os post-its terão as seguintes cores:
Cada tarefa deve ter no máximo 1 dia de duração, com no mínimo meio-dia. Definimos também que cada tarefa deverá ter só o nome da pessoa que está a fazendo, ou que responderá por ela (caso seja feita por mais de uma pessoa).
Um dos grupos foi bem tranquilo isso, o problema é que é o único projeto em que eu não tenho a menor idéia do que se trata. hehe
Outro grupo também foi tranquilo, pois foi o meu projeto piloto quando fiz a experiência com SCRUM. Eles já conhecem o processo todo.
Porém, nos outros três projetos tivemos problemas.
Um deles, decidimos momentaneamente tirar da dinâmica. Motivo? É um projeto muito teórico que é a base de dois mestrados e alguns trabalhos de conclusão e doutorado. Não consigo ver a geração de valor nele, pois haverá pesquisa, pesquisa e mais pesquisa. Seriam artefatos na forma de relatórios… além disso, as duas pessoas responsáveis não estão mais no laboratório, mas nas baias que servem para os mestrandos/doutorandos. Não teriam a taskboard à vista. E eles não possuem um gerente de projetos… essa é a figura direta de um dos coordenadores. Enfim, um projeto bem difícil e bem complicado para aplicar SCRUM. Decidimos deixá-lo de lado no momento.
O outro projeto trata exclusivamente de testes com RFID. Notamos que a pessoa (é uma só) responsável por ele, estava gerando testes e mais testes mas só obtendo dados… sem ter muita informação. Decidimos então criar cenários de testes, para homologarmos qual será a melhor configuração para captar o máximo de tags para aquela situação específica. Assim teremos um objetivo bem claro e um resultado aparente. Este projeto deixamos em separado, pois como envolve uma pessoa apenas, iremos exigir na dinâmica apenas um “ante-projeto” destes testes. Nada mais.
E por fim, o outro projeto problemático. O SCRUM prevê user stories onde representam a interação do sistema com o usuário. Exemplos de user stories, que achamos por aí:
“O usuário pode depositar o dinheiro na conta”
“O usuário pode definir quais são as pessoas que podem visualizar seu perfil”
“O usuário pode buscar livros pelo autor, nome do livro e código”
São coisas bem específicas e fáceis de visualizar. Mas um dos “projetos” é a criação de uma API para a comunicação da leitora de RFID com a antena. E aí, não há como definir um usuário!! Ficamos quase 1 hora em reunião para conseguir achar duas míseras user stories para essa situação e acabamos definindo coisas técnicas: a geração da versão em Java e a modelagem e estrutura padrão para as API’s.
Nessa hora eu percebi como o conceito de user story precisa ser aprofundado por mim e pelo meu colega que está me auxiliando. Ainda temos dúvidas nesse tipo de situação. Um sistema pode ser um ator? E no caso de envolver só hardware ou este tipo de camada mais baixa? Criamos uma user story grandona (que suba até o alto nível) ou deixamos ela mais técnica mesmo? Questionamentos, questionamentos…
Foi um dia de reuniões, pra variar. Agora irei disparar um email avisando os grupos dos horários das daily scrum. E vamos começar a ver o que acontece. Tomara que todos consigam cumprir suas user stories, pois não estamos exigindo nada demais.
Vou levantar um questionário e tasklist de itens que precisamos levantar para a semana que vem, para termos uma taskboard direita e também para lembrarmos de coisas para a retrospectiva.
Ufa, o dia hoje foi isso. Conversa, conversa e um pouco de desmotivação…
Será que consigo mudar? O tempo dirá.
Primeiro dia oficial do sprint relâmpago. Algumas constatações:
– Para a equipe que já possui experiência em SCRUM, utilizamos o tempo para levantar as atividades, coisa que ficou faltando ontem. Feito isso, encerrou-se a reunião com eles. Não há muito o que falar ou explicar.
– Para a equipe da API, a função principal foi introduzí-los ao daily scrum, sendo eles liderados pelo meu colega. Foi um momento interessante, onde eu apenas assisti e escutei. Ao final, expressei ao meu colega que ele cometera dois erros: discutiu assuntos técnicos DURANTE a reunião (o que fez com que perdessemos tempo nisso) e não questionou a equipe sobre impedimentos, esperou que eles mencionassem alguma coisa. Além disso, notei que a equipe falou como se estivesse se reportando ao gerente e não à própria equipe. Essa é uma das coisas mais difíceis de mudar no pessoal, mas acredito que eles vão estar sentindo a reunião como um acerto de ponteiros e não como um “report” em breve.
– Para a equipe de um projeto de HW, no qual o scrum master é o gerente da própria equipe, eu apenas expliquei rapidamente o que se tratava a daily scrum e depois solicitei ao scrum master que conduzisse a reunião, sendo que eu apenas escutaria e não iria intervir. Foi uma reunião bem bacana, para a primeira vez de todos ali! Levantamos tarefas não-planejadas, todos disseram o que fizeram e o que pretendem fazer para a amanhã e também levantamos o primeiro impedimento. Um dos projetos de HW foi modificado por um dos “chickens” (cliente) e ainda não foi reenviado para a equipe. Agora o scrum master terá já um impedimento para atacar. Depois da reunião, eles trataram rapidamente de assuntos técnicos, sendo bem como eu estava planejando. No final, um dos guris da equipe veio falar que a reunião estava sendo bem legal pois ele estava começando a se sentir mais “dentro” do projeto. Ele reclamou que no projeto anterior ele recebia demandas de diversas pessoas diferentes e no final era cobrado por uma delas só (que nunca estava pronta). É o tipo de pessoa que eu sempre escutei que “ele só fica na internet, não trabalha”, mas acho que agora começo a entender que era um funcionário que estava com a motivação a dois palmos abaixo do fundo do poço. E noto nele um foco de motivação com essa mudança. Felizmente! E fico feliz por ele dar este feedback.
– Por fim, para o outro projeto, de testes, estamos com mais dúvidas do que soluções. Não sabemos ao certo o que testar, pois para qualquer caso são muitas variáveis envolvidas. Então decidimos começar do básico… testar uma antena por completa para saber TUDO sobre ela: potencia, angulo de atuação, leitura, etc. Mas perdemos boa parte da tarde discutindo. Como é um projeto em que apenas UMA pessoa está trabalhando não seria justo exigir algo muito pesado. Então a “user story” deste projeto para esse sprint relâmpago será a criação do plano de testes documentado.
Hoje o meu colega, que está atuando comigo, também falou que uma das coisas que desmotiva aqui no trabalho é a falta de pró-atividade das pessoas. Ele comentou como é chato ter que estar sempre tendo que apontar os caminhos para os funcionários… lembram daquela máxima: “Traga-me soluções e não problemas”? Pois é, isso não se aplica aqui.
Mas isso é algo que quero atacar DEPOIS. Primeiro, é a comunicação.
Segundo dia de sprint. Hoje eu já tentei deixá-los mais “a vontade”. Em praticamente todos os grupos surgiram impedimentos, mas só em um deles era um impedimento real. Nos demais eu deixei claro a diferença entre impedimento e pró-atividade, novamente.
O grupo em que já possuia um gerente, eu os deixei à vontade para conduzir a reunião como eles preferissem. E acho que o resultado foi bacana… parece o grupo mais empolgado e ativo no SCRUM. Infelizmente é o grupo que possui mais atividades não-planejadas… muito por culpa do “cliente” deles.
Com o projeto de testes, em que temos uma pessoa só trabalhando, hoje fiz algo bastante interessante. Como se trata de um “gurizão” (como chamamos aqui no Sul 🙂 , já que tem menos de 20 anos, ele ainda está naquela fase de insegurança… o meu colega me passou uma idéia para os testes e eu apenas conduzi para que o responsável pelos testes tomasse a decisão que ele achava mais conveniente. Ou seja, ao invés de chegar e dizer “Ok, tu tens que fazer isso, isso e aquilo” eu apresentei duas propostas e na conversa com ele deixei-o decidir pela melhor. E ao mesmo tempo questionei o motivo. O resultado foi que chegamos na mesma conclusão. Foi o primeiro passo para a pró-atividade dele, espero!
No mais, foi um dia corrido, com diversas tarefas para fazer em paralelo. Exatamente o tipo de dia que eu gosto 🙂
Aliás, estou fazendo jus aquela máxima que diz que “o gerente de projetos é sempre aquele que nunca está na sua mesa”. Estou sempre em reunião, em contato com meus subordinados, colegas, chefes… ou seja, em total comunicação. Hoje eu posso dizer tranquilamente o que cada uma das pessoas está fazendo dentro do laboratório. Ou seja, aparentemente o problema de comunicação está quase resolvido!
Amanhã é o dia da sprint review (demo) e retrospectiva. Ainda não me preparei para isso, mas já avisei a eles que EU serei o cliente, ao contrário dos nossos chefes. O motivo? Não quero inibí-los… tanto os chefes quanto as equipes. Será difícil para os chefes entenderem que tivemos uma dinâmica nessa uma semana e, portanto, os “entregáveis” são bem pequenos, quase nada. E isso pode fazer com que passe a imagem de que o SCRUM não trouxe benefício nenhum. De lambuja, ainda pode desmotivar as equipes.
Avisei a todos, porém, que eu serei um cliente fiel. Vou dar o feedback necessário, conforme o que foi prometido. Eles tem que sentir, mesmo que de forma teatral, como seria a reação com um cliente caso eles não entreguem ou entreguem sem qualidade.
Vou até preparar um “checklist” de perguntas que farei 😉
Para a semana que vem pretendo criar o product backlog real com todas as equipes. Talvez demore a semana toda… mas gostaria de que na 5a e 6a pudessemos iniciar as reuniões já. Tomara que dê tempo.
Falei que ontem de noite eu havia enviado um email para os meus chefes explicando o porque eu preferia que eles não fossem os “clientes” dessa dinâmica, pois temia que eles não entendessem que utilizamos a semana para eles vivenciarem o SCRUM e desenvolverem pequenas partes dos projetos em que atuam.
Recebi essa resposta por email:
“(…) Como cliente ancioso, gostaria de ver o andamento dos projetos durante esta semana. Pois, acredito que a adocao da metodologia foi um plus no trabalho de cada projeto e entendi que os projetos continuariam fncionando a toda carga. (…)”.
A dificil arte de agradar gregos e troianos.
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.
[Crédito da imagem: Scrum – ShutterStock]
Flávio Steffens de Castro é empreendedor na Woompa (www.woompa.com.br), criador do crowdfunding Bicharia (www.bicharia.com.br) e gerente de projetos desde 2006. Trabalha com métodos ágeis de gerenciamento de projetos desde 2007, sendo CSM e autor do blog Agileway (www.agileway.com.br).
You must be logged in to post a comment.
