Olá,
Neste post pretendo descrever minha experiência de como implementei a metodologia ágil SCRUM em uma das empresas por onde passei. Não estarei divulgando o nome da empresa pelo fato de não ter pedido autorização ainda.
O cenário dessa história é muito parecido com o cenário de várias empresas que desenvolvem sistemas e tem obtido pouco sucesso em cumprir os seus prazos de entregas, que sofrem com mudanças de escopo sempre no começo, no meio e quase no final dos projetos, gerando a falta de confiança dos sponsors e até mesmo de grande parte dos stakeholders do projeto para com datas, orçamento e etc…
A intenção aqui não é mostrar uma solução ‘bala de prata’ na implementação Scrum e metodologias agéis, e sim mostrar um caso de sucesso baseado no ambiente que encontrei em uma de minhas experiências felizes com o Scrum.
Tentei exemplificar em dez capítulos todos os passos. Separei os tópicos bem organizados para o caso de alguém queira ler apenas sobre um detalhe específico. Abaixo coloco a relação deles.
Contar todo esse caso, pode ficar um pouco extenso, neste caso, pretendo utilizar uma forma de resumida, sem entrar em muitos detalhes sobre práticas e gerenciamento para não causar cansaço… por favor….vá em frente… pois valerá a pena…. garanto que tem um final é feliz!!! 
Vamo lá então…
Passo 1 – O Cenário Inicial e o Desafio Proposto
A empresa pela qual fui contratado como gerente de projetos tinha o seguinte cenário:
- Uma equipe com mais de vinte profissionais, entre eles desenvolvedores, analistas de negócio e outro gerente de projeto;
- Os produtos eram sistemas de gerenciamento empresarial (ERP), sistemas de PDV(Ponto de Venda) e sistemas fiscais para empresas de pequeno e médio porte.
Os problemas apontados pela diretoria:
- Falta de visibilidade nos projetos, tanto de andamento, de cronogramas, escopos e desempenhos;
- Falta de uma metodologia funcional no desenvolvimento de sistemas e gerencial ;
- Impossibilidade de tomada de decisões referente a novos projetos, por não ter informações precisas do término dos projetos correntes.
O desafio a mim proposto:
- Dar visibilidade no progresso do andamento dos projetos;
- Dar apoio a diretoria na implementação de metodologias de desenvolvimento de sistemas;
- Gerenciar cronogramas e orçamento de horas do projeto;
- Criar relatórios com indicadores para cada projeto em andamento no departamento;
Como abordado, tinhamos um ótimo cenário para a implementação de desenvolvimento ágil, não?
Com todo este cenário, já sabiamos o que fazer e como fazer… faltava agora a aprovação da diretoria e a aceitação da equipe para dar o ponta pé inicial.
Passo 2 – Análise do Ambiente e o Plano de Ação
Ao receber a incubência por parte da diretoria, estava na hora de arregaçar as mangas e começar a dar resultado.
A primeira coisa que feita foi, analisar o ambiente e todos os projetos que estavam em andamento, quais estavam atrasados e quais projetos que estavam na fila para serem desenvolvidos. Com isso separamos o urgente do importante, que nesse caso estavam quatro projetos em andamento na casa, com mais três projetos na fila, resultado é que não haviam condições necessárias para cumprir com as metas já antes estabelecidas.
Depois da analise do ambiente, traçamos um plano de ação que funcionaria da seguinte forma:
- Apresentação de um modelo solução para o gerenciamento no desenvolvimento dos sistemas para a diretoria;
- Criar indicadores de performance para o andamento dos projetos;
- Evangelizar equipes em metologia ágil, o SCRUM;
- Ganhar a confiança dos stakeholders;
- Montar uma equipe exclusiva e 100% SCRUM em um projeto isolado dos outros;
- Obter o máximo de desempenho com pequenas entregas com valor de negócio;
- Obter sucesso exponencial na entrega do projeto;
Ufa! Grande desafio não? Mas o melhor ainda estava por vir!!! Particularmente eu estava muito ansioso para dar o ponta pé inicial…
Agora era hora de agir.
Passo 3 – Apresentando o Scrum para a Diretoria
Com todo o plano traçado, começamos pelo início, preparei uma apresentação sobre desenvolvimento de sistemas com SCRUM XP e fui diretamente apresentar para a diretoria da empresa. Realmente a empolgação era grande em trazer a melhor solução para os problemas da empresa, na minha opnião é claro.
Ao apresentar a metodologia SCRUM e seu funcionamento em um projeto em todas as suas fases, veio o feedback da diretoria.
A diretoria achou interessante toda apresentação mas….( isso mesmo, tem um ‘mas’ ai, pelo visto não foi um sucesso total) … acabaram ficando um pouco receosos em alguns pontos da metodologia, como a de pouca documentação, trabalho com escopo aberto e etc, enfim, todas aquelas dúvidas que os gestores tem em relação ao ´novo´, e me bombardearam de perguntas com dúvidas pra lá de excêntricas e formas de tratar cada parte do projeto.
Bom, o resultado foi o seguinte, me disseram para ir implementando aos poucos então e nesse contexto teria que ir trazendo os resultados sob doses homeopáticas e assim, convencendo vagarosamente sob resultados poucos expressivos.
Sai da reunião meio desmotivado, pois não tinha atingido 100% meu objetivo, mas como todo desbravador , resolvi ter uma atitude um pouco mais ousada juntamente com a equipe, enxergamos o copo meio cheio e resolvemos atuar por conta própria. Sabiamos o que tinhamos o que fazer, particularmente tinha know how pra isso, e sabia o resultado o resultado final, então resolvemos que implementariamos o SCRUM 100%, correndo o risco de obter um grande resultado.
No próximo passo eu conto todos os passos…
Passo 4 – Implementando o Scrum
Depois de todos os antepassos, chegou o momento de agir, de trabalhar duro e estrategicamente para obter o resultado esperado.
A primeira coisa a ser feita foi assumir o projeto mais crítico e mais importante da empresa. Se desejamos grandes resultados, temos que arriscar grandes desafios.
Com o projeto mais importante da empresa sob minha responsabilidade, estava na hora de montar uma equipe e blinda-la de quaisquer eventos externos ao projeto. A equipe foi montada inicialmente com quatro desenvolvedores e três analistas, um product owner e eu como scrum master.
Passei um dia no processo de evangelização da equipe, logo depois passamos a trabalhar, estava na hora de montarmos o Product Backlog, criar as histórias e setar as prioridades para assim criarmos nossa primeira Sprint.
A criação do Product Backlog foi feito com cinco histórias que se tornaram Sprints, cada uma mais tarde.
Abrindo um parênteses aqui, preciso fazer alguns adendos sobre práticas no SCRUM. Processos não são escritos em pedra, o Scrum é uma metodologia, ou melhor, um framework baseado no empirismo, ou seja, baseado mais na experiência do que em teorias e etc, etc, etc… Perseguimos sempre resultados.
Neste caso especifico, antes de começar a implementar o Scrum by the book, ou seja, a aplicação das melhores práticas, resolvemos utilizar processos que já estavam funcionando com algumas equipes, aperfeiçoando-os de modo a ter resultados eficazes. Implementando o framework de dentro pra fora.
Um dos processo que já estavam funcionando bem eram com os analistas, antes dos desenvolvedores iniciarem o desenvolvimento, os analistas levantavam todas as regras de negócio e assim traduziam em diagramas UML, essa prática é adotada pelo RUP que estava sendo utilizado antigamente.
Também, ao implementar o Scrum, surgiram muitas dúvidas da parte dos analistas de como e que tipos de artefatos (documentos)deveriam ser produzidos para se seguir um “padrão” para ser entregue aos desenvolvedores e etc. Minha reposta foi instantanea e pronta! Não há nenhum padrão para o desenvolvimento dos artefatos nesta fase inicial. Calma…. eu explico o porquê..
Não há padrão, mas existem algumas regras básicas que devem ser seguidas, sendo elas:
- A criação de qualquer artefato pelos analistas de negócio deve ser criado, quando se torna inviável sua exemplificação verbal, basicamente é isso;
- Quanto mais comunicação entre as equipes Scrum, menos será necessário a criação de artefatos;
- A adoção da criação de qualquer documentação de apoio será sempre requerida pela equipe, quando essa mesmo tem a necessidade de usa-lá.
Uau!!! Meio estranho não é? Mas é assim mesmo que funcionam as coisas em um ambiente empirico de desenvolvimento, um pouco mais a frente mostro como funciona isso no dia a dia. Mantenha sua mente aberta!
Passo 5 – A criação da Primeira Sprint – O Impacto
Essa parte necessita de um capítulo a parte, pois realmente foi a mais importante e a que gerou o maior impacto para a empresa.
Após os analistas terem levantado todas as regras de negócio e validado juntamente com o PO e após toda documentação estar pronta, estava na hora de iniciarmos nosso primeiro Sprint Planning.
Como eu havia dito antes, já tinha todo o plano na mente de como iria tocar todo o projeto em todas as suas fases, no entanto, estava na hora de colocar tudo isso em prática.
Nosso Sprint Planning iniciou como o Scrum sugere, toda a equipe estava reunida em uma sala de reuniões onde os analistas começaram a mostrar e exemplicar toda a regra de negócio contido na Sprint para a equipe, a explicação deveria ser bastante clara e objetiva, não deixando dúvidas para TODA a equipe, a mesma informação teria que ser passada por todos os membros. Encerrado este ciclo na reunião, dividimos a história, que no caso são funcionalidades do sistema, em tarefas e assim com essas tarefas faríamos as estimativas de entrega desse Sprint.
Para obter a estimativa dessa sprint, utilizei o Planning Poker, que é uma prática que auxilia na estimativa de histórias e tarefas baseada no consenso de pontos por esforço. Essa prática nos levou ao sistema de pontos de esforço por cada tarefa em questão. Com a equipe treinada na utilização do planning poker, os desenvolvedores jogavam as cartas com os pontos de esforço que achavam mais coerentes para cada tarefa, e assim ao final da estimativa de cada tarefa chegamos ao valor total de pontos de nossa primeira Sprint.
Mais um adendo preciso fazer aqui. Para que eu obtivesse uma pontuação muito próxima do real, meu dever era não influenciar na estimativa dos desenvolvedores, e também ter a certeza que o entendimento da equipe de cada tarefa estava com uma compreensão total das regras de negócio, quanto mais conhecimento da regra, melhor a estimativa. Parte do sucesso de se obter êxito, na minha opnião, depende desses dois passos fundamentais.
Bom, resumidamente, chegamos ao fechamento da nossa primeira Sprint, no qual finalizamos com 156 pontos de esfoço para término em 20 dias de trabalho.
Confesso que para padrões de agilidade desenvolvimento não estava bom, mas era a estimativa da equipe, e eu não poderia interferir, a equipe formada não estava totalmente integrada, eu era gestor novo na empresa, haviam outro colaboradores novos também e etc. Tinha muito trabalho a ser feito para melhorar esta performance.
Passo 6 – O Início da Primeira Sprint – O Passo Importante
Fechada a reunião de Sprint Planning, estava na hora de partir para os próximos passos e começar a ver os resultados.
Inicialmente, montamos o Kanban e logo a seguir montamos o Burn Down Chart para o acompanhamento do projeto. Encomendei um quadro branco grande e coloquei em um lugar estratégico na sala de desenvolvimento, e quando tudo ficou pronto, gerou uma grande expectativa para todos na empresa, passavam por ele, olhavam, faziam seus comentários e elogiavam a organização dos dados. O negócio estava começando a ficar bom!
Outro passo tambem que fizemos, foi montar grupos de e-mails, com grupos para toda a equipe, todos os stakeholders e um grupo para a diretoria geral.
Enviei um e-mail para praticamente toda a empresa, informando que no dia seguinte estariamos iniciando nossa primeira spint, com data de início e fim e o que seria entregue naquela interação. Neste ponto, eu estava criando o comprometimento da equipe com tudo o que fora acordado antes, o nível de responsabilidade aumentou e muito desde esse ato.
Bom, faltou dizer o que seria a entrega nessa Srpint não é? Bom, a entrega seriam todo o layout do sistema feito em Flex, com todos os módulos de autenticação e permissões de usuário no acesso ao mesmo, estavamos utilizando Java, com frameworks como o Spring, Hibernate e etc.
No dia seguinte, iniciamos o primeiro dia de trabalho dentro do prazo estipulado, coordenei todo trabalho e dei apoio a equipe nas dúvidas que iriam aparecendo, a equipe estava motivada e produzindo bem, tudo estava funcionando conforme o esperado.
No próximo dia, na parte da manhã foi onde ocorreu o nosso primeiro Daily Metting, onde eu fiz as três perguntas básicas para a equipe: O que você fez ontem? O que vai fazer hoje? Você teve algum impecilho?
E foram assim, todos os dias seguintes, o objetivo principal dessa reunião diária de quinze minutos foi fundamental, pois no meu caso, como Scrum Master da equipe, eu era o responsável direto para resolver qualquer problema que a equipe encontrasse no meio do desenvolvimento, os problemas eram diversos, acesso na base de dados, servidor de aplicação fora do ar, dúvidas em frameworks, lincenças de softwares expiradas, desenvolvedores travados com dúvidas e etc, etc, etc. Não importava o problema, eu era o responsável por não deixar a equipe parar de produzir, tinha que arrajar soluções eficientes para cada problema que ocorresse dentro do projeto.
Creio estar ai um dos principais papéis do Scrum Master, meu compromisso nesse momentoe era com uma coisa só, e essa coisa se chamava Burn down Chart. Meu papel era de evitar ao máximo que o resultado da produção real ficasse abaixo da estimativa. Eu constantemente estava enxugando toda a ‘gordura’ de tempo e eliminando todo o imprevisto que viesse a ocorrer. Chamado de ‘enxugamento do desperdício’ no Lean.
Passo 7 – Os Indicadores de Performance - A Maneira de Criar a Visibilidade do Desempenho
Bem, quando chegamos neste ponto, eu já começava a criar os indicadores de performance, que daria toda a visibilidade do projeto para a diretoria, mas eu queria ir um pouco mais longe, e assim não criei indicadores somente para a diretoria, criei indicadores também para a equipe, indicadores individuais, e um indicador para o Sprint. Como eu fiz tudo isso? Vamos lá, foi relativamente muito simples, que deu um grande resultado, isso se sucedeu da seguinte forma.
Com a pontuação do Sprint em 156 pontos com 20 dias de duração, fazendos os cálculos, a equipe deveria fazer em média 7,8 pontos por dia. Como tinhamos quatro desenvolvedores, cada um deveria fazer em média 1,95 pontos para atingirmos nossa meta.
Para alguns experientes em metodologia ágil sabe que nesses números há alguma coisa errada não é? É verdade! E essa incoerência sempre vai ocorrer em sprints iniciais com equipes novas e sem entrosamento. Isso é absolutamente normal.
Agora preciso encurtar um pouco a estoria para que isso não se torne um livro!
Querem saber o resultado final dessa Sprint? O resultado final foi que fizemos a entrega da Sprint com dez dias de trabalho, e não vinte, como a equipe havia estimado anteriormente. Fala sério, por mais que fosse meio óbvio para o scrum master, esse resultado de se fazer uma entrega antes do estimado é uma tremenda jogada de marketing, não é não?
No resultado final, a equipe fez uma média de 15,6 pontos diários, e a média individual ficou 3,9 pontos. O negócio estava começando a funcionar. Quando fizemos a primeira entrega do sistema com todo o layout impecável, com todas as autenticações e permissões, um dos diretores ficou emocionado, parabenizou toda a equipe e ficou bastante impressionado com o resultado.
Pois bem, a média individual da equipe variou bastante, pois tive desenvolvedores que pontuaram um média de 7 pontos, e outros que pontuaram uma média de 2 pontos. A partir desse ponto, começamos a entender, de uma maneira muito rápida em precisa o perfil de cada colaborador dentro da equipe e como contribuia para o progresso dentro do time.
Após o encerramento da Sprint, estava na hora de fazermos nossa reunião de Sprint Review. Nesta renião discutimos como foi o andamento da Sprint, o que tinha funcionado, o que não estava bom, lições aprendidas e etc. Nessa reunião eliminamos todo o que não funcionou e aperfeiçoamos o que não esta indo tão bem. Também davamos feedbacks diretos para cada membro da equipe e recebíamos também. Depois de terminado esta reunião, iniciamos o processo de mehoria contínua. A cada encerramento de Sprint faziamos as melhorias necessárias com base no aprendizado anterior e assim iamos melhorando nossa performance a cada nova Sprint.
Mais um adendo necessário. É sobre o feedback, uma das coisas que influenciaram bastante o comprometimento do grupo foi minha posição de deixar o grupo aberto para dar sugestões e opniões sobre qualquer coisa, que estivesse interferindo em sua produção. Minha teoria é de que se uma pessoa não tem abertura para dizer o que sente para você, essa pessoa facilmente poderá dizer isso pelas suas costas. Manter o dialogo aberto foi fundamental.
Passo 8 – As Sprints Seguintes e o Relatório para a Diretoria
Começamos a trabalhar na nossa segunda sprint, nesse momento os analistas de negócio já estavam com toda a documentação pronta para realizarmos nossa segunda Sprint Planning.
Até este ponto eu já começava a ter dados para começar a ter uma estimativa cada vez mais próxima do real. Eu sabia que minha equipe conseguiria até aquele momento obter uma média de 156 pontos em 10 dias. O que eu teria que fazer agora era somente medir as tarefas da segunda sprint com essa média. Eu ainda tinha o recurso de utilizar a média de velocidade da equipe, mas preferi deixar para a terceira sprint.
Adotando o padrão da sprint anterior, chegamos a uma pontuação de 189 pontos. De acordo com a estatística, a equipe conseguiria entregar esse sprint em 12 dias de trabalho. E assim foi.
Montei novamente o Kanban e o Burndown Chart, logo montado, dai sim criei particularmente um relatório para a diretoria com os dados da Sprint anterior e com as estimativas de entrega da Sprint que estava prestes a começar.
Neste relatório continham os seguintes itens:
- Resultado final da primeira Sprint, com sua antecipação na entrega de dez dias;
- Índice de funcionalidades que foram entregues e testadas;
- Índice final de performance da equipe, com a pontuação final e com a pontuação diária no decorrer dos dias;
- Índice final de performance individual de cada colaborador, com sua pontuação diária e sua média;
- Estimativa de entrega da segunda sprint;
- Lições aprendidas e melhorias aplicadas para a próxima sprint.
Foi realmente um relatório bastante esclarecedor de como realmente as coisas estavam dando certo, e o que realmente importa para a diretoria são números, e contra fatos não há argumentos, os números sobre a performance eram muito bons para o início do projeto, sem ‘maquiagem’ dos dados nem supervalorização, apenas o real.
Ao encerrar a segunda Sprint, mais uma boa notícia, terminamos em 10 dias, isso significava que estavamos melhorando nossa performance. Como isso se sucedeu dessa vez?
Bom, eu explico. Quando iniciamos a segunda sprint, eu tinha feito um acordo com a equipe para tentarem melhorar um pouco mais suas pontuações, uma vez que já tinhamoos informações da sprint anterior de qual a média de pontuação de cada membro da equipe. Dessa forma, o comprometimento da equipe aumentou ainda mais, pois cada um sabia da sua pontuação mínima diária, portanto ninguém poderia dar bobeira, pois senão ficaria atras dos demais na questão de performance. Nesse intuito, eu acabava tendo a situação sob controle, pois a equipe começava a se torna auto gerenciada, todos sabiam de suas responsabilidades, e se caso algo desse errado, na reunião diária, o problema era detectado e solucionado. O nível de interação entre os membros da equipe aumentou bastante, criamos algumas regras internas do tipo, não fica mais de vinte minutos parado em um problema sem chamar alguém para ajudar, fazer programação em pares e etc.
Com tudo isso, nossa equipe já estava fazendo praticamente 20 pontos diários.
Dado o encerramento da segunda sprint, seguimos os mesmos passos anteriores, realizamos o sprint review, iriamos dar inicio na terceira sprint, e agora os dados já estavam um pouco mais consolidados, então chegou a hora e utilizar as últimas ferramentas para fecharmos todo o ciclo inicial do Scrum.
Passo 9 – Scrum e o Cálculo de Estimativas
Essa parte farei o passo a passo o cálculo de estimativa para ficar bem claro como estavamos procedendo, pois a partir deste ponto, as coisas começaram a ficar cada vez mais automáticas.
Depois da nossa reunião de sprint planning da terceira sprint, chegamos ao valor de 220 pontos.
Tudo que eu precisava era de uma formula para avaliar a estimativa,existem várias existentes, no entanto escolhi uma mais apropriada para o momento e exemplifiquei abaixo.
Fórmula para velocidade estimada do Sprint:
(Dias de Recurso Disponível) * (Fator Foco) = (Velocidade Estimada)
Então, fui pegar informações da sprint passada:
Na Sprint anterior tinhamos quatro desenvolvedores disponiveis por dez dias, como abaixo:
Desenvolvedor 1 = 10 dias
Desenvolvedor 2 = 10 dias
Desenvolvedor 3 = 10 dias
Desenvolvedor 4 = 10 dias
———————————-
Total = 40 dias de recurso diponível para o Sprint (Lê-se recurso = dias)
Agora, eu precisava saber, qual era o fator foco, baseado no último sprint, e a fórmula segue abaixo também:
Fórmula Fator Foco do último Sprint:
(Fator Foco) = (Velocidade Atual)_____
(Dias de Recurso Disponível)
Usando a fórmula para o nosso caso, seria o seguinte:
Fator foco = 189 pontos de história => Fator foco = 4,725
40 dias de recurso disponível (Obs.: Recurso = dia. Recursos neste caso não são pessoas)
Com as informações na mão, agora posso calcular a estimativa para a próxima sprint.
Vamos ver a quantidade de recurso disponível para 12 dias com quatro desenvolvedores, no caso:
Desenvolvedor 1 = 12 dias
Desenvolvedor 2 = 12 dias
Desenvolvedor 3 = 12 dias
Desenvolvedor 4 = 12 dias
———————————-
Total = 48 dias de recurso diponível para o Sprint
Agora utilizo a fórmula para calcular a estimativa, segue abaixo:
Fórmula para velocidade estimada do Sprint:
(Velocidade Estimada) = (48 Dias de Recurso Disponível) * (4,725 Fator Foco) => Velocidade Estimada = 226,8 pontos por estória.
A conclusão é que para eu conseguir entregar a terceira sprint em 12 dias de trabalho, a pontuação dessa sprint não poderá passar de 226,8 pontos.
E assim fica exemplificado as fórmulas matemáticas que ajudam a fazer estimativas mais coerentes, de acordo com a performance alcançada pela equipe a cada sprint.
Passo 10 – A Prova do Resultado
Bom, terminada a terceira sprint, a metodologia já estava práticamente implementada. Mais uma vez melhoramos nossa velocidade e mantivemos até o final do projeto uma média de 23 pontos por dia de desenvolvimento.
Desde a primeira entrega do relatório e o acompanhamento diário do desenvolvimento do projeto, a diretoria se mostrou bastante satisfeita. Conseguimos dar a eles a visibilidade dentro de um projeto, e agora eles conseguiam tomar decisões referente ao projeto, como por exemplo:
Se a diretoria expressasse o desejo de acelerar o desenvolvimento do projeto, eles sabiam agora que teriam de aumentar a pontuação diária de desenvolvimento. O número de pontos necessários para serem aumentados, iria decidir o perfil do profissional a ser contratado, sendo os níveis junior, pleno e senior, e assim por diante.
Fazendo um tira teima, segue os dados do encerramento do projeto segundo a estimativa baseada na metodologia antiga e a mesma estimativa na metodologia ágil com SCRUM.
Metodologia antiga
Estimativa de horas : 7.000 horas
Metologia Scrum
Estimativa de horas: 2.900 horas (Esse mesmo projeto foi entregue com 3.000 horas)
Como comprovado, realmente os números impressionam. Para não estender muito esse artigo, não vou entrar muito em detalhes, mas é um bom motivo para um próximo post.
Depois dos dados apresentados, um dos diretores me chamou em sua sala, e muito satisfeito com os resultados, me nomeou para ser o gerente geral do departamento de desenvolvimento e ser reponsável pela implementação ágil em todos os projetos dentro da empresa.
Sendo assim, fiquei reponsável pelo departamento e implementei em todos os projetos o Scrum, com pequenas equipes e o departamento inteiro se tornou ágil. Desde aquele momento então a diretoria tinha o total controle dos projetos em andamento, e conseguiam fazer previsões claras em cima dos relatórios e etc.
Realmente, isso se tornou um divisor de águas dentro da empresa, e isso mexeu com a empresa inteira. Certa vez, vendo os resultados, a gerente do departamento comercial me chamou em sua sala e me disse que gostaria de dar a mesma visibilidade que eu estava dando nos projetos e etc e se teria como eu ajuda-la. Qual foi minha resposta? Claro que sim!
Apesar do meu forte skill em desenvolvimento de sistemas, de onde passei desde programador até por arquiteto de software, analista de negócios e etc, minha formação é em Administração de Empresas. Essa foi uma escolha muito estratégica dentro da minha área em tecnologia, quando iniciei os estudos, ninguém entendia nada, mas ao fim dos estudos, eu tinha as ferramentas necessarias para gerenciar qualquer tipo de projeto, inclusive no desenvolvimento de sistema, da qual tenho mais de onze anos de experiência, inclusive com uma certificação java programmer que tirei em meados de 2004.
No mesmo raciocício de ajudar minha colega de trabalho, o Scrum é uma vertente do LEAN, que é resumidamente traduzido para “enxuto”. É uma maneira de simplificar o modo de como a organização produz valor para seus clientes. Ela foca esforços naquilo que realmente faz a diferença e garante a competitividade da empresa no mercado, enquanto todos os diperdícios são eliminados.
Seguindo esta linha de raciocínio, consegui desenvolver um plano de ação para que ela pudesse implementar indicadores de performance dentro de seu departamento e assim utilizar um Kanban para ter o controle das tarefas, dando assim uma maior visibilidade para a diretoria.
Bem, realmente todo esse trabalho foi muito gratificante e exemplifica como funcionou para mim a implementação do SCRUM em uma organização.
Espero que tenha gostado e me coloco a disposição para esclarecer eventuais dúvidas. Meu e-mail é leandrots1@hotmail.com
Equipe no Planning Poker 
