Eu comecei a minha carreira há mais de quinze anos em Lisboa. Pouco depois tive uma oportunidade fantástica de me mudar para a Finlândia, onde acabei por começar a trabalhar na NOKIA.
Alguns de vocês são capazes de saber que a NOKIA começou a sua Agile Journey perto de 2004/2005 (altura que me mudei para lá). Estou a dizer isto para perceberem um pouco do meu background porque vai ser importante para perceber o meu ponto de vista, e perceber também o meu termo de comparação.
Nos dias que correm já não faço muito consultoria de Agile, durante os últimos anos desenvolvi um programa para ajudar executivos e respectivamente as suas empresas para transformarem-se em empresas fantásticas de produto, já que o Agile na maior parte das vezes não resolve nada a nível estrutural da empresa.
Como é obvio continuo a seguir o tópico do Agile de uma maneira muito próxima, já que para poder implementar o meu programa as empresas têm que ter adoptado metodologias Agile. Se quiser saber um pouco mais por favor consulte: “ADAPT Methodology®”.
A razão pela qual quero escrever este blog post é simples. Neste preciso momento estou no processo de expandir a evolution4all para Portugal e no topo disso tenho feito muito Coaching pessoal a vários Scrum Masters em Portugal e tenho observado vários comportamentos no mínimo bizarros e por isso resolvi escrever este blog post.
Normalmente não escrevo muito em Português mas durante os últimos meses decidi começar a traduzir todo o meu conteúdo para Português para que as pessoas em Portugal consigam encontrar o meu conteúdo mais facilmente.
Baseado em toda a informação referida acima e com o todo o conhecimento que tenho da cultura Portuguesa resolvi escrever este post que vai descrever 11 razões pelas quais eu acho que o Agile não funciona em Portugal e porque é que vai ser muito díficil de melhorar.
Uma coisa que eu quero deixar bem claro é o facto de eu não achar que este artigo tenha a ver de qualquer maneira com a competência das equipas e das pessoas em Portugal porque sinceramente trabalho com muita gente fora de Portugal há quase 15 anos e cada vez mais acho que os Portugueses são do mais competente que existe à face da terra.
Quem segue o meu trabalho sabe que sou bastante provocador e há cerca de 5 anos atrás escrevi um artigo semelhante na Alemanha, este artigo pode ser encontrado aqui:
5 Reasons Why Agile Does Not Work In Germany And What To Do
E sem mais demora vamos passar ao conteúdo.
Uma das coisas que me fez sair de Portugal foi a cultura das chefias. Infelizmente temos muito a cultura do chico esperto e do chefe que sabe tudo. Chefes que dão ordens atrás de ordens sem saber ouvir ninguém, o típico command and control; para ter uma implementação Agile com bastante sucesso os chefes têm que aprender a delegar e a confiar.
Ninguém no topo da hierarquia sabe tudo, as pessoas que estão perto da operação são as melhores pessoas para resolver os problemas, elas sim sabem como resolver os problemas da melhor maneira. A imagem abaixo ilustra bem o que eu quero dizer.
Solução: Se as chefias querem que Agile seja implementado com sucesso nas suas empresas elas vão ser as primeiras a ter que aprender que a maneira de gerir as pessoas como sempre geriram provavelmente tem que mudar…
Há uns tempos atrás eu escrevi um blog post a explicar porque é tao difícil para as chefias mudarem. Se quiser ler veja o blog:
Agile Management Style: Why Is It So Hard for Executives to Adopt it?
Esta para mim é uma das minhas favoritas, a razão é muito simples, normalmente as pessoas que são parte dos PMOs seriam as últimas pessoas que eu escolheria para começarem uma Agile Transition. Aliás eu quando trabalho com executivos normalmente menciono que o PMO é uma das maiores barreiras organizacionais para uma implementação com sucesso de Agile.
Muitas das ideias do Agile são completamente contra as ideias do “old school project management” logo a esmagadora maioria dos PMP vai aplicar Agile como um processo em vez de um mindset. Assim que tiverem alguma dificuldade que não saibam como resolver vão imediatamente voltar a aplicar o que o PMP diz.
Há umas semanas atrás uma das pessoas com quem eu faço coaching teve uma sessão comigo e disse-me alguns dos problemas que estava a ter com a equipa.
Eu sugeri para usar uma board física e esquecer tudo o que seja ferramentas virtuais, sem entrar em grande pormenor eu disse-lhe que provavelmente ao fazer isso (e mais umas quantas coisas) o engagement na Daily iria aumentar.
Eu não queria acreditar quando ele me disse que não podia usar boards físicas porque o Agile Office obrigava as pessoas a usar JIRA. Isto é um grande exemplo de como os old fashion PMPs vão tentar criar processos standard em vez de ajudarem cada equipa a descobrir a sua própria solução. Para não falar de um dos princípios do agile manifesto:
Individuals and interactions over processes and tools
Solução: Se realmente quiser ter uma Agile Adoption com bastante sucesso evite ao máximo dar essa responsabilidade ao PMO. São de longe (em casos normais) as pessoas menos capacitadas para tomarem tal responsabilidade… Contrate uma empresa especializada que o possa ajudar, mas mais uma vez verifique que os consultores não são mais outros PMPs com a certificação de Scrum Master.
Este motivo é comum em 90% das empresas com quem eu falo. Toda a gente espera que as pessoas dentro da organização fiquem Agile e percebam Scrum mas investir num bom treino para explicar a todo a gente de uma forma muito clara o que é Agile e o que se espera da pessoas é muito raro. Isto não é só em Portugal, como eu disse 90% das empresas por onde passei faz o mesmo erro.
Uma transição para Agile não é fácil, a maneira como as pessoas agem e pensam é bastante diferente da maneira tradicional de trabalhar, não espere que as equipas que não têm qualquer treino sejam capazes de mudar radicalmente a maneira como trabalham de um dia para outro.
Solução: Eu de cada vez que era contratado para ajudar uma empresa numa transição Agile uma das primeiras coisas que fazia era ter a certeza que todas as pessoas envolvidas tinham treino mínimo para perceberem o que era esperado delas. Se estiver a pensar em começar uma transição por favor tenha a certeza que todas as pessoas que estão envolvidas vão ter o treino certo.
Hoje em dia existe uma histeria louca à volta do modelo Spotify. Existem alguns iluminados que acham que por deixar de se usar o nome de Team lead e passar a chamar chapter ou tribe lead são imediatamente ágeis. Para os mais inocentes ou desatentos, o modelo Spotify não é muito mais que o modelo completamente outdated de matriz, para saber mais porque este modelo está morto visite este blog post:
Why a matrix organisational structure will destroy your company
O modelo Spotify funcionou para eles porque eles tinham uma cultura onde esse modelo trazia resultados, mas como é obvio quando se copia esse modelo para outras empresas com culturas completamente diferentes os resultados (na maioria dos casos) vão ser medíocres.
Solução: Cada caso é um caso, as empresas têm que perceber que cada sistema é diferente, seguir uma filosofia ou um blueprint não é errado, agora copiar literalmente um processo de outra empresa que nada tem a ver com a nossa é puro suicídio.
99% das empresas seguem um modelo matriz, este modelo é um modelo completamente ultrapassado para empresas que fazem desenvolvimento de produtos digitais. Os lideres das empresas têm que desenhar empresas baseadas em Value Streams, ou seja, equipas onde toda a gente que é necessária para fazer o release de um produto estejam presentes. Ou seja aplicar os principios do cross functional team a toda a organização.
A maior parte das pessoas que eu conheço menospreza o quão difícil é ter uma boa implementação Agile. Muitas das pessoas acham que Agile ou Scrum é so ter umas dailies e umas retrospectivas e já são Agile. Uma boa implementação de Agile demora anos a ser conseguida, não é de um dia para o outro que se consegue.
Eu já perdi a conta a empresas que vi que pensam que são Agile porque têm dailies mas na realidade usam um sprint para desenvolver código e o segundo para testar. Caso não se apercebam isso é puro waterfall.
Até mesmo se usarem a primeira semana do sprint para desenvolver e a segunda para testar continua a ser waterfall. Isto demonstra uma completa falta de entendimento o que é software development em Agile.
Solução: Claro que sendo eu consultor a malta vai dizer que não poderia dar outra solução se não esta, mas cá vai: “Arranjem um bom consultor para vos ajudar”. A malta pensa que os consultores são caros, e bons consultores especialmente estrangeiros são muito caros, mas o dinheiro que vão perder por implementar uma solução pobre na sua empresa vai ser muito maior.
Se quiser implementar Agile na sua empresa por favor garanta que esta rodeado de alguém com muitos anos de experiência nesta area, esta tarefa não é algo nada fácil.
Deixem-me dizer uma coisa, se o Product Owner não tem tempo para ir às reuniões então é melhor arranjar alguém que tenha tempo para estar dedicado à equipa 100%. Muitas vezes como as empresas acham que o Product Owner pode fazer o seu trabalho nos tempos livres dão-lhe mil e uma tarefas que nada tem a ver com o seu trabalho como Product owner.
O resultado é obvio vários pessoas são nomeadas como representantes e no final nenhuma tem o poder para decidir nada.
Há uns meses atrás escrevi um longo blog post onde eu descrevo:
20 Product Owners AntiPatterns
Sendo o Proxy Product Owner um dos anti-patterns. Esta prática é uma das piores coisas que uma empresa pode fazer, ter várias pessoas que são proxy Product Owners vai aumentar a frustração na equipa, já que a pessoa não pode decidir nada sem o PO e vai fazer com que os proxies funcionem como Bottlenecks.
Solução: O product owner é uma das posições mais importantes numa equipa Agile. É um trabalho que exige 100% dedicação. Se resolver implementar Agile na sua empresa é mandatório que o seu product owner seja um membro dedicado a 100% ao produto e à equipa.
Esta é uma das razões que vejo mais. É hilariante ver o número de pessoas que foram Project Managers durante anos e de repente passam a ser Scrum Masters dentro da mesma organização, a fazer o mesmo trabalho mas agora com o título de Scrum Master.
Muitas organizações continuam a não perceber que Project Manager e Scrum Master são posições completamente diferentes. Aliás na minha opinião são posições quase opostas.
Um project manager é alguém que conhece bem o negócio, é alguém que tem uma rede de contactos muito boa dentro da empresa e que faz as coisas acontecerem. Se for preciso o Project Manager até pressiona um pouco as equipas para que as coisas aconteçam mais rapidamente. É alguém que muitas vezes tem o budget e a responsabilidade de todo o projecto.
O Scrum Master é quase o oposto, é uma pessoa que conhece o processo muito bem (normalmente não o negócio), também deve ter uma rede de contactos bastante boa mas é uma role que não tem qualquer poder, é um role que ajuda as equipas a encontrar as melhores soluções e está lá para servir a equipa. O Scrum Master não tem qualquer budget ou poder de decisão.
Não quer dizer que Project Manager não dêm muito bons Scrum Masters, eu conheço alguns mas normalmente o resultado não é o melhor.
Solução: Proxima vez quando tiver um produto ou project Agile pensem em por o Project Manager como Product Owner. Tente arranjar um Scrum Master que não seja Project Manager. Tente identificar alguém dentro da organização que seja muito bom com pessoas, e que utilize influence em vez de persuasão, até pode ser um project manager mas muito cuidado com esta escolha.
Para ser sincero este problema é um problema que vejo a toda a hora, muito provavelmente porque advém do problema que referi anteriormente, de o Project Manager ser o novo Scrum Master.
Ser Agile não é tao simples como mudar o job title. é muito mais que isso…
Na velha maneira de waterfall as empresas fixavam os requirements; a qualidade e o schedule mudavam. Quando a empresa decide ir para Agile a coisa muda. O custo e o schedule são fixos e o que muda são as features, ou seja, definimos a frequência que queremos usar para fazer o release de software e o que muda é o Scope.
Os Gantt charts são algo do passado e completamente inúteis, os Gantt chart foram substituídos por Burndown charts, se quiser saber mais sobre este tema pode visitar este blog post:
Burndown Chart The Ultimate Guide For Every Scrum Master
Solução: Os lideres da empresa têm que perceber que o planeamento em agile funciona em 6 níveis:
E o que temos que fazer é organizar a nossa empresa nesta maneira. Software é uma industria altamente complexa logo não existe maneira de prever a delivery meses à frente. Temos que pensar em ciclos de uma/duas semanas e conectar esses ciclos com product releases (high level features) e com os objectivos do produto e da empresa. E claro usar Burndown charts para fazer o tracking de tudo.
Isto é algo que eu vejo bastante, é interessante ver a quantidade de vezes que os managers me dizem que estão altamente orgulhosos de como as suas equipas construíram a sua própria maneira de trabalhar em Agile.
Infelizmente em 99% dos casos isto é muito mau, porque as equipas desenvolveram a sua maneira própria de trabalhar para contornar as barreiras organizacionais que o Agile mostra.
Meus amigos gostem ou não gostem o Agile funciona, quando os managers dizem “isto do agile não presta, antigamente não tínhamos problemas e agora existem problemas em todo o lado” é a pura demonstração que o Agile já esta a funcionar. O Agile está a mostrar toda as disfunções que a empresa tem.
Criar as suas próprias abordagens para evitar estes problems apenas esconde os problemas e a empresa não esta a melhorar nada a nível organizacional.
Solução: Se a sua empresa realmente quiser implementar Agile, implemente Agile by the book durante os primeiros 18-24 meses, resolva todos os problemas organizacionais que vão aparecer e só depois pense em ter a sua própria abordagem.
Lembre-se do Karate Kid, passou semanas a fazer a lavar carros e a pintar muros até conseguir perceber para que raio aquilo servia, Agile não é diferente, para correr primeiro é preciso aprender a caminhar.
A esmagadora maioria das empresas pensa que um Scrum Master é alguém que simplesmente marca umas reuniões a facilita umas retrospectivas, não admira que há umas semanas atras vi uma empresa a contratar uma empregada do Lidl para Scrum Master.
Não a pessoa não tinha qualquer tipo de background técnico ou de software, se fosse o caso estaria perfeitamente OK com isso, a empresa simplesmente acha que a role de Scrum Master pode ser ocupada por qualquer perfil
Outro caso muito familiar aqui em Portugal é que as empresas acham que o Scrum Master deve ser um developer part-time porque não querem pagar um salário extra, logo a pessoa deixa de ser um grande developer para ser um mediocre Scrum Master e um developer normal porque simplesmente não tem tempo para se desenvolver em ambas as roles.
Solução: Scrum Master é uma role extremamente difícil e importante, o Scrum Master é uma role que deve ser feita a full time. Se voce quiser implementar Agile na sua empresa por favor garanta que tenha Scrum Masters a tempo inteiro, não precisa de ser uma relação de 1 Scrum Master para 1 equipa mas tem que ser uma role a full time.
Tenho investigado bastante quais são as empresas que existem em Portugal que estão a ajudar as empresas com formação. Se quiserem façam um google search por formação Agile e vão ver algumas das empresas. Quando clicam no site de muitas das empresas que estão na primeira página vão ver que muitas delas oferecem Agile e Project Management, e algumas delas ate têm PMPs a dar formação em Agile.
No perfil de uma das empresas ate vi a definição de Scrum: Gestão de Projectos Ágeis - Sabe o que é o Scrum? Scrum é uma metodologia ágil para gestão e planeamento de projetos de software, ou seja, é fazer mais e melhor e em menos tempo.
Isto é no mínimo horrendo, ter empresas a dar a formação Agile e a dar certificações de Scrum sem sequer serem capaz de ler uma linha do Scrum Guide
Scrum is a framework for developing, delivering, and sustaining complex products.
Para mim isto é muito muito perigoso, como já referi neste artigo para mim “Project Management” requer uma mentalidade muito diferente de Agile por isso pergunto me que experiência estas pessoas têm para poder ajudar alguma empresa com formação em agile, isto leva-me a pensar que as empresas estão lá para ganhar dinheiro e não para realmente ensinar e ajudar os clientes.
Agora vocês podem-me dizer que formação não tem nada a ver com consultoria, também é verdade mas no meu tempo de faculdade sempre respeitei muito mais os professores que têm experiência profissional, as pessoas quando vêm para uma formação precisam de ajuda, de respostas, se têm uma pessoa que faz tudo mas não faz nada como formador de certeza que não vai ser a melhor opção.
A maior parte das grandes empresas (e as boas) de consultoria em Agile recusam-se a dar qualquer tipo de consultoria ou formação em gestão de projecto isto deve ser algo para pensar, mas se calhar aqui em Portugal o que é mais importante é vender a bandeira das certificações e não temos que saber nada do assunto né?
Solução: Procurem empresas de formação ou consultoria que tenham provas dadas, que tenham tido muitas transformações no seu portfólio. Fujam de empresas que “vendem” certificações só para fazer dinheiro. Portugal tem muita gente competente procurem por alguém que pode levar o seu negócio para outros patamares, se quiserem posso dar nomes de pessoas de confiança.
Como eu não gosto de apontar só os problemas, por baixo vai encontrar a minha abordagem pessoal.
Hoje em dia existe uma grande demanda para este tipo de serviço, fazendo esta area bem atractiva para qualquer consultor, infelizmente você vai encontrar várias empresas a oferecer-lhe consultores sem terem qualquer tipo de experiência, especialmente as grandes empresas de “management consulting” que todos nós sabemos quem são.
Existem muitos gestores de projeto da velha escola que se enquadram nessa categoria. Eles passam por um curso de certificação Agile e vendem-se como consultor Agile perfeito.
Outro problema da esmagadora maioria das empresas e consultores nesta área reside no facto de não terem uma abordagem holística. Normalmente vendem uns treinos e umas workshops mas não têm uma abordagem holística logo o impacto vai ser muito pequeno.
Em resumo tenha cuidado com quem você contrata para ajudá-lo com a sua Implementação Ágil. Como líder, você precisa entender quem seria um bom consultor para ajudá-lo com sua implementação.
Muitos executivos acreditam que a transformação Agile não afeta seu trabalho. Isso está longe da realidade - seu estilo de liderança muda drasticamente e não será fácil.
Será difícil para você, afinal, se você é uma pessoa muito bem-sucedida, muito provavelmente todo o excelente trabalho como líder que fez no passado fez com que estivesse onde está hoje! Infelizmente o que o levou ao sucesso no passado não o vai manter no sucesso no future (provavelmente).
Infelizmente já não estamos a viver na era industrial e isso implica mudanças muito grandes no seu estilo de liderança. A sociedade não é o único problema aqui, tenho certeza que você já ouviu falar sobre a geração milenar. Eles são muito diferentes das gerações anteriores.
Eles são muito mais difíceis de liderar e precisam ser geridos de uma maneira completamente diferente. Há muito a ser entendido quando você se torna ágil. Por isso eu quando começo uma transformação Ágil passo sempre dois dias com a equipa de direcção.
Isto é um dos erros mais comuns que eu vejo quando as empresas tentam fazer transformações grandes! Esquecem-se sempre de criar uma equipa de "early adopters" para ajudar na mudança!
Esta equipa é crucial pois é composta por várias pessoas da organização, isto quer dizer que existem pessoas de todos os níveis da empresa, isto é bastante importante pois estas pessoas vai ser responsáveis por ajudar na mudança mas acima de tudo vão influenciar várias pessoas em várias camadas da empresa.
Lembre-se que todas as pessoas vão resistir há mudança se não forem envolvidas, com esta abordagem, você está a integrar várias pessoas a todos os níveis que vão fazer de tudo para que a mudança tenha sucesso.
Um erro muito normal que as empresas fazem é criar um departamento há parte para liderar a mudança, isso é um erro fatal, não faça isso, traga pessoas de departamentos diferentes e crie uma equipa cross functional que está empenhada em fazer acontecer a transformação.
A esmagadora maioria das empresas faz um erro crucial: espera uma transformação com pouco ou qualquer treino às pessoas envolvidas na transformação. O normal é dar uns treinos aos Scrum Masters e aos Product Owners e pronto está tudo resolvido.
Se realmente quer ter sucesso com uma transformações destas garanta que toda a gente que é afectada pela mudança recebe treino.
Garanta que todas as pessoas que vão actuar como Scrum Masters recebam o treino apropriado. Providencie treino aos Product Owners, não só o básico da Scrum Alliance ou Scrum.org mas algo mais além como Lean Product Management.
Se não conseguir arranjar pessoas com o perfil certo para Scrum Master pense numa solução como o Scrum Team Coach, um pacote de 6 meses em que contracta um Scrum Master Externo para o ajudar na transição.
Durante o tempo de transição garanta que os Scrum Masters têm acompanhamento com programas como o Scrum Master Mentoring Program ou o Lean Product Management Coaching Program.
E por último e 99% dos casos esquecidos, garanta que todos os developers e as equipas de desenvolvimento têm o mesmo suporte, esmagadora maioria das empresas esquece-se disto e como resultado vão ter várias pessoas que não acreditam no Agile porque nunca ninguém se deu ao trabalho de explicar-lhes os benefícios.
Pela minha experiência muito poucas organizações chegam a esta parte, mas na minha opinião esta é a parte mais importante. A esmagadora maioria dos executivos pensa que este tipo de transformação pode ser delegada mas infelizmente não podiam estar mais enganados.
Esta parte é tão importante que me levou a escrever um livro só dedicado a como construir uma organização de produtos digitais, se estiver interessado pode comprar o livro na AMAZON.
Quando o Agile está implementado nas camadas mais baixas da empresa, existem 5 pilares fundamentais que os executivos têm que implementar.
O resultado disto é um Product Management Blueprint para executivos como é mostrado no abaixo.
Como eu referi em cima as pessoas que seguem o meu trabalho sabem que de vez em quando escrevo blogs bastante polémicos, não faço com o intuito de ofender ninguém mas também percebo que muitas pessoas vão ficar ofendidas.
Se é uma das pessoas que ficou ofendida com este blog acho que a nossa conversa vai acabar por aqui, por outro lado se for uma pessoa que quer levar a sua empresa para outros patamares com alguém que está habituado a fazer isto no dia a dia então vamos conversar!
Se gostou deste artigo, dê uma olhada às páginas da minha empresa evolution4all. Nós somos especializados em ajudar empresas a desenvolver produtos digitais de maneira a ficarem empresas rápidas, flexíveis, modernas e inovadoras tal como uma startup!