Scrum — Melhores Práticas
Que o Scrum funciona, ninguém duvida. O problema mora em como e onde ele é aplicado. Ele tem mais chance de mostrar resultados em empresas pequenas (onde geralmente há mais flexibilidade e espaço — ou mente aberta) do que em empresas grandes (corporações com processos dogmáticos).
O manifesto ágil é pragmático. Mas ele parte da premissa que você trabalha com indíviduos maduros que formam assim um time maduro.
Tenha em mente que ao implantar o Scrum (e os seus valores) você terá dois benefícios imediatos: detectar problemas que “impedem” a velocidade de entrega — sejam eles técnicos ou processuais ou políticos. E trocar grandes falhas que só serão detectadas em “meses” (ou em uma janela de tempo muito maior) por pequenas falhas — que são corrigidas na iteração seguinte.As maiores lições aprendidas que tive foram:
Confundir Scrum com bagunça
Ao entrar diretamente em choque com um sistema processual, o Scrum é sempre confundindo com bagunça ou desorganização. Sendo que, existem diversas maneiras de se controlar/monitorar a evolução das iterações e das releases. O indicado nesse caso é sempre expor os controles (sprint burndown, release burndown, quadro, backlog). Deixar isso o mais visível possível para que as pessoas comecem a se adaptar aos novos controles. É interessante para quem se beneficia do processo atual (e as motivações podem ser muitas) atribuir adjetivos negativos a mudança. Tomem um cuidado extra para serem muito profissionais com esse tema.
Manter a temperatura do grupo
A tendência natural ao se formar times e rodar as iterações é que a médio prazo as discussões sobre as histórias e as tarefas sejam minimizadas. Pois o time vai perdendo o pique e prefere entregar sem ter que discutir para achar o melhor caminho. Fica-se com a impressão que um time que discute sobre todas as histórias em todas as interações é ruim, bem como também é ruim um time que nunca discute nada e todos sempre estão em comum acordo. O indicado é monitorar essas discussões e, se for o caso, incentivar as discussões ou evitar discussões acaloradas.
+ interações + problemas
Conforme as iterações passam, os conflitos entre membros do time ou entre time e pessoas que dão suporte ao desenvolvimento, pode aumentar. É necessário, nesse momento, o lado político do Scrum Master entrar em atuação e ponderar as considerações para que os ânimos não se exaltem ou haja um partidarismo desnecessário. O foco deve ser na entrega do produto com qualidade e não em estar certo ou errado.
Controle
“Controle inteligente é confundido com descontrole ou liberdade” Lao Tzu — Livro da Ética
Conforme os hábitos e a mudança de comportamento são incorporadas no ambiente de trabalho, pessoas em volta e inclusive os participantes que estão adotando essa metodologia tendem a encarar a nova prática como uma ausência de supervisão por parte da gerência. Quando na verdade, o conceito que muda é a transferência da responsabilidade para as pessoas do time. Horário de entrada/saída, divisão de tarefas, entregas, são responsabilidade que estar do lado do participante. Indicação: o Scrum Master deve somente interferir quando as coisas estão saindo fora do controle. E sempre incentivar o amadurecimento do time para chegar no tão sonhado auto-gerenciamento.
Filtrar informações para a equipe
Até todas as pessoas envolvidas com o desenvolvimento do produto entenderem a filosofia agile muita besteira será falada e é trabalho do Scrum Master filtrar essas informação para o time. Ele receber o feedback do trabalho, filtrar e comunicar como o time é visto pela empresa na retrospectiva e não durante o sprint. Uma dica é validar os feedbacks recebidos passando pelas três peneiras de Sócrates: A Verdade, Bondade e Necessidade.
Manter a motivação
Com tantas mudanças conceituais e necessidade de mudança de postura de muita gente, manter a motivação para médio e longo prazo é um dos grandes desafios do Scrum Master. É necessário sempre comemorar as entregas e celebrar quando as coisas deram certo. Criar moedas de troca com o time é extremamente necessário.
Velhas posturas em novos paradigmas
Como dito, se sua empresa tiver a mentalidade dos anos 70, levar essa empresa para uma mentalidade mais evoluída vai ser difícil e doloroso. Mas é o seu trabalho. It is what it is.
Evidenciar problemas incomoda pessoas
Quando os impedimentos aparecem, os problemas que estão por trás desses impedimentos são na maioria das vezes políticos. O motivo de alguém fazer as coisas de alguma forma e ninguém saber esse motivo é um exemplo clássico desse item. Outro ponto importante: questionar é parte do processo de entendimento. Ouvir coisas do tipo “vamos colocar todas essas informações no relatório porque o diretor pode querer saber desse indicador algum dia” também dói no coração. Alguém pode, por favor, questionar quais as informações que o diretor quer no relatório? Saber questionar de uma forma construtiva, positiva e educada é parte do trabalho do time ágil também. Temos que fugir desse estigma criança para receber porrada e bruto para apontar problema dos outros.
Evitar a adoção parcial — ScrumBUT
Adotar meio Scrum pode (PODE e não com certeza vai) levar ao dobro de problemas. É melhor fazer uma adoção total em um time do que uma adoção parcial em cinco times. Vários problemas nascem dessa adoção parcial. E é nessas horas que um Scrum Master com experiência consegue identificar os problemas e entender quais são reflexo de uma adoção parcial.
Maturidade
Em algum momento da implantação do Scrum, a tendência é perder o foco e esquecer que a entrega é o mais importante. Estar certo é um argumento forte, mas entregar funcionando é uma verdade científica.
Pessoas e Empresas
Esse item está intimamente relacionado ao item acima: maturidade. Sendo que as pessoas fazem as empresas, é preciso sempre selecionar pessoas maduras para fazer parte do time. Evitar criar uma “cultura do medo” onde só porque algum master-diretor pediu algo isso deve ser feito sem ser questionado é uma boa prática. Em uma sociedade que busca ter respostas rápidas pra tudo, a arte de fazer boas perguntas se faz mais necessária do que ter uma resposta pronta.
Ter um produto
Muitas vezes o PO ou a empresa não tem um produto, eles têm uma ideia. Não tem regras de negócio, layout, detalhes. Há só uma big picture formada na cabeça de alguns que querem esse esboço concretizado para provarem algum ponto. O Scrum Master deve trabalhar junto com a área de produtos para criar critérios antes de iniciar o desenvolvimento de produtos
Perfil
Algumas pessoas simplesmente não querem ver as coisas de outra maneira. O investimento de tempo nessa possível transformação é sua responsabilidade. Tanto no “não” como no “sim”, esteja ciente dos riscos.
Evitar extremismos
Principalmente em TI, pessoas tendem a ser polarizadas. É um ou zero. Isso ou aquilo. Há um mundo de cores e variações possíveis para um acordo. Evite que seu time seja zero ou um.
Version one is better than version none
O Done Manifesto já prega isso há um tempo. É essencial para o Scrum Master, SEMPRE bater nessa tecla. Fuja do pensamento do perfeito na primeira iteração — isso lhe atrapalha de entregar algo.
Originalmente publicado em daniloferreira.com.br em 27 de janeiro de 2013.
