Ken Schwaber teria dito que apenas 30% das equipes que utilizam Scrum são bem sucedidas. Ken, em seu blog, afirma não se lembrar dessa afirmação; ele indica que apenas 30% se tornarão "excelentes equipes de desenvolvimento".
A afirmação de Schwaber está alinhada com vários estudos sobre a gerência de mudanças. Especialistas no assunto, tais como o professor de Harvard, John Kotter, afirmam que 70% dos grandes esforços de mudança organizacional irão falhar. Independentemente da perspectiva pela qual se olha para os estudos, o prognóstico não é positivo. Então, o que podemos fazer para garantir que estaremos entre os 30% que obtêm sucesso?
Aqui listo dez sugestões. A lista poderia ter um maior número de itens, mas esses dez me pareceram mais significativos que quaisquer outros. Já retirar algum reduziria muito a efetividade da lista. Aqui vai!
1) Utilize um quadro físico
Estou convencido de que a maior diferença entre as equipes que adotam o Agile com sucesso e as que falham (ou que ficam "travadas") está na utilização de um quadro físico. Apesar de algumas equipes estarem distribuídas geograficamente e de existir tecnologia razoável para substituir o quadro físico por um virtual, mantenho a recomendação. Se for possível afixar um quadro em algum lugar onde muitos, senão todos, possam vê-lo, as chances de sucesso serão bem maiores.
É difícil explicar todas as razões para utilizar um quadro físico; é preciso experimentar e testemunhar seus efeitos. Parece ocorrer alguma espécie de mágica quando o mundo abstrato do software entra em contato com o mundo físico dos cartões e do quadro.
Visualizar o trabalho é apenas o começo: é importante aprender a interpretar o que o quadro está dizendo e a agir de acordo com isso.
2) Comece a coletar e usar métricas e estatísticas
Métricas, como velocidade, burn-down, defeitos identificados, defeitos registrados em log etc. não têm boa fama no desenvolvimento de software - por razões justas, em muitos casos. Mas não significa que não sejam úteis; apenas que têm sido vítimas de má escolhas ou de coletas mal feitas.
No mínimo, meça a velocidade da equipe e crie o gráfico de burn-down, ou um diagrama de fluxo cumulativo de trabalho (cumulative flow).
A beleza de trabalhar com Agile é que é bem fácil levantar algumas métricas simples. Quando as métricas se tornam complicadas, as pessoas não as entendem e é mais difícil aprender com elas. Da mesma forma que acontece com os quadros para visualização do trabalho, as métricas têm utilidade intrínseca, mas são muito mais úteis como ferramenta de aprendizado.
3) Envolva um coach/consultor
É possível adotar o Agile sem ajuda de terceiros; livros podem ser lidos, experimentações feitas e cursos realizados. Mas a falta de ajuda faz todo o processo ser mais lento e corre-se mais risco de ficar fora dos 30% de sucesso. Além disso, a adoção levará mais tempo, o que aumenta ainda mais o risco.
Não há grandes distinções, na minha opinião, entre um coach e um consultor ágil. Assim, independentemente de qual papel se escolha, o que se quer é alguém que seja capaz de:
- Observar, examinar, interrogar e desafiar os conceitos sobre o que está sendo feito;
- Oferecer ajuda em quais práticas e processos adotar e sobre a melhor forma de adotá-los;
- Oferecer exemplos do que viram funcionar ou não em outros lugares, e como outras equipes atacaram problemas similares.
Pode ser necessário trabalhar com mais de um consultor/coach, pois poucos serão capazes de conhecer todos os processos, práticas, tecnologias, produtos e estratégias. Uma opção é ter um consultor/coach com dedicação integral, mas o modelo com o qual obtive mais sucesso foi o de ter o aconselhamento leve, juntamente com um sistema de mudanças "puxadas" (veja mais abaixo).
Apesar de não haver necessidade de um consultor/coach dedicado, deve haver um acompanhamento contínuo. Tenho praticado e escrito sobre o coaching ágil leve; seguindo este modelo procuro voltar às empresas em intervalos de aproximadamente um mês, para continuar o acompanhamento.
4) Ações no lugar de palavras
Ações valem bem mais que palavras. Não se pode prever os problemas e questões que vão emergir até que se comece a utilizar o Agile de fato. Falar sem agir gera mais expectativas, aumentando cada vez mais o risco de que o Agile pareça apenas outra moda passageira de gestão.
Fale sobre o Agile, planeje-se, mas não deixe de mergulhar na ação, pois não há substituto para isso. Aprenda com suas ações e melhore; refine. Utilize algumas métricas que possam indicar o que está acontecendo.
Em especial, não gaste muito tempo decidindo se é melhor utilizar XP, Scrum, Lean, FDD, DSDM ou Kanban. Todos são similares, e no final você acabará montando sua própria versão híbrida, de uma forma ou de outra.
5) Treine a todos e realize discussões envolvendo todo o grupo
As equipes não se tornam ágeis por decreto da gestão, apesar de ter havido várias tentativas nesse sentido. A leitura de livros funciona para alguns, mas a maioria dos livros permanece não lida ou simplesmente não é absorvida.
Explique para as pessoas o que é o Agile - ou pelo menos o que significa para a organização. É quase impossível achar alguém da área técnica que não tenha ouvido falar de Agile; mas o que cada um sabe, as partes que se lembram, são diferentes. É importante que todos partam de um entendimento comum.
Porém não pare por aí; abra tempo para discutir o que é o Agile para cada um, o que gostam e o que não gostam de fazer. O Agile é um esporte coletivo; sem um entendimento comum, cada um estará jogando um jogo diferente. Essas discussões devem começar nas sessões de treinamento, ao mesmo tempo em que a equipe chega a um entendimento compartilhado das técnicas ágeis.
6) Anime mas não force
Quem já trabalhou em empresas por alguns anos já viu mudanças organizacionais serem forçadas para todos: BPR, ISO 9000, Seis Sigma, CRM etc. Um dia alguém tem uma ideia e então o rolo compressor de mudanças é ligado, passando por cima de todos.
Vivemos em um mundo pós-moderno, pós-BRP, pós-demissões, pós-recessão, pós-tudo. Os funcionários não são crianças e já sabem tudo o que está acontecendo. Além disso, é comum haver redundâncias antes do início do movimento de mudanças, especialmente quando consultores estão envolvidos. Se houver necessidade de cortar pessoal, faça-o antes de mudar para o Agile.
Aplique um princípio Lean: puxe, não empurre. Quando se fala em "gerência de mudanças", entra-se no mundo das mudanças "empurradas"; então proíba o uso dessas palavras.
Caso você esteja na gerência e queira introduzir o Agile, crie um movimento que gere entusiasmo com mudanças de baixo para cima, e forneça apoio de cima para baixo. Tentar uma adoção do Agile com uma abordagem unicamente de cima para baixo quase certamente resultará em fracasso - os funcionários são sempre céticos em relação a mudanças forçadas.
Procure entusiasmar indivíduos e equipes, faça-os pedir o uso do Agile. No lugar de impor mudanças, os gestores devem estimular a curiosidade das pessoas, fazer com que levantem dúvidas e peçam ajuda.
Faça tudo para que a "chama se acenda" e não deixe que se apague. Quando for pedido, ajude e forneça suporte a todas as necessidades. Permita gastos, abra espaço no orçamento para palestrantes, treinadores ou coaches. Apoie a ida a conferências; seja generoso. E envolva-se; também é preciso aprender - mesmo que se saiba que tudo o que o necessário é estar lá para quando o entendimento comum estiver construído. Aprenda a mudar também e a adequar seus próprios comportamentos de acordo com as necessidades.
7) Seja claro nas razões para adotar o Agile
Independentemente da posição que se ocupa - seja ela de engenheiro, analista de testes, gerente de projetos, diretor - entenda qual o problema que se quer resolver com o Agile. Entenda porque é importante mudar e o que esperar como resultado da mudança.
Não adote o Agile porque está na moda, mas sim para obter resultados reais. Procure entender o que as pessoas querem do Agile e o que isso pode melhorar na vida delas; entenda ainda o que a organização quer do Agile. Inovação? Cronogramas confiáveis? Menos defeitos?
É importante também compreender como cada membro da equipe enxerga os benefícios de se adotar o Agile. Se todos veem os benefícios, então (claro) haverá apoio na adoção; caso contrário, as mudanças serão difíceis. À medida que o Agile é adotado, utilize o que se esperava como resultados para escolher as ferramentas, otimizar seus processos e medir seu sucesso.
8) Adote tanto os aspectos técnicos quanto os de processo
A mudança do processo sozinha não é capaz de fazer tudo funcionar bem. Deve-se dar atenção aos aspectos técnicos também; melhorar a qualidade, dar apoio aos engenheiros, analistas de testes e outros que estejam realizando o trabalho.
Algumas empresas veem com desdém o lado técnico: a atitude parece ser de "isso é técnico demais" ou "eles que sujem as mãos", ou ainda, "podemos mudar para um país com custos mais baixos".
Caso essa seja sua visão, será difícil obter sucesso. Suje as mãos, fale com os engenheiros, adote o desenvolvimento orientado a testes (TDD), a refatoração; evite planejar a arquitetura toda de uma vez antes do desenvolvimento; aprenda a conviver com decisões difíceis de projeto e de evolução da arquitetura. Há ciclos de feedback positivo importantes nessas práticas.
9) Torne o fluxo de requisitos claro e limpo
Não basta melhorar apenas a parte da programação; a parte dos requisitos deve ser tratada também. Deve haver uma comunicação clara entre quem representa os requisitos (Product Owners, Gerentes de Produto etc.) e a equipe de desenvolvimento. Haverá muito mais negociações sobre o que fazer do que sobre quando fazer. Alguém precisa representar a equipe e se responsabilizar por essa parte do trabalho.
É comum que empresas tenham pouco pessoal para desempenhar este papel. O Agile torna esta escassez ainda mais grave, pois o gargalo nos requisitos terá efeito sobre o desenvolvimento.
Faça um exercício mental; pense no que aconteceria se o Agile duplicasse a produtividade dos desenvolvedores. Seria necessário o dobro do esforço no lado de requisitos. A princípio, pode-se apenas vencer um grande backlog, mas conforme se faz isso, o valor do que é entregue provavelmente entrará na descendente.
10) Mudanças estruturais e grupos funcionais
Monte suas equipes com as pessoas necessárias para fazer o trabalho sobre o qual são responsáveis; acabe com grupos funcionais (por exemplo, desenvolvedores de banco de dados e desenvolvedores de interfaces de usuário em equipes separadas). Esta é apenas a primeira de muitas mudanças organizacionais necessárias. Mas se esta falhar, será praticamente fim de jogo.
Equipes irão parar, ficar travadas, se precisarem pedir ajuda de outros grupos para ter acesso a habilidades especializadas ou obter permissões. Outros grupos têm outras prioridades, e pequenos impedimentos se acumulam, cada um tirando um pouco de velocidade da equipe, minando sua moral e tornando a adoção do Agile mais difícil.
Indo além
É isso! Se houvesse um décimo-primeiro ponto, seria: liberte-se do passado, as coisas mudam, o Agile não é apenas um "aditivo". Se não pararmos de fazer algumas das coisas sendo feitas hoje, nunca veremos o benefício completo do Agile. Mas para fazer essas mudanças, pode-se esperar pelos primeiros sucessos; sucessos que os dez itens acima irão ajudar a obter.