Sua Transformação Ágil Não Funcionou

Mesmo que você acredite que sim…

Chega a ser estranho logo eu colocar um título como este em uma publicação. Mas há uma grande probabilidade de você já ter visto em vários lugares posts sobre “Transformação Ágil” ou talvez “cases de sucesso”, ouvindo palestrantes sobre seus times “ultra-masters” ou até mesmo alguns cursinhos de 4 horas prometendo multiplicar seu salário em 10X. Na maioria das vezes você não vê um case de fracasso ou um “aqui estão nossas falhas”, embora existam estes cases apresentados em grandes conferências internacionais. A ideia aqui é justamente aproveitar alguns anos vendo erros e acertos para mostrar a tentativa de implementar o ágil falhando, ou melhor, coisas que acham que estão fazendo certo. Claro que não vou falar sobre todos os erros possíveis, pois daria para escrever uma trilogia, mas abaixo você encontrará alguns que são bem comuns.

Vamos começar pelo básico: Tentar começar a usar o ágil de baixo para cima. Isto é, tentar começar aplicando algo em algum time para depois tentar espalhar para o resto. Lamento informar, mas não dá (ou não deu) certo pois é justamente o inverso. Transformar uma organização deve ser feito de forma “top-down”. De nada adianta fomentar um processo em um time se os níveis superiores não estão comprometidos com esta ideia. O resultado disto é visto em todo o lugar até hoje, e continuamos vendo frustrações nestas tentativas: Time de desenvolvimento que não pode opinar, PO que não tem poder de decisão sobre o produto, gestão cobrando prazo e o comando-controle comendo. Depois é só ligar o modo “Go-Horse” e acabar desistindo… Muito se fala em mudar a cultura, mudar o mindset. Nesta hora lembre-se “A cultura devora o processo no café da manhã”. Muito cuidado ao tentar simplesmente enfiar o processo a fórceps.

Ainda temos a o famoso “enfiar o framework goela abaixo”. Acreditar apaixonadamente que um framework é a salvação da pátria é uma das coisas que mais vejo. Para piorar, sem nem ler ou entender aquele framework. E tem mais: a culpa não é do framework, e sim de quem está aplicando. Pegue como exemplo o próprio Scrum. Quantas vezes você já viu memes na internet satirizando aqueles que falam “mas está escrito no Scrum Guide”. SURPRISE! No próprio nome já diz, é um GUIDE. Nada está escrito em pedra, e o que serve para um pode não servir para outro. Ou você vai ligar um cronômetro e todos vão ficar quietos quando a daily chegar em 15 minutos? Vai parar de planejar pois acabou o time-box da planning? Estas coisas servem de referência para você aprender a ser mais assertivo, e não para você ser o chato que impede o time impondo as regras. Você quer implementar o Scrum: Então primeiro comece pelos três pilares e os cinco valores. Depois que você aprender a transparência e começar a reportar a verdade e ter tudo claro para todas as esferas, passe para o próximo pilar. Mas aprenda também Kanban, XP, DTA, dentre outras coisas que serão muito úteis (vou deixar para falar delas em artigos futuros).

Achar que o ágil é um unicórnio colorido que come post-it e defeca software. É claro que usar as notas autoadesivas é muito bom, ajuda na visualização e também deixando o trabalho a mostra. O erro aqui é o tamanho do foco que é dado ao ficar fazendo dinâmica atrás de dinâmica, evitar conflitos ao invés de fazer a gestão deles, e esquecer completamente o foco no valor do produto tentando ter apenas os “Coaches da Felicidade” dentro da organização. Desculpa a sinceridade, mas… Você esqueceu da engenharia de software, dos Design Patterns, da escrita de requisitos, critérios de aceite, arquitetura, estimativas (que NÃO SÃO um prazo!), e de várias práticas que precisam ser seguidas.

Você adotou um “modelo” de algum lugar, e ainda por cima não leu o manifesto ágil. Não é minha intenção dizer aqui que o case “Spotify” não é um modelo e que o SAFe não é nada ágil (ops! acabei falando). Mas sem gerar polêmicas, se alguém me disser que deu certo, vou pedir para ler o subtítulo lá em cima. Não, definitivamente não deu certo. Não deu certo nem no Spotify e nem eles mesmos estão usando, mas mesmo o C Level de lá falando isso em conferências anuais, ainda tem consultorias vendendo a ideia, e com erros inclusos (tem mais uma referência aqui se quiser saber mais). De repente vemos chamar o time de squad (fico atécom medo de alguém estar com um AK47 escondido) criando reuniões e mais reuniões de chapter, guild, etc… E tem até mesmo reunião para marcar reuniões! O que deve ser trabalhado com a organização é criar a própria cultura. Lembre-se sempre de olhar também para o que não deu certo. Aprenda com os seus próprios erros e com os erros dos outros também. Comece pelo manifesto, vai por mim. Comece pelos princípios e valores de lá!

Você acreditou nos gráficos de Gantt, o documento que está “absolutamente errado após o primeiro dia”. Neste parte recomendo a leitura de um artigo de Jeff Sutherland, de 2006 (já faz quase 24 anos desde a primeira implementação do Scrum, credo!!!). Acredito que alguns irão se identificar no momento em que ele diz que “Na melhor das hipóteses, engole um recurso em tempo integral no esforço inútil de manter o gráfico atualizado”. Quando falamos de ágil precisamos lembrar que ele é iterativo (também é interativo). As estimativas vivem mudando quando as mudanças ocorrem, os times aprendem iteração após iteração e também precisam de tempo para prototipar, experimentar, sem nem mesmo saber quanto tempo gastará com as famosas “Spikes” (ou melhor, quantas). Aqui o negócio é simples: Visão de produto, que irá crescer e se desenvolver tendo cada vez mais valor com o tempo. Também pode usar a palavra “produtizar”. Pense mais Lean e enxugue o processo.

Acredite no resultado, não no prazo. O plano muda no meio do caminho, então não é uma boa acreditar muito em escopo também.

Agora, vale ressaltar que existem sim práticas boas que podem ser obtidas em qualquer lugar, mesmo em casos como os que citei acima. É necessário engajar o “C-Level” ou o nível mais alto da empresa. Uma transformação ágil não acontece de forma rápida. Ela é um pouco dolorosa, tem pedras no caminho e deve ser feita parte a parte.

Existe uma série de dicas que podem ser dadas, mas vamos deixar isto para outras postagens ;)

Agile Coach @ SouthSystem. Long years in IT field, 12 with Agile and 15 inside people managemant. Graduated as IT Manager and MBA in Software Engineering.

Agile Coach @ SouthSystem. Long years in IT field, 12 with Agile and 15 inside people managemant. Graduated as IT Manager and MBA in Software Engineering.