Tempo de leitura: 4 minutos
Eventualmente, você resolveu iniciar a adoção ágil na sua empresa e acreditou que o Scrum seria a melhor forma de fazê-lo. Algum tempo depois, você percebe que o Scrum não funciona e nem sequer sabe o porquê.
Talvez você se identifique com alguns dos problemas abaixo:
Tudo o que você vê é que as entregas planejadas não são realizadas. As prioridades e o planejamento da sprint já viraram um balaio de gato, tudo entra e sai da sprint a torto e a direito.
Aquela reunião de estimativas que o time usa pra estimar acaba virando pó, puro desperdício, pois o time nem mesmo sequer é capaz de identificar sua velocidade.
O Burndown, então, nem se fala, coitado! Anda reto o tempo todo. O que falar da reunião diária? Era pra levar 15 minutos e nunca conseguimos fazer em menos de 30 minutos… Nem vou mencionar que às vezes levamos mais de uma hora para realizá-la.
A reunião de planejamento também não funciona. O time fica o tempo todo discutindo sobre o que deve ser feito, com muita incerteza sobre o que fazer ou como deve ser feito. Quando conseguem ter uma prioridade para as estórias da sprint, acabam não fazendo a segunda reunião de planejamento do Scrum, pois acreditam que quebrar as estórias em tarefas vai ser desperdício. Afinal, o backlog costuma mudar durante a sprint, pois o chefe sempre chega com alguma coisa urgente pra fazer.
Não vou nem falar da baixa qualidade das entregas e do número de bugs imenso que que não para de crescer. Alias, nessas alturas, mais de 50%, quiçá 80% da capacidade produtiva da equipe é consumida por defeitos, em sua maioria no código, mas muitas e muitas vezes defeitos no modelo de negócio e também no processo.
Ah, esqueci de mencionar que essa equipe não faz testes automatizados porque “não tem tempo”.
Obviamente, essa equipe começa a ter uma série de problemas que afetam exacerbadamente não só a sua moral mas também a sua credibilidade. A pressão vem não apenas do cliente, mas também das áreas internas da empresa que acreditam que o problema é da TI. Mal sabem eles que num ambiente como esse, a TI não tem nem capacidade de compreender o valor ou nem mesmo o porquê daquilo que está fazendo. Nesse estágio, a TI parece mais uma pastelaria, onde um grita daqui: “sai um de carne….” e o outro grita dali: “não, faça a bananinha primeiro porque meu cliente está esperando a mais tempo”.
Você entrou em um ciclo vicioso, que mais parece um snowball gigante e crescente que só te leva ao precipício.
Se você se encontra nesse cenário, não perca mais nem um segundo!
A solução
Há um caminho seguro e conhecido para desenvolver produtos de software, mas ele é estreito e desafiador.
Se não houver a colaboração de todas as áreas e pessoas da empresa para que mudem seu comportamento e muitas vezes sua estrutura organizacional, o sucesso almejado não será alcançado.
O ponto de partida inicial é disciplina. Pare de atuar de forma flácida com o Scrum, fazendo que chamamos de Scrum but… “I do scrum but I don’t do bla”. Ex.: Eu faço scrum mas não faço retrospectivas. Eu faço isso mas não faço aquilo…
O scrum é um poderoso framework para organizar o trabalho de uma equipe. Se você seguir suas regras básicas e ter disciplina, certamente, terá mais sucesso. O Scrum sem rigor é simplesmente uma peneira com a qual você tenta se esconder do sol. Ele se torna como areia movediça, quanto mais você avança com um Scrum flácido, mais você afunda, gerando disfunções com um prejuízo muitas vezes incalculável.
Então a dica aqui é: siga as regras do jogo e tenha disciplina.
Bom pessoal, eu passei por isso tudo e muito mais, e encontrei uma forma de estruturar as coisas. Pasmem, o Scrum é só uma pequena engrenagem. Ele pode ser uma excelente ferramenta e você pode eventualmente também não precisar dele. Há vida além do Scrum! Na realidade, há uma infinidade de outras coisas que você precisa se preocupar.
Pense a respeito disso e leia os outros posts e vídeos do nosso blog. Se você quer ajuda, deixe seu email aqui ao lado. Você receberá todas as minhas atualizações e eu mesmo também responderei os seus comentários.
Link permanente
Excelente artigo e até engraçado! Quem já viveu de software já viveu uma ou todas as histórias usando Scrum ou não. Implantei em minha empresa e vivi tudo isso. Acredito no método é também em um profissional da empresa ou sócio dela que possa acompanhar tudo de perto e cobrar da equipe as mudanças que ele exige, não é fácil. Mas não conheço nada melhor!
Link permanente
Fala Cláudio,
Obrigado pelo feedback.
É verdade, as vezes é melhor rir para não chorar 🙂
Com relação a participação do sócio ou diretor, você tem toda razão, um processo de adoção ágil nunca funcionará sem patrocínio executivo. E o processo fica melhor ainda quando o executivo participa ativamente da transformação.
Link permanente
Olá,
A implantação do framework Scrum é um item muito mais da cultura organizacional do que simplesmente técnico e, o framework não pode levar a culpa de uma implementação mal feita.
Não basta disciplina mas sim, o comprometimento ao nível da Organização onde a postura deve mudar para aquilo que gere valor ao negócio, automatizando os testes sempre, automatizando as entregas, tendo uma infraestrutura ágil para atender as demandas por ambientes de desenvolvimento, testes e homologação.
Apoio as iniciativas Scrum + DevOps como uma das melhores configurações de trabalho mas, sem o comprometimento dos patrocinadores e das partes interessadas, nenhum framework no mundo será capaz de resolver os problemas.
Outro ponto fundamental é que as organizações precisam parar com a mentalidade que todo e qualquer projeto é possível em prazos “sacados da cartola”, seja por uma data especial para a empresa, a concorrência ou uma expectativa de mercado. Os gestores de projetos também precisam aprender a falar “Não” ou pelo menos dizer “precisamos planejar/entender o projeto antes de dar uma data”. Parece que existe um pânico pairando no ar onde, caso o Gestor diga “Não” ele será taxado de incompetente ou será demitido. Datas são metas e será necessário sempre avaliar se o escopo, custo, esforço, qualidade, risco e, por fim, o prazo, são compatíveis.
Por mais que pareça óbvio, e é mesmo óbvio, não é feito o básico e a caça às bruxas começa.
Pessoas da Engenharia de Software, principalmente, Einstein já dizia: Insanidade é fazer as coisas da mesma forma e esperar resultados diferentes.
Obrigado por compartilhar o artigo e sucesso!
Atenciosamente,
Sérgio Salles, PMP, ITIL, MCTS
Link permanente
Fala Sérgio,
Obrigado pelo seu feedback. Você destilou perfeitamente. O devops é essencial para atingirmos sucesso. O problema é que bem poucas empresas conseguem atingir o estado da arte no quesito entrega contínua. Muitas tem até uma dificuldade gigante que seu software seja usado pelo cliente final enquanto desenvolve. Nesse caso, o tão sonhado “production mode” fica muito longe.
Eu tenho a seguinte máxima “considere em produção desde o primeiro commit”. Ou seja, não se avança features antes de toda a infra pra testes, migração de dados e deploy automatizados estiverem prontos.
Quanto a dizer NÃO, esse é outro grande problema. Até porque no lean, temos que adequar a demanda à nossa capacidade produtiva e não ao contrário. Toda vez que quem dá o prazo é alguém diferente daquele que irá construir, haverá problema. Eu mesmo já trabalhei em empresas onde o comercial era inimigo do desenvolvimento. Parecia que tinha uma muralha da china intransponível no meio.
Já vi também projetos inteiros fracassarem por não saber dizer não. Se esse negócio não fosse tão sério, o lean não teria um princípio direto tratando disso, o Muri.
Muito obrigado pelo seu feedabck. Se puder compartilhe com seus amigos.
Forte abraço,
Samuel