Hoje vou compartilhar as observações do Scrum Master sobre o primeiro ano de vida da equipe no novo framework.
Por que decidimos ir para o Scrum? Os motivos são comuns para muitas empresas:
- a relação não tão simples entre "negócios" e "desenvolvimento";
- a necessidade de agilizar as entregas;
- entendendo que é preciso reconstruir processos.
A mudança para o Kick-Off demorou cerca de seis meses (desde o início de 2019): estudo, formação, preparação de materiais e recolha das informações necessárias. E, finalmente,
em 3 de junho de 2019, demos início ao primeiro sprint.
O primeiro ano no novo framework é um desafio tanto para a equipe quanto para o Scrum Master. É necessário mudar radicalmente a mentalidade e começar a fazer as coisas de forma diferente.
O que um Scrum Master deve se lembrar durante este período?
Um Scrum Master não é um sapato, não precisa ser confortável. É necessário desenvolver uma habilidade sustentável de espelhar a equipe e seus membros individuais de padrões de comportamento não saudáveis. É muito importante aprender como dar feedback de maneira correta e em tempo hábil, mesmo que isso tire o Scrum Master e o oponente da zona de conforto.
Você precisa pensar em termos de equipe, não de indivíduos. Você precisa olhar para a equipe como um organismo vivo e lembrar que se "órgãos individuais adoecem", todo o organismo pode começar a ficar deprimido. Para continuar a analogia, o Scrum Master é um terapeuta. Não cirurgião, mas terapeuta, portanto, casos clínicos difíceis são para outros especialistas.
Scrum, assim como LeSS, não tolera a imaturidade pessoal dos membros da equipe. Se a equipe não sabe o que é Scrum, nunca trabalhou neste framework e, além disso, se já funcionou na composição atual, então eu recomendaria que você evitasse passar no LeSS imediatamente.
Identificar voluntários para o Kick-off (que geralmente leva três dias) dentro de uma equipe que não trabalhou anteriormente no Scrum tem mais probabilidade de ser falso. Se as pessoas não trabalharam nesta estrutura antes, dificilmente entenderão o que é e podem realmente falar sobre sua disposição de trabalhar dessa forma.
Hardy não é tudo. Se houver um problema com o software, mesmo um desenvolvedor que seja muito bom em termos de dureza pode se tornar um grande problema.
Em equipes auto-organizadas, pessoas com reflexão desenvolvida, inteligência emocional e desejo de autodesenvolvimento contínuo, expansão da consciência e vontade de mudar o paradigma podem viver e existir harmoniosamente.
Seria ingênuo acreditar que você é o mais inteligente. É muito importante transmitir esta mensagem a todos os membros da equipe. A penetração nesta mentalidade mais simples dá origem a muitas vantagens em vez de desvantagens: do respeito mútuo ao “sentimento de estar junto”.
A parte mais difícil é trabalhar com responsabilidade. É importante que as pessoas entendam que "voluntariedade" não se trata apenas de vontade e disposição para trabalhar no Scrum. Trata-se de disposição para se desenvolver, para crescer acima de si mesmo, para aprender a dar e receber feedback, a refletir e a fazer mudanças. Trata-se de um processo contínuo de melhoria não só dos processos, mas também de nós mesmos.
As pessoas geralmente não entendem por que um Scrum Master é necessário. E aqui, depois de conduzir muitos diálogos e workshops, discussões e conversas diferentes, cheguei à conclusão de que esse mal-entendido muitas vezes se deve à falta de prontidão para entendê-lo. O Scrum Master deve manter isso em mente e continuar trabalhando nisso.
O que o Scrum nos deu em um ano?
“Negócios” e “desenvolvimento” tornaram-se inseparáveis - a compreensão de “nós” e “eles” deixou de existir. Os especialistas em negócios trabalham junto com os desenvolvedores nas mesmas equipes. Agora, a compreensão das necessidades de um negócio reside nas equipes de desenvolvimento. Como resultado, melhoramos significativamente a velocidade de entrega: agora, os lançamentos ocorrem uma vez por sprint. Atualmente estamos vivendo em sprints de três semanas. Anteriormente, a taxa de lançamento real não era mais do que uma vez a cada 1,5 meses.
Legalizamos a dívida técnica e começamos a ganhar tempo nos sprints. Acertamos a proporção de 70% vs 30%, onde 30% foi alocado para a dívida técnica.
Em um ano, conseguimos envolver todas as competências críticas dentro da equipe, abandonamos os fornecedores e internalizamos o desenvolvimento. A influência de cada um nos resultados do desenvolvimento e nas soluções implementadas tem aumentado significativamente. A imersão dos desenvolvedores no produto e no contexto do cliente aumentou significativamente. Assim, a carga semântica “Por quê?” Mudou qualitativamente.
Lançamos o processo Discovery - aumentamos significativamente a imersão na “pele do cliente”. Agora todas as nossas ideias, quanto ao que nos parece que o cliente seria útil, verificamos directamente com os clientes. Criou um ambiente pronto para experimentar e uma cultura de vontade de experimentar.
CI / CD implementado.
Cobrimos praticamente todas as funcionalidades do aplicativo WEB com autotestes, o que reduziu significativamente o tempo e os custos de mão de obra para a regressão manual.
Iniciamos a transição para uma arquitetura de microsserviço, o que deve agregar mais independência às equipes de desenvolvimento.
Introduzimos um sistema de monitoramento de aplicativos e hardware: agora em modo on-line, é possível monitorar o status de um e do outro e, às vezes, receber sinais antes que as ligações dos clientes sejam feitas. Nós construímos uma série de painéis para monitorar indicadores de negócios, incluindo KPIs no modo automático.
Ao longo do ano conseguimos fazer muito, mas o nosso caminho continua.
PS: Eu deliberadamente não escrevi sobre os estágios de implementação do Scrum. Você pode ler muito sobre isso agora. Se estiver interessado, posso escrever um artigo separado.