Last updated on | Agile General Knowledge

10 razões que mostram que o Agile Em Portugal está podre

by Luís Gonçalves
Agile Em Portugal

Neste blog post quero explicar porque acho que o nível de Agile Em Portugal é muito baixo, e sinceramente não vejo muita maneira de melhorar. Eu comecei a minha carreira à 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 produto para ajudar as empresas a melhorar radicalmente o seu processo de product development, mas continuo a seguir o tópico de Agile de uma maneira muito próxima, já que para poder implementar o meu produto as empresas têm que ter adoptado metodologias Agile.

Se quiser saber um pouco mais por favor consulte: “Organisational Mastery”.

A razão pelo qual quero escrever este blog post é simples. Neste preciso momento estou a pensar em 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 a malta em Portugal consiga 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 10 razões pelas quais eu acho que o estado do Agile Em Portugal é muito mau e não vai melhorar tao depressa.

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 moro fora de Portugal há quase 15 anos e cada vez acho que os Tugas são do mais competente que existe à face da terra.

Quem segue o meu trabalho sabe que sou bastante provocador e acerca de 2 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.

A hierarquia dos chico espertos

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 teem 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.

Iceberg Ignorance

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?

O PMO transforma-se em Agile Office

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.

Ninguém recebe treino

Este motivo é comum em 90% das empresas com quem eu falo. Toda a gente espera que a malta toda fique Agile e perceba Scrum mas investir num bom treino para explicar a tudo a gente de uma forma muito clara o que é Agile e o que se espera da pessoas é muito raro. Isto não é so 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 teem 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.

Isso do Agile é fácil, baster ter umas dailies e umas retros

A maior parte das pessoas que eu conheço menospreza o quanto 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 teem 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 caca 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 experiencia nesta area, esta tarefa não é algo nada fácil.

O Product Owner está muito ocupado, não tem tempo para estas reuniões de Scrum

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 atras 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 varias 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.

O Project Manager é o novo Scrum Master

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.

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.

Scrum Master é quase o oposto, é uma pessoa que conhece o processo muito bem (normalmente não o negocio), 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 deem 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.

Somos Agile mas tentamos colocar os sprints num Gantt chart porque pensamos que conseguimos controlar tudo.

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 mudava. 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 teem que perceber que o planamente 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.

Os developers não conhecem a metodologia e as companhias orgulham-se de ter cada uma a sua variação de Agile

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.

Isso do Scrum Master é apenas um secretário e podemos ter um developer a marcar reuniões que isso funciona tudo

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 à 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 na Tuga é 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.

Hoje em dia todas as empresas dão PMP e Agile Certifications

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 teem 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 experiencia estas pessoas teem 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, tambem é verdade mas no meu tempo de faculdade sempre respeitei muito mais os professores que teem experiencia 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 na Tuga o que é mais importante é vendar 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 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 ninguem mas também percebo que muitas pessoas vão ficar ofendidas.

À dois anos atrás escrevi algo semelhante sobre a Alemanha. Centenas de pessoas comentaram no post e centenas de pessoas ficaram ofendidas mas muitas outras concordaram com o que eu disse eu contactaram me para ajudar as suas empresas…

5 Reasons Why Agile Does Not Work In Germany And What To Do

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 está responsável por Product Development e 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, pode me adicionar no LinkedIn ou mesmo aqui neste site.

THE ULTIMATE OKR GUIDE

Quer saber mais sobre os OKRs? Escrevemos um white paper que resume tudo o que você precisa saber para começar a usar OKRs na sua empresa! Não espere mais e faça o download do seu white paper agora.

Download o White Paper

Se gostou deste artigo, de uma olhada às páginas de produtos e serviços da minha empresa evolution4all. Nós oferecemos formação Agile, consultoria Agile, formação OKR, consultoria OKR, formação em inovação e consultoria em inovação.

Com a minha equipa, criei 5 produtos: High Performing TeamsScrum Team CoachScrum Master MentoringOrganisational Mastery and the External Business Accelerator.

Luís Gonçalves

About Luís Gonçalves

https://www.linkedin.com/in/luismsg/

Luis Gonçalves is an Entrepreneur, Author & International Keynote Speaker that works exclusively with Senior Executives of 7 to 8 figure businesses on the deployment of his game changing ‘Organisational Mastery’ Methodology.

Comments

Share your point of view

X