Agilidade X Pressa
Ser ágil não quer dizer ser rápido e ser rápido não quer dizer ser ágil.
Ser ágil é ser preciso e coordenado. Ter pressa é sinal de que estamos atrasados de alguma forma. Isso não é ser ágil. Isso é falta de planejamento.
O primeiro contato com a metodologia Agile
Em meados de 2009 tive meu primeiro contato com a metodologia ágil, (Scrum com Kanban). Nessa época trabalhava em uma equipe que realizava uma espécie de Data Mining. Posteriormente, li o livro Lean Startups e desde então, sou um entusiasta do desenvolvimento ágil que vi ser tratado por muito tempo como um modismo passageiro. Contudo, de uns tempos para cá vi a filosofia Agile se consolidando em grandes e tradicionais organizações para as quais eu presto serviços, o que me deixou realmente empolgado. O que me levou a crer que finalmente iria começar a escrever software com qualidade em tempo reduzido e não somente me preocupando com prazo, escopo e custo como sugerem os gerentes de projetos catequizados pelo PMBOK.
por Leonardo Fernandes no Linkedin Pulse
Ágil é se adaptar às mudanças de mercado
Tais organizações estão tentando seguir a fórmula das pequenas startups que implementam o Lean e o Agile para criar produtos e serviços em uma velocidade maior do que as gigantes do ramo estão sendo capazes acompanhar.
As grandes organizações com processos e produtos antiquados demoraram a perceber e se adaptar às mudanças do mercado, e como resposta a isso começaram a implementar aqui no Brasil há alguns anos as mesmas metodologias.
A fórmula equivocada usada
A fórmula usada para isso é simples, pegam os velhos e confiáveis baby boomers da organização, dão a eles um treinamento de quatro horas sobre metodologia agile e voilà! Os designam Product Owner ou Scrum Master de um time Agile.
Desde então eu tenho visto o que deveria ser ágil se transformar em pressa, o que eu gosto de chamar de metodologia Hurry.
Metodologia Hurry
A metodologia Hurry é, basicamente, quando você prega um Canvas Kanban na parede, se reúne em frente a ele uma vez por dia e continua alimentando as velhas idéias e posturas dos métodos waterfall.
Os velhos avatares permanecem sendo o pessoal técnico de confiança das organizações, com respeitáveis trinta anos de experiência dos quais há vinte não se atualizam, a não ser quando a organização “sugere” ou banca ou por iniciativa do colaborador realizando MBAs consagrados no mercado com professores também jurássicos.
Nesse cenário o bom e velho baby boomer é incentivado a impelir um ritmo veloz à equipe e a pressa travestida de agilidade logo mostra seus efeitos.
Velhos problemas mantidos
A estrutura permanece verticalizada com foco em agradar pessoas e não nas entregas, só que agora o chefe autoritário tem um repertório de palavras e conceitos para camuflar a estrutura vertical e centralizadora.
Isso é um problema, porque quando um membro da equipe está sendo acusado de algo (seja por um problema de conduta ou técnico) ao tentar se justificar, é contido em sua reação com o discurso de que não “estamos” buscando culpados ou a daily não é para tratar disso.
Essa frase é dita normalmente pelo chefe que agora é chamado de Product Owner ou Scrum Master e vez por outra leva as pessoas a rirem, sendo um sinal que a equipe está sobre o regime de Hurry Method e não Agile.
Agile não existe sem autonomia da equipe
Um outro indício de que a metodologia Agile está sendo deturpada de uma forma tóxica é quando as prioridades nas Sprints ficam flutuando sem que haja algo realmente catastrófico, como um erro em produção, uma invasão alienígena ou uma hecatombe nuclear.
O ponto alto do manifesto Agile é a autonomia do time em solucionar os problemas elencados no curto período de um sprint, ou seja todo o poder que o time tem, se resume em saber como, quando e o que deve ser feito com o sprint.
Ja no Hurry Method em um time autogerenciado cada membro (acha que) sabe exatamente o que fazer e quando fazer sem necessidade de planejamento, diálogo e comunicação.
Se concentra poder não é Agile
No fim das contas, o Agile deformado em Hurry, represa na mão de poucos o poder que antes estava diluído na mão de outros como o especialista em banco de dados e o arquiteto, e esse papel (do chefe fantasiado de líder) de Product Owner ou Scrum Master exerce influência sobre o Stakeholder de forma direta e em termos práticos, pode desligar ou dificultar a vida de membros da equipe mesmo que isso seja uma questão mais pessoal do que técnica.
As cerimônias do Agile normalmente são negligenciadas e via de regra os “donos da bola” aprenderam que um framework não precisa necessariamente ser implementado em sua completude, que o foco tem que ser a utilidade, e usam esse argumento para só implementar o mínimo do framework Agile.
Isso garante que possam continuar atuando como antes, de forma arbitrária, mas com cara de inovador e arrojado.
Em outras palavras, as cerimônias são reduzidas a dailys negligenciando as retrospectivas, planejamento de equipes e principalmente as cerimônias de entrega, onde o time tem contato direto com o usuário final.
O não cumprimento de todas ações sob o argumento de que não há tempo ou que se trata de uma customização, mantém o Product Owner blindado em seu trono de despotismo.
Por fim, o que confere o título de Hurry Method é o fato de que agora o chefe infiltrado no time usa um efeito colateral do Agile como métrica de produção.
No caso de um time ágil acabam sendo realizados muitos deploys e subidas para desenvolvimento e para produção, o número de versões é grande, mas isso é uma característica colateral.
O Product Owner acaba por usar este efeito como forma de controlar a produção, uma vez que não há reunião para planejar e metrificar as tarefas.
Não sendo capaz de criar o burndown chart, o gênio começa a medir a produção do time pelo número de versões ou de funcionalidades que são colocadas em produção, sem levar em consideração a complexidade ou o valor que a funcionalidade leva ao negócio.
E na sua organização? Será que existe a possibilidade disto acontecer no desenvolvimento de TI?
Cursos relacionados:
Gestão da Inovação
Transformação Digital
Gestão da Mudança
Gestão de Riscos
Gestão de Indicadores – KPIs
Design Thinking
Gerenciamento de Projetos
Escritório de Projetos – PMO
Mapeamento de Processos
Escritório de Processos – BPMO
Simplificação de Processos
Escritório de Valor – VMO
Conte com a ProValore para melhorar os processos de gestão da sua organização
Cadastre-se em nosso informativo e receba o eBook Planejamento Estratégico para a Transformação em 2025
