Use o Scrum e questione o Scrum!

Estou trabalhando diretamente com Ágil em desenvolvimento de Software faz pouco tempo, e nesse tempo me enfiei nas trincheiras do conhecimento, para entender todo esse mundo, conversando com agilitas do Brasil, seguindo agilitas munidas via Twitter, indo a eventos grandes além de fazer cursos e mais cursos na área. E mesmo assim ainda tenho muito o que aprender. Nesse período dei alguns passos com o aprendizado, compartilho aqui alguns com vocês.

A empresa, onde trabalho como Scrum Master, DígithoBrasil, começou a trabalhar com métodos ágeis entre 2010 e 2011. Usando como porta de entrada o Framework Scrum. Nesse tempo (Segundo relatos de colegas) a empresa passou por momentos muito difíceis quanto a aceitação da agilidade. Considero isso normal, dado que para ser ágil exige uma grande mudança de cultura e em geral, pessoas possuem certa resistência a mudanças.

Quando entrei na empresa em 2013, na minha visão, a resistência às práticas ágeis eram mínimas, assim como a cultura ágil na equipe de Desenvolvimento, pois já estava bem enraizada (J entrei no “Cenário Feliz”). Os times estavam trabalhando com o Framwork Scrum conforme descrito no “Guia Scrum”, entregando para o cliente a cada 15 dias, focando na necessidade do cliente, burndown, cerimonias, dentre outros; com a produtividade indo muito bem. Nesse mesmo período iniciou-se discussões acaloradas na comunidade Ágil sobre Scrum e ScrumBut e pude vivenciar essas discussões, chegando a algumas conclusões, “precipitadas”, de que não deveríamos mudar e defender o Scrum até a morte. Ainda bem que nascemos com a capacidade de pensar

No Agile Trends 2013, fiz um curso de CSM da K21, e os instrutores falaram algo parecido com: “use o Scrum e questione o Scrum” e no Agile Trends do mesmo ano, algumas apresentações tinham esse mesmo foco, “Por que Scrum”, “Questione o Scrum”. Cheguei a achar que era uma retaliação ao Framework Scrum e fui conversar com os palestrantes durante os intervalos e aprendi a questionar “O que você esta fazendo”, “Como esta Fazendo” e “Por que esta fazendo”.

Logo após o curso, durante o evento, ocorreram muitas discussões sobre o SCRUM e outros métodos ágeis. Essas discussões mudaram a minha percepção sobre esse a agilidade, principalmente no fator questione o que esta fazendo. Ao retornar para empresa com a percepção ampliada, passeia a aceitar e incentivar os questionamentos no time.

Com essa nova postura as pessoas começaram a envolver-se mais no processo, começaram a pensar como poderiam melhorar a forma de trabalho e deixar de ser mecanizados por um processo pré-definido e sim pelo processo que melhor atende ao time.

Um pouco do que fizemos:

Com essa abertura, o time começou a questionar, e muito, então partimos para quem vencia nos argumentos e na segurança “Tudo com saúde, no Stress”. Porém tomamos um cuidado, fazer Baby Steps de Mudança, algo que depois o Samuel Crescêncio apresentou como um ótimo caminho para a mudança.

Então o primeiro cara a morrer foi o Burndown em um dos times que trabalho. O time venceu meus argumentos da necessidade do Burndown então, bora experimentar tirar ele por 2 Sprints; resultado, já se passaram mais de 15 Sprints e o time falhou 1 única vez nesse período todo de entregas.

O Segundo a morrer nesse time foi estimativa de horas para tarefas, apesar de continuar quebrando as tarefas, o time parou de ficar imaginando quantas horas cada tarefa levará. Outra mudança com sucesso e alegria do time, pois diminuímos dois itens que para o time (que já praticava agile a um bom tempo) de trabalhos manuais considerados “chatos”;

Logo o terceiro item foi replicar o Baby Steps aos PBIs (Itens de Produtos de Backlog), quebrando de 2 em 2 na mesa de trabalho (Sai fora sala de reunião);

Dentre outras pequenas mudanças, veio o quarto grande item, sem reunião diária, segundo o time “- A gente já pareia o dia inteiro e conversa o dia inteiro, não precisamos de reunião Diárias”. Ok bora experimentar. Resultado: após 4 ou 5 Sprints retomamos a reunião diária, a pedido do time.

Existem varias coisas que o time testou e continua testando, e isso tem garantido um aprendizado continuo e seguro, sem deixar afetar o cliente e o rendimento direto do time. Quando o time falha essa falha é rápida e fácil de ser corrigida, pois sabemos aonde falhamos.

Resumindo, hoje o meu entendimento sobre evolução de processo em Times Ágeis:

  • O Framework Scrum é ótimo para começar os trabalhos;
  • O time precisa trabalhar um bom tempo com “um método” para criar maturidade;
  • Em paralelo criar maturidade nas práticas ágeis, ou seja, evoluir o Ágil em pessoas e equipes é fundamental para times eficientes;
  • Após a maturidade, é uma boa fazer experimentações, auxiliar o time para pensar se do jeito que esta sendo feito esta ajudando o time ou entravando;
  • Mudar em passos pequenos. Mude, meça (mesmo que empiricamente) e veja se deu certo;
  • Não ter medo de errar e passar essa segurança para o time, errou, corrija;
  • Os experimentos precisam ser pequenos para controlar o riscos e custos;
  • Utilizar ferramentas para auxiliar as pessoas é uma boa, exemplo, Feedback Canvas (Matheus Haddad), Documentos de Visão, Missão, criar identidade para o time;
  • O que mais gosto, é fazer as pessoas enxergarem o valor do que fazem e de como fazem.

Acredito que esse processo de mudança, possa ser levado para qualquer área de atividades. As pessoas podem pensar e podem mudar o jeito de fazer, as vezes precisam de segurança para que isso aconteça.

Obs. Ainda usamos muitas coisas do Scrum, porém usamos também do Lean e do Kanban.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *