Implementando Scrum – Mais um caso de Sucesso!

Olá a todos…     

Desde meu último post, venho de muita correria, muito aprendizado e também outros cases de sucesso na implantação de Scrum através da consultoria que venho  prestando…    

Entre alguns cases de sucesso, gostaria de destacar a consultoria que prestei para a empresa Orbisat, através do gerente de um dos departamentos de desenvolvimento da mesma, o Sr. Seido.       

 O CENÁRIO INICIAL…    

    

Após o conhecimento e o contato com algumas literaturas e artigos sobre metodologias ágeis no desenvolvimento de sistemas, o Sr. Seido começou a interessar-se pelo assunto e após alguns estudos conclusivos, começou a implementar,  juntamente com sua equipe algumas das práticas ágeis, como tarefas distribuidas em post-its, reuniões diárias e trabalho sobre interações de curto prazo de formas isoladas.    

O ambiente de desenvolvimento do departamento do Sr. Seido  tem se mostrado  bastante dinâmico, com o desenvolvimento de produtos com alto valor tecnológico, com programação  em baixo e alto nível  e integrações precisas de hardware, software e aplicações web.    

Sob indicação de nossa consultoria, o Sr Seido, no meio de um projeto altamente complexo, com muitas restrições tecnológicas e com um cronograma bastante apertado,  resolveu tomar uma decisão de inovar no meio da turbulência, baseado numa frase que ouvi bastante no decorrer dos dias, que é a chamada, filosofia do louco!!!    

“Louco é aquele que faz a mesma coisa todos os dias sempre esperando um resultado diferente!”    

Então para se obter resultados nunca antes esperados, o Sr. Seido resolveu fazer o que nunca tinha feito antes.    

Neste contexto então, iniciamos o processo de implantação Scrum para o departamento de desenvolvimento. Resolvendo então fazer coisas diferentes para se obter resultados diferentes!     

O fato mais interessante é que estavamos no meio de um projeto turbulento, com prazo apertado, com muita coisa a ser feita e agora mais uma atividade a ser realizada, implantar Scrum num ambiente dinâmico e complexo.    

Como sabemos, sempre quando estamos trabalhando com novas idéias, sempre existe o fator rejeição. E a primeira rejeição veio exatamente da maioria das pessoas da equipe do Sr. Seido, também imagine-se no lugar da equipe? Tanta demanda de coisas a serem feitas e agora mais um possível overhead de trabalho sem se entender completamente o seu significado e sua eficácia.    

Nosso primeiro passo foi entender o ambiente, levar os pontos a serem melhorados e implementar o Scrum de forma completa e eficaz, tendo como resultado final a completa satisfação do cliente, da equipe e também da organização como um todo.    

O processo de implementação das metodologias ágeis, para se mostrar efetivamente eficaz, deveria atender as necessidades da equipe, ajudando, e não gerando mais trabalho, nem burocracia e muito menos transtornos que fariam a equipe perder seu desempenho.    

INICIANDO A IMPLANTAÇÃO…    

Iniciamos o processo de implementação, com uma apresentação de introdução ao Scrum e suas práticas para a toda a equipe. Esse momento se tornou essencial para a o entendimento, para se compreender, interagir e enxergar os benefícios da nova proposta de trabalho e questionar muito sobre o assunto. Afinal eu estava sendo muito bem pago para responder todas as questões e eliminar todos os mitos e má práticas Scrum.    

Nesta introdução, foram abordados todos os passos que compõem o framework Scrum, juntamente com as práticas de estimativas, utilizando o Planning Poker, cerimoniais, entregas com valor de negócio para o cliente,  criação dos artefatos como o Kanban, Burn Down  Chart, relatórios e etc.    

Uma vez que toda equipe estava com o conhecimento teórico das práticas ágeis, estavamos na hora do start-up,  o momento de se colocar tudo isso prática e obter os resultados desejados.    

Definimos o Product Onwer e o Scrum Master com seus papéis claramente definidos junto com  a equipe e assim colocamos o Scrum para rodar.    

Para facilitar a implementação,  costumo num primeiro momento vestir minha roupa de ninja, colocar a faixa na cabeça e assumir o papel de Scrum Master, assim consigo mergulhar mais a fundo nas necessidades e dificuldades da equipe, alinhando as expectativas com o Product Owner e checando que todos os passos estavam sendo executados pela equipe.    

Inicialmente o Product Backlog já estava pronto, com suas funcionalidades documentadas e seu business value pontuado. Então começamos organizando a primeira Sprint.    

     

 Product Owner com a mão na massa    

Realmente, tudo estava muito novo e o volume de informação era grande,  mas a equipe estava motivada com a nova proposta, estavam sendo convencidos de que, de uma certa forma teriam beneficios, e que se não desse certo, pelo menos não traria nenhum revés. Até esse ponto, já estava bastante confortável o andamento das coisas.    

Em nossa primeira reunião de Sprint Planning, definimos o tamanho da Sprint, a funcionalidade com valor de negócio a ser entregue e as atividades que iriam ser pontuadas com o Planning Poker. Dentro do departamento, três projetos estavam em andamento, portanto separamos e criamos Sprints e artefatos separados para cada um como na figura abaixo.    

     

     

Kanban    

Um dos primeiros beneficios encontrados pela equipe, foi  a de se encontrar uma forma genérica de pontuação que permitiu ser pontuada tarefas das mais diversas, sendo elas tarefas em hardware, programação e baixo e alto nível tudo junto em um projeto só.    

Encerrada a primeira Sprint, fomos a criação dos artefatos, com a construção do Kanban, BurnDown Chart e etc…    

     

 BurnDown Chart dividos por projetos    

     

Depois do start-up e da Sprint em andamento, prosseguimos com as reuniões diárias, trabalho em equipe, feedback constante e etc.    

Uma das coisas que mais atormentavam a equipe de desenvolvimento eram as estimativas. Quanto mais se planejava os trabalhos a serem realizados, mais os prazos atrasavam e as coisas saiam do controle.    

Trabalhar com a pontuação do Planning Poker, baseado no conceito de Fibonacci, e pontuarmos pontos de esforço, nos trouxe uma melhor precisão nas estimativas, porém esta técnica mostrou que quanto mais praticamos e entendemos todas as variáveis, melhor se tornam as estimativas em equipe.    

    Equipe no Planning Poker    

Outro fator bastante importante quando trabalhamos com estimativas, é o entendimento do ambiente em que estamos trabalhando, este ambiente pode ser totalmente estável, linear, constante ou ser também totalmente instável, dinânico,  não linear. O que chamamos de ambiente caótico. A definicação de caótico é : “pequenas mudanças, e muitas vezes em muito pequenas variáveis causam resultados totalmente inesperados e indefinidos”.    

O que acontece muitas vezes é que utilizamos técnicas muita das vezes voltadas ao determinismo, casualidade.  Baseado em formulas exatas para resolvermos problemas que estão em um ambiente totalmente dinâmico e inconstante… sendo mais preciso…. inexato, onde isso não funciona.    

Essa é uma das razões pelas quais o emprego de metodologias ágeis tem se propagado com altos indices de sucesso. Pois foi criado para esse tipo de ambiente, muitas vezes caóticos e sem controle dos resultados. O segedo se torna obter  o entendimento do mesmo e tentarmos  influência-los de forma a conquistarmos nossos objetivos. Daí começarmos a falar sobre Empirísmo torna-se mais claro sob este entendimento.    

Esse é um assunto muito bem abordado pelo Fabio Akita… ficam aqui os créditos dele, um cara genial que vem fazendo interessantes estudos sobre o tema…    

Voltando… uma vez que estavamos implantando passo a passo, várias dúvidas eram levantadas e discutidas em grupo. A equipe começou a tormar ciência da necessidade de  feedbacks contínuos, interações em grupo e o auto gerenciamento proposto. A partir daquele momento, com o Scrum adotado, os problemas eram detectados com mais rapidez e a analise do ambiente fez com que as equipes entendessem o tipo de complexidade dos projetos estavam inseridos e a trabalhar com eles.    

Como estavamos trabalhando com três projetos, era muito visivel essa percepção, pois existiam projetos em que o desenvolvimento estava sendo realizado em um ambiente totalmente linear, com pouca ou nenhuma curva de aprendizado, onde  as  tarefas a serem realizadas eram de total dominio dos desenvolvedores. Nestes casos, as estimativas chegavam muito próximo do real com pouca variação.    

Nos projetos onde o ambiente se tornava dinâmico, não linear e complexo, sempre que havia uma certa curva de aprendizado,  onde a maioria das atividades nunca haviam sido desenvolvidas antes, como resultado, as estimativas sempre se tornavam-se  imprevisiveis e os resultados completamente inesperados, a equipe despendia de muito mais esforço estimado em algumas tarefas e em outras o esforço ficava completamente abaixo do estimado.    

Nestes projetos onde o ambiente era complexo,  o Scrum mostrou sua eficácia. A equipe a cada Sprint aprendeu a lidar com o ambiente,  levar em consideração o débito técnico, a importância de não ser influenciado na pontuação das estimativas e entender que a discordância muitas vezes é o ponto inicial para a sinergia. Onde a soma do todo é maior que a soma de suas partes.    

Outro benefício relatado pela equipe, foi a da “materialização” das tarefas, onde as mesmas se tornam tangiveis agora para a equipe, gerando assim  muito mais controle tanto no ambito visual como gerencial do Kanban. Também as reuniões de Sprint Planning, onde as tarefas são trazidas ao grupo e há uma longa discussão preliminar ao invés do recebimento de um simples Caso de Uso elaborado por um Analista de Negócio e exemplificado com pouco entendimento e compreensão.    

Tarefas no Kanban

Bem, o resultado final se mostrou acima do esperado, principalmente para a equipe, que antes recebeu com receio e aversão sobre o novo.    

No encerramento da consultoria, promovemos uma palestra para os demais gerentes da empresa sobre  introdução ao Scrum, com apresentações das práticas ágeis e o case de sucesso implementado dentro da empresa. Nestas palestras, houve testemunhos tanto do gerente como um dos membros da equipe exemplificando desde a rejeição inicial até  a aceitação e adoção da metodologia como válida entre a equipe.    

O final da consultoria se deu no término do ciclo de palestras promovido dentro da empresa com alguns dos outros departamentos já adontando algumas das práticas ágeis como o Kanban entre outros. Algo bastante significativo para nós, pois conseguimos atingir o objetivo de evangelizar, convencer e a incentivar outros gerente a conhecer e adotar práticas ágeis em seus departamentos.    

Bem, fica aqui apenas um relato dos fatos mais importantes deste case com muitas particularidades que podem vir ao encontro de departamentos semelhantes.    

Fica aqui o meu relato e também meus votos de sucesso ao Seido e todo seu pessoal!     

     

     

     

 

Advertisement