A Evolução dos Princípios Ágeis e Como Aplicá-los no Mundo Atual

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts através de um programa de software. Perdoe quaisquer erros tipográficos, pois o sistema automático não está correto 100% das vezes.

Galen Low: Olá a todos, obrigado por nos acompanharem. O meu nome é Galen Low, do The Digital Project Manager. Somos uma comunidade de profissionais digitais com a missão de nos ajudarmos mutuamente a desenvolver competências, ganhar confiança e criar ligações, para podermos amplificar o valor da gestão de projetos num mundo digital. Se quiser saber mais sobre isso, visite thedigitalprojectmanager.com/membership.

Muito bem, hoje vamos embarcar numa viagem para reimaginar o desenvolvimento Ágil e explorar como poderá ser utilizado no futuro — bem como as alterações que teríamos de fazer para que continue a ser adequado às formas como as equipas irão trabalhar daqui a cinco, dez ou quinze anos.

Junta-se a mim hoje ninguém menos do que Jim Highsmith — O Jim Highsmith — um pioneiro reconhecido do desenvolvimento Ágil, coautor do Manifesto Ágil, membro fundador da Agile Alliance e profissional multifacetado de projetos tecnológicos com mais de 60 anos de experiência... Poderia continuar, mas penso que os elogios acabariam por ocupar praticamente todo o episódio.

Jim, muito obrigado por se juntar a mim hoje! É uma honra.

Jim Highsmith: Obrigado, Galen. Estou ansioso por esta conversa.

Galen Low: Temos conversado bastante. Tenho adorado as nossas conversas. Temos falado sobre o futuro do desenvolvimento Ágil. Temos falado sobre reimaginar o desenvolvimento Ágil.

Mas pensei em abordar já um tema interessante, enquanto tenho consigo. É coautor do Manifesto Ágil. E foi membro fundador de muitos dos grupos importantes que sustentam aquilo que hoje conhecemos como desenvolvimento Ágil. Por outras palavras, teve um dos melhores lugares para assistir à evolução do desenvolvimento Ágil desde o início.

De que formas viu mudar o tom das conversas sobre o desenvolvimento Ágil atualmente, em comparação com a altura em que era uma ideia nova? Continua a ser tão entusiasmante falar sobre isso?

Jim Highsmith: Para mim, continua a ser entusiasmante. Não sei se o é para toda a gente. Uma das coisas que temos de compreender é que o Manifesto Ágil nasceu numa época diferente.

Quero dizer, foi há 23 anos e, nessa altura, não existiam muitas redes sociais. Por isso, a forma como divulgámos a ideia foi através de artigos em revistas, apresentações em conferências e do wiki de Ward Cunningham. E era praticamente tudo. Nos primeiros anos, recebemos muitas críticas, porque representava realmente uma mudança em relação ao passado, uma mudança bastante significativa.

Exceto em alguns locais. Por exemplo, se formos ao Silicon Valley e dissermos: “Aqui estão algumas práticas reais”, eles respondem: “Ah, nós já fazemos isso. Só precisávamos de um nome para isso.” Certa vez estive numa empresa no Silicon Valley e disseram-me que estavam a trabalhar de forma Ágil. Perguntei: “Quanto duram as vossas iterações?” Responderam: “Três ou quatro meses.”

Por isso, mesmo aí havia alguma diferença de opinião. Outra questão é que existe um ciclo de adoção tecnológica que foi publicado há muito tempo: inovadores, maioria inicial e maioria tardia. No início, eram algumas pessoas inovadoras, tanto empresas como indivíduos, que se dedicavam verdadeiramente ao desenvolvimento Ágil.

Agora temos pessoas em todas essas fases. Temos a maioria inicial e a maioria tardia. Algumas pessoas estão apenas a começar. Outras não querem começar. E, por isso, recebemos tipos de feedback diferentes de cada grupo. Na área dos inovadores, as pessoas avançam simplesmente com aquilo que parece uma boa ideia.

Quando chegamos à maioria tardia, essas pessoas querem provas. E não querem apenas provas na sua indústria, mas também nos seus tipos de projetos. É provável que digam: “Não podemos fazer isso por causa de X, Y e Z.” Por isso, teremos sempre respostas variadas a este tipo de questões. Uma coisa que notei, e já trabalhei com tudo, desde a ausência de metodologia até metodologias estruturadas e metodologias Ágeis, é que todas funcionam e nenhuma funciona.

É mais uma questão de pessoas do que de metodologia. E, na realidade, é uma questão de mentalidade. Tenho utilizado as expressões “realizações e desilusões” em vez de “sucesso e fracasso”. Penso que todos os projetos, sejam Ágeis, em cascata ou de outro tipo, têm algumas realizações. Há quem diga que o modelo em cascata não funciona.

Bem, durante a década de 1980, realizei muitos projetos utilizando o modelo em cascata e foram muito bem-sucedidos. Alcançámos bastante. Também houve algumas desilusões, e algumas dessas desilusões acabaram por nos alcançar em meados da década de 1990. Num livro de 2002, escrevi uma definição de agilidade: agilidade é a capacidade de criar e responder à mudança para obter benefícios num ambiente empresarial turbulento.

E não sei se alteraria muito essa definição hoje. Continua a ser agilidade. Penso que uma das coisas que acontece é as pessoas confundirem métodos, metodologia e mentalidade. São três coisas distintas, que poderemos abordar mais tarde, se quisermos. Mas, essencialmente, o tom mudou na forma como analisamos o desenvolvimento Ágil.

Uma das coisas que estou a tentar fazer com esta iniciativa de reimaginação do desenvolvimento Ágil é recuperar um tom mais positivo.

Galen Low: Gosto muito dessa perspetiva: já não se trata apenas do grupo dos primeiros adotantes. Agora temos um espectro de pessoas que estão atrasadas ou que adotam mais tarde, e das provas de que precisam.

E o ónus da prova é diferente agora do que era anteriormente. Gosto do que está a dizer sobre o facto de o mundo continuar a avançar e de a agilidade ser considerada valiosa atualmente, mas isso não significa que o modelo em cascata tenha deixado de funcionar. Poderá simplesmente ter uma finalidade ou um foco diferentes, ou podemos esperar desilusões e realizações diferentes, mas isso não significa que esteja desatualizado.

Jim Highsmith: Uma das coisas que, por vezes, se perde é o facto de ser necessário analisar os projetos no seu próprio contexto, especialmente no que diz respeito à incerteza. Por exemplo, um projeto como o do telescópio Webb é muito diferente do desenvolvimento de uma aplicação para o iPhone, em termos do caso de utilização. É necessário compreender isso, especialmente quando se gere um projeto.

Galen Low: Gosto do facto de utilizar esse exemplo, porque recorremos frequentemente a exemplos aeronáuticos e espaciais. Num mundo de software, em que existe integração contínua e se fazem implementações constantemente, é relativamente fácil.

Não vou dizer que é fácil, mas é certamente muito mais fácil do que enviar um vaivém para a estação espacial numa missão de reabastecimento ou para reparar uma peça de equipamento que não estava a funcionar como esperado. É necessário planear de forma diferente, elaborar orçamentos de forma diferente e pensar nesse projeto de forma diferente.

Jim Highsmith: Sim. É interessante mencionar o setor aeroespacial porque, no início dos anos 2000, tive uma conversa com a secretária da Força Aérea. Ela tinha lido o meu primeiro livro e dizia que, na construção de projetos aeroespaciais, talvez fosse necessário trabalhar com iterações e que estas não poderiam durar um ou dois anos.

Utilizou a ideia de desenvolvimento adaptativo num dos seus discursos. Portanto, não significa que todos os projetos aeroespaciais tenham de seguir o modelo em cascata. Podem ser, em certa medida, adaptativos e Ágeis. Penso que essa é uma parte importante da nossa reimaginação.

Galen Low: Há pouco trocei da ideia de um ciclo de três ou quatro meses. Mas, por vezes, no contexto geral, isso é ágil. É rápido. É uma rotação muito curta para obter resultados, aprender com eles e garantir que não passamos 15 anos a construir a coisa errada. Continua a ser a mentalidade correta, mesmo que os métodos sejam diferentes.

Por vezes queremos que estas mentalidades tenham regras codificadas e regras que não podem ser quebradas. Mas, na verdade, trata-se apenas de uma forma de pensar para evitar algumas das desilusões que poderiam resultar de fazer as coisas de outra maneira.

Jim Highsmith: Podemos pegar em qualquer prática, por exemplo, o planeamento de um ciclo. Podemos sobrecarregá-la com documentação e reuniões, tornando-a muito prescritiva, ou podemos torná-la adaptativa. A mesma prática pode ser mais prescritiva ou mais adaptativa, dependendo da forma como a abordamos.

Galen Low: Todos os benefícios que as pessoas anunciam relativamente a algo, não apenas ao desenvolvimento Ágil, também podem tornar-se a sua própria fraqueza. Podem deixar de ser verdade nas mãos erradas.

Jim Highsmith: Outra questão é que, com a chegada das redes sociais, os 10% têm uma voz mais forte do que os 90%. E 10% das pessoas gostam de ser negativas. Não sei se se lembra de Spiro Agnew, que foi vice-presidente durante a presidência de Richard Nixon. Ficou famoso pela expressão “os nababos tagarelas da negatividade”.

Pensei nisso enquanto me preparava para esta conversa. Disse para mim próprio: esse é o problema com 10% das pessoas em algumas destas redes sociais — são nababos da negatividade.

Galen Low: É curioso, e ainda bem que mencionou as redes sociais, porque muitas pessoas têm atualmente o primeiro contacto com o desenvolvimento Ágil através de polémicas, de alguém no Reddit ou de alguém nas redes sociais, normalmente a partir de uma perspetiva negativa. As pessoas perguntam por que razão ainda se utiliza o modelo em cascata ou qual é a grande vantagem do desenvolvimento Ágil. Dizem que nunca funciona. Abordam a questão a partir de extremos muito polarizados. E, como diz, essas pessoas têm agora uma voz muito forte.

Não é apenas um grupo reduzido que ouviu um programa de rádio, viu um cartaz ou leu um artigo académico. A informação aparece praticamente no feed de toda a gente. As pessoas recebem estas impressões constantemente. Voltando ao seu exemplo, na política isto seria compreensível, mas estamos a falar de uma metodologia de projetos que não esperaríamos que fosse tão controversa. Ainda discutimos apaixonadamente há mais de 20 anos se o desenvolvimento Ágil é bom ou não. Por que razão continuamos a discutir isto?

Jim Highsmith: Algumas pessoas, por exemplo, publicam textos sobre os problemas das abordagens Ágeis e dizem que não existe documentação. Há 20 anos que respondemos a essas questões. Onde é que essas pessoas estiveram?

Há cerca de um mês estava a consultar o meu livro de gestão de projetos, publicado em 2009, Agile Project Management, e encontrei um gráfico que me tinha esquecido de que existia, sobre documentação.

Pensei: “Está bem, esta é uma abordagem mais equilibrada à documentação.” Apresentava algumas orientações. Publiquei-o na Internet tal como estava, sem o modificar. Teve 66 000 impressões e 96 republicações, apesar de eu não o considerar particularmente interessante. Orientações sobre documentação. Isto mostra que existem muitas pessoas à procura de informação equilibrada, afastada dos extremos.

Mas também direi que precisávamos dos extremos naquela época, porque era necessário analisar os limites. No caso da documentação, alguém poderá ter dito: “Vamos experimentar não ter documentação.” Ninguém queria realmente dizer isso. O que estávamos a dizer era que a documentação tinha substituído a comunicação e a colaboração.

Uma consequência do modelo em cascata foi a criação de organizações que o seguiam. Havia um grupo de requisitos, um grupo de design, um grupo de programação e um grupo de testes. A comunicação entre eles era feita através de documentação. Não existia colaboração nem comunicação interativa. Era disso que tentávamos afastar-nos: a documentação deveria complementar a colaboração, e não substituí-la.

Galen Low: É curioso, porque usamos expressões como “a revolução Ágil”, “grande mudança” e “perturbação”. Passou muito tempo e nem sempre reconhecemos o impulso que foi necessário naquela altura. Quando pensamos em revoluções ou em defender uma posição extrema para provocar uma mudança, penso que muitas pessoas interpretaram isso de forma demasiado literal.

Pelo que vejo, não se trata de não haver documentação. Trata-se de dar prioridade à comunicação em relação à documentação.

Jim Highsmith: É uma questão de interpretação. É algo semelhante à Constituição dos Estados Unidos. Existem juízes que defendem uma interpretação estrita: o que está escrito na Constituição é exatamente aquilo que significa. Se o Manifesto Ágil fala de software, então, para essas pessoas, aplica-se apenas ao software.

Outras pessoas fazem uma interpretação mais flexível e reconhecem que o desenvolvimento Ágil pode evoluir e que o manifesto não está gravado em pedra. Foi criado num momento específico. Temos de encontrar formas de o alargar a outras áreas e não ficar presos à formulação exata.

Galen Low: Não é um problema do desenvolvimento Ágil. É um problema humano. Aplicamos isso igualmente quando interpretamos algo à letra da lei ou quando compreendemos suficientemente a essência para a transportar para o futuro. É precisamente isso que vamos explorar, porque penso que as pessoas nem sempre reconhecem que o desenvolvimento Ágil está a mudar.

Que tendências ou práticas emergentes na gestão Ágil de projetos lhe chamaram recentemente a atenção?

Jim Highsmith: Há pessoas que estão a desenvolver extensões à abordagem Ágil básica. Quando começámos as conferências Ágeis, em 2004 e 2005, preocupava-me a negatividade existente na comunidade Ágil em relação à gestão de projetos.

Foi por isso que criámos os mestres de Scrum e outras designações: dizíamos que não precisávamos de mais gestores de projetos, mas sim de mestres de Scrum. Penso que isso foi um problema durante muito tempo. Em 2005, fundei uma organização chamada Agile Project Leadership Network. A nossa missão era alargar a gestão de projetos ao desenvolvimento Ágil e dizer que a gestão de projetos não era inútil; precisávamos era de um tipo diferente de gestão de projetos.

Precisávamos de uma gestão de projetos mais centrada nas pessoas do que nas tarefas, na colaboração e noutros aspetos semelhantes. Essa foi também a organização a partir da qual alguns de nós passámos para o PMI para desenvolver a certificação Ágil do PMI.

Existem pessoas que estão a fazer extensões semelhantes. David Pereira, por exemplo, está a publicar um novo livro sobre gestão de produtos, para o qual escrevi o prefácio. Uma das coisas de que gostei foi que o livro aborda a agilidade, mas quase nunca utiliza as palavras “Ágil” ou “agilidade”. O conceito está presente em todo o livro.

Chris Stone é outro exemplo de alguém que avançou com uma abordagem própria ao desenvolvimento de software sem ter de utilizar sempre a palavra “Ágil”. Naturalmente, a grande área que está a surgir é a inteligência artificial. Vi pessoas a utilizar a expressão “Ágil aumentado”, que me parece adequada para o momento atual.

Galen Low: Disse anteriormente que, quando escrevia o manifesto e este foi publicado, era alvo de críticas e de pessoas que se opunham à mudança. Agora falamos de extensões do desenvolvimento Ágil. Essas pessoas também estão a ser alvo de críticas? Evitam utilizar a palavra “Ágil” de propósito para não afastar as pessoas?

Jim Highsmith: Em parte, sim. Algumas pessoas estão a abandonar o termo porque recebeu alguma publicidade negativa.

Curiosamente, hoje recebe boa publicidade no mundo empresarial. Se analisarmos alguns anúncios de diretores executivos sobre a direção que as suas empresas estão a seguir, vemos que o diretor executivo da GM utilizou a palavra agilidade. O diretor executivo da Bayer também utilizou essa palavra para descrever uma nova prática.

No contexto empresarial, o termo está a ser utilizado cada vez mais. Steve Denning publicou recentemente vários artigos na Forbes sobre a implementação de metodologias Ágeis, e uma mentalidade Ágil tornou-se muito importante para algumas das principais empresas atuais.

Galen Low: Tenho visto muito mais disso. E isso suscita conversas na nossa comunidade sobre o que essas pessoas querem dizer. Haverá Scrum para executivos, para o planeamento e a execução estratégicos? Ou será sobretudo uma questão de mentalidade? Voltamos a ficar presos entre métodos, metodologias e mentalidades. Provavelmente são os três, mas temos de evitar confundi-los.

Jim Highsmith: Existe, por exemplo, a associação de marketing Ágil, que está a aplicar princípios Ágeis ao marketing com bastante sucesso. Encontraremos extensões para o marketing, para a inteligência artificial e para diferentes indústrias. Não creio que exista Scrum na direção executiva, mas haverá formas mais Ágeis e adaptativas de abordar estas questões.

O que irá mudar é também a estrutura das organizações. Estive a ouvir uma apresentação extraordinária do diretor executivo da NVIDIA. Ele explicou que o chip mais recente da empresa tem 208 mil milhões de transístores. Quando comecei, um transístor tinha aproximadamente o tamanho da ponta de um dedo. Se multiplicarmos isso por 208 mil milhões, chegamos a cerca de 10 milhas quadradas. A diferença tecnológica em relação ao passado é enorme.

Tenho falado com grupos sobre o facto de, seja qual for a sua função — mestre de Scrum, gestor de projetos ou coach Ágil —, ser necessário ter algum conhecimento tecnológico. Já não é possível evitá-lo. Isso deixou algumas pessoas bastante preocupadas.

Galen Low: É interessante, porque no manifesto se fala de software, mas hoje muitas coisas parecem óbvias para quem trabalha nesta área e não são nada óbvias para outras indústrias. Fico satisfeito por ver empresas, equipas de marketing e outras áreas a abrirem os seus processos e métodos para se tornarem mais ágeis.

Também têm de encontrar o seu próprio caminho. Não ajuda alguém ficar no topo da montanha a dizer: “Descubram isso de uma vez.” Existe uma grande oportunidade para colaborar mais. A mudança e a agilidade serão cada vez mais necessárias na tecnologia e nos negócios. É assustador, mas também inspirador. Temos de fazer com que estas áreas avancem juntas. Talvez seja essa a parte de reimaginar o desenvolvimento Ágil.

Jim Highsmith: Parte do processo consiste em reimaginar a gestão. Para voltar à apresentação que mencionei, o diretor executivo da NVIDIA tem 55 subordinados diretos. Isso significa uma organização mais horizontal. É necessário gerir de forma muito diferente quando se têm 55 subordinados diretos em vez de três ou quatro.

Tenho outro exemplo. Um amigo meu, consultor, foi ajudar numa transformação Ágil e descobriu que a empresa tinha 100 programadores e 98 gestores de projetos. Havia algo desequilibrado. Existiam silos funcionais de analistas, designers, programadores e testadores, e cada pessoa trabalhava em sete ou oito projetos.

A combinação destes fatores exigia muita gestão de projetos para manter a coordenação. Uma das soluções foi simplificar a organização, reduzir o número de gestores de projetos e aumentar o número de profissionais técnicos.

Penso que também temos de corrigir o equilíbrio entre tipos de gestão, colaboração e competências técnicas. Os aspetos técnicos do desenvolvimento Ágil nem sempre receberam o peso suficiente.

Galen Low: Isso faz todo o sentido. Como gestor de projetos e representante de gestores de projetos, admito que existem maus gestores de projetos. Talvez tenha sido necessário imaginar uma equipa sem gestor de projetos. Mas, à medida que os projetos tecnológicos se tornaram mais complexos e passaram a exigir mais coordenação, tornou-se evidente que um gestor de projetos podia ser útil.

Talvez o problema não esteja nos papéis em conflito, mas no equilíbrio e na forma como configuramos as pessoas e os papéis. Num projeto Ágil, provavelmente já não damos tanta ênfase à documentação e devemos dar mais atenção às funções técnicas. Estas funções já não são apenas técnicas: falamos de pessoas capazes de pensar sobre o negócio, programar e trabalhar com outras pessoas.

Os antigos estereótipos já não são verdadeiros. Por isso, as nossas configurações e combinações têm de mudar. O desenvolvimento Ágil parece ser uma boa resposta para o futuro, mas existem desafios no horizonte. Que desafios vê as metodologias Ágeis a enfrentar atualmente e quais poderão surgir no futuro? Por que precisamos de reimaginar o desenvolvimento Ágil?

Jim Highsmith: Precisamos de o reimaginar por causa dessas mudanças. Hoje fala-se de inteligência artificial, mas também da Web3, da cadeia de blocos, da computação na nuvem e dos megadados. Existem muitas mudanças tecnológicas em curso.

Se daqui a três ou cinco anos tivermos computação quântica, isso irá alterar profundamente as coisas, dependendo da rapidez com que conseguirmos criar aplicações úteis para empresas e organizações. Será difícil acompanhar essas mudanças tecnológicas e criar o impulso adequado dentro de uma organização.

Vejamos os megadados. Foi publicado um livro sobre a evolução dos megadados e sobre como 90% dos problemas ou desilusões das implementações de megadados eram culturais e apenas 10% eram tecnológicos.

Se o desenvolvimento Ágil seguir um caminho semelhante, talvez esteja a produzir transformações mais eficazes do que os megadados, mas ainda temos um longo caminho a percorrer. Grande parte da questão está relacionada com a mentalidade. Vejo a mentalidade como a forma de pensar de cada indivíduo e a cultura como o conjunto de todas as mentalidades de uma empresa.

Não parece que estejamos a melhorar na mudança cultural e de mentalidade. Como iremos acelerar essa mudança? Tenho pensado muito na ideia de capacidade, em oposição ao conhecimento. Quando começamos a falar de inteligência artificial e de motores de conhecimento, percebemos que o conhecimento é apenas uma parte. Posso utilizar a inteligência artificial para tarefas baseadas em conhecimento, como fazer investigação, mas capacidade é diferente. A capacidade resulta do conhecimento, da experiência e da tomada de decisões.

Não basta obter alguns certificados de Scrum, Kanban ou outras áreas. O conhecimento, por si só, não chega. É necessária experiência. Como podemos aumentar a velocidade com que adquirimos experiências? É possível obter experiência sem passar diretamente pela experiência?

Uma forma é utilizar estudos de caso, como faz a Harvard Business School. Reúne-se um pequeno grupo, apresenta-se um estudo de caso, discute-se profundamente e apresenta-se a conclusão ao resto da turma. São experiências que permitem desenvolver uma análise aprofundada sem vivenciar diretamente a situação real.

Depois surge a questão de saber se temos experiência e conhecimento suficientes para tomar boas decisões. Existem decisões de tipo um e de tipo dois, e a inteligência artificial irá afetar cada uma delas de forma diferente.

Estamos à procura de sensibilização, de um assistente ou de aumento de capacidades através dos sistemas de inteligência artificial? Encontrar a abordagem certa será difícil, porque hoje existem muitas questões tecnológicas diferentes a considerar.

Galen Low: Concordo plenamente. Tudo está a avançar muito depressa. Quando pensamos em iterações e ciclos, analisamo-los pela perspetiva da eficiência e da aprendizagem, geralmente da aprendizagem técnica, para não ampliarmos os erros e só os vermos no final.

Mas a mentalidade de aprender depressa e falhar depressa também se aplica às pessoas. Podemos aprender deliberadamente em cada ciclo. Podemos utilizar experiências curtas para aprender tanto quanto possível, refletir sobre elas e melhorar enquanto seres humanos.

A controvérsia em torno do desenvolvimento Ágil é parcialmente uma questão de interpretação, mas também é resistência à mudança. Passamos de um ambiente de estrutura, segurança e previsibilidade para outro mais flexível, ambíguo e desconhecido. Esse mecanismo humano pode tornar as pessoas resistentes ao desenvolvimento Ágil.

Jim Highsmith: As iterações são importantes para a aprendizagem. Num projeto de um ano realizado em cascata, fazemos a definição de requisitos uma vez, o design uma vez, a programação uma vez e os testes uma vez.

Num enquadramento Ágil, se fizermos lançamentos mensais, passamos por esses ciclos de aprendizagem 12 vezes, em vez de uma. Isso incentiva o processo de aprendizagem.

Preocupa-me aquilo a que chamo agilidade prescritiva, que é uma contradição. Algumas pessoas dizem: “Façam estas seis coisas, têm de fazer estas seis coisas e têm de medir tudo desta forma.” A agilidade torna-se prescritiva. Se formos prescritivos com a agilidade, nunca aprenderemos o suficiente para adquirir uma boa experiência e adaptar o que fazemos. O ideal é uma agilidade adaptativa.

As metodologias Ágeis espalharam-se amplamente. Nas extremidades, há pessoas que frequentaram um curso de dois dias para mestres de Scrum e passaram a ensinar Scrum. Naturalmente, tenho algumas reservas em relação a isso.

Galen Low: É bom que não tenhamos mantido o conhecimento fechado, mas quando algo se espalha fica sujeito a más práticas. Às vezes são pessoas que nem sabem que estão a fazer algo errado; simplesmente representam, praticam ou interpretam mal os conceitos. Isso torna-se um desafio.

Voltando à sua missão de reimaginar o desenvolvimento Ágil, compreendo a necessidade. Como? Que estratégias tem desenvolvido ou imagina utilizar para enfrentar os desafios futuros?

Jim Highsmith: Criámos uma iniciativa de reimaginação do desenvolvimento Ágil. Existe um grupo central a que chamamos Grupo de Lançamento. Estamos a tentar lançar a iniciativa, não geri-la.

Criámos um sítio Web e estamos a preparar apresentações em várias conferências sobre reimaginar o desenvolvimento Ágil: voltar aos princípios básicos, ou seja, à mentalidade, e avançar para o futuro, analisando como iremos gerir nesse contexto.

Também estou envolvido numa conferência em Portugal, em setembro, dedicada à reimaginação da gestão. Não se trata apenas de saber como desenvolver de forma Ágil num ambiente de inteligência artificial, mas também como exercer liderança e gestão nesse ambiente.

À medida que avançamos, gosto da expressão “desenvolvimento Ágil aumentado”. A inteligência artificial irá afetar de forma diferente todas as áreas do desenvolvimento de software, desde a programação e os testes até à identificação de requisitos.

Se tentarmos manter exatamente as mesmas práticas e métodos, teremos problemas. É necessário ter a mentalidade certa para dizer: “Esta era uma prática que utilizávamos, mas já não precisamos dela porque a inteligência artificial irá assumir essa função.”

Por exemplo, Martin Fowler escreveu um livro sobre refatorização. A refatorização consiste em voltar ao código e melhorá-lo.

Galen Low: Certo.

Jim Highsmith: E se tivermos uma ferramenta automática de refatorização? Talvez essa função seja integrada na ferramenta. Ainda precisaremos de compreender a refatorização a partir de uma perspetiva de mentalidade, mas as próprias práticas irão mudar devido à inteligência artificial e a outras tecnologias.

Galen Low: É esse o equivalente a reimaginar o desenvolvimento Ágil? Por outras palavras, vocês são um grupo de lançamento que vai iniciar um processo de refatorização do desenvolvimento Ágil. Mais importante ainda, estão a criar o mecanismo para que o desenvolvimento Ágil se possa refatorar ao longo do tempo. Em vez de voltarmos a este ponto daqui a 20 anos, o desenvolvimento Ágil deverá evoluir continuamente. Esse é o objetivo?

Jim Highsmith: Não tinha pensado nisso em termos de refatorização, mas penso que tem razão. Esse é um dos nossos objetivos. Queremos que as pessoas compreendam que o desenvolvimento Ágil não foi um desastre. Foi muito bem-sucedido em muitos contextos. Também existem desilusões que temos de enfrentar. Temos de descobrir como irá adaptar-se ou refatorar-se no futuro.

Temos um sítio Web com muito conteúdo e estamos a tentar envolver outras organizações. A Agile Alliance já se juntou ao grupo para realizar vários painéis em conferências. Este ano iremos também realizar um painel na conferência Ágil em Dallas.

Gostaria que a organização Scrum assumisse esta iniciativa de voltar aos princípios básicos e avançar para o futuro. A nossa abordagem não representa uma única denominação. Queremos compreender as desilusões do desenvolvimento Ágil e fazer uma análise da causa-raiz, em vez de dizer que algo é simplesmente terrível.

O que aconteceu no processo que levou à desilusão? Como podemos aprender com isso e aplicar essa aprendizagem de forma abrangente, quer se utilize Kanban, Scrum, XP ou DevOps?

Galen Low: Gosto dessa abordagem independente. Pela escala e pelo sucesso do desenvolvimento Ágil, parece que o seu esforço corresponde agora a uma espécie de diplomacia ao nível dos Estados.

Está a reunir organizações, associações e fações que se veem como entidades separadas. É necessário um momento de união para avançarmos; caso contrário, ficamos fragmentados.

Jim Highsmith: Uma competência fundamental para qualquer pessoa que queira ser Ágil, seja programador ou diretor executivo, é compreender o equilíbrio. Estamos sempre a equilibrar criatividade e controlo, colaboração e orientação.

A cultura de uma organização tem de se adaptar ao ponto em que se encontra e ao ponto para onde precisa de ir. Numa escala de 1 a 10, em que 10 é o nível máximo de agilidade e 1 significa ausência de agilidade, talvez uma organização esteja a tentar passar de 1 para 3. Será um pouco mais Ágil, mas não tanto como o Google, a Microsoft ou outra organização.

A forma de passar de 1 para 3 será muito diferente da forma de passar de 7 para 8 ou de 4 para 6. Carol Dweck escreveu um livro sobre mentalidade e fala de mentalidades de crescimento e fixas. Precisamos de algumas pessoas com os dois tipos de mentalidade.

Com o tempo, as grandes organizações tendem a acumular uma percentagem muito maior de pessoas com mentalidade fixa do que com mentalidade de crescimento, e isso é difícil de alterar. Se uma organização está no nível 1 e quer chegar ao nível 3 ou 4, talvez tenha de analisar se algumas pessoas com mentalidade fixa estão a limitar a mudança e se existem pessoas suficientes com mentalidade de crescimento para a concretizar.

Não basta ter uma pessoa assim no topo ou na base. É necessário ter alguém em cada nível disposto a assumir essa responsabilidade. Essa é uma das dificuldades da mudança cultural.

Galen Low: Também é interessante pensar no gradiente. Muitos de nós estamos programados para querer uma mudança binária, como se bastasse premir um interruptor para transformar uma organização de um dia para o outro. Mas passar de 1 para 3 também é positivo.

Jim Highsmith: No que diz respeito ao contexto, há muito tempo costumava falar em conferências organizacionais do PMI. Perguntava se as pessoas tinham projetos com requisitos bem definidos e tecnologia conhecida. Respondiam que sim. Depois perguntava se também tinham projetos com tecnologia de ponta e requisitos muito incertos. Também respondiam que sim.

Então perguntava: “Medem o sucesso da mesma forma nos dois tipos de projeto? Gerem-nos da mesma forma?” E respondiam: “Ups.” É isso que quero dizer com contexto e equilíbrio.

Temos de compreender o contexto em que estamos a trabalhar e o equilíbrio necessário. Ausência de documentação ou excesso de documentação? Planeamento de curto prazo ou planeamento de longo prazo? Onde precisamos de estar?

Uma das minhas preocupações com o planeamento de curto prazo, especialmente com a abordagem centrada exclusivamente em funcionalidades, é perdermos de vista o objetivo. Existe um objetivo de longo prazo, que é mais importante do que lançar 36 novas funcionalidades hoje.

Por isso, volto à palavra que utilizei no meu primeiro livro: especulação. Não é necessário planear tudo; é necessário especular. Temos de imaginar para onde queremos ir, sem elaborar todos os detalhes como fazíamos no passado. Ainda assim, precisamos de uma ideia do destino e do resultado que procuramos.

Galen Low: O que acho interessante é que, quando o explica, parece óbvio, mas criámos grupos mais do que técnicas. Tentamos cozinhar um peru da mesma forma que fazemos uma salada, porque somos Ágeis e só fazemos as coisas de uma maneira.

Quando analisamos realmente a situação, percebemos que, se houver muita ambiguidade, talvez seja necessária uma abordagem; se houver uma grande necessidade de previsibilidade e requisitos estáveis, talvez seja necessária outra. Não se trata de uma espátula contra um garfo. Trata-se de saber quando utilizar cada ferramenta.

Gosto da ideia de reunir as pessoas de forma independente. Não estamos a representar nenhum grupo. Estamos simplesmente a voltar a reunir-nos para refatorizar o desenvolvimento Ágil e fazê-lo avançar. Existem desilusões que afetam todos os que o utilizam ou não utilizam. Temos de as compreender e aprender com elas.

Na sua perspetiva, olhando para as metodologias de projetos e para a forma como colaboramos e entregamos resultados, para onde se dirige o futuro? Como nos preparamos para um futuro desconhecido?

Jim Highsmith: Quando estava a trabalhar no meu livro Wild West to Agile, publicado no ano passado, comecei o último capítulo a pensar que iria prever o futuro. Depois percebi que prever o futuro não era uma boa abordagem.

Como tinha escrito uma história do desenvolvimento de software a partir de uma perspetiva pessoal, percebi que estava mais interessado em saber como a história nos pode preparar para o futuro do que em prever o futuro.

O primeiro passo é compreender os padrões históricos. Quando escrevo sobre algo atualmente, procuro recuperar um período da história. Escrevi recentemente sobre métodos estruturados e sobre o que chamo metodologias monumentais da década de 1980, para mostrar que isto não é a primeira vez que algumas destas coisas acontecem.

A inteligência artificial tem passado por ciclos de entusiasmo e desilusão há 30 ou 40 anos. Muitas pessoas não têm sentido histórico, mas esse conhecimento pode ajudar.

Temos de mudar a mentalidade e a cultura. Existem muitos livros sobre gestão da mudança, mas estamos a aproximar-nos dos limites do que significa ser humano. Talvez estejamos a fazer o melhor possível, mas talvez existam formas de melhorar.

Uma forma de nos prepararmos para o futuro é redesenhar a organização. Isso inclui torná-la mais horizontal e garantir a formação e a experiência adequadas para gestores e colaboradores. Teremos de reforçar a formação.

Já não existe um percurso profissional linear. Existe um percurso de obstáculos, e cada pessoa será responsável por encontrar o seu caminho. Se eu quiser saber mais sobre inteligência artificial, tenho de descobrir por onde começar, que informação procurar, que cursos frequentar e quem poderá ajudar-me.

Temos de acelerar a melhoria das capacidades. Mais uma vez, capacidade significa conhecimento, experiência e tomada de decisões. Não basta adquirir conhecimento.

Tenho algumas reservas em relação à proliferação de certificações, mas passei a vê-las como distintivos de escuteiro. Indicam que se adquiriu algum conhecimento básico, mas não provam necessariamente a existência de experiência.

A tecnologia tornar-se-á ainda mais importante. Existem livros sobre a próxima grande transformação, que abordam não só a inteligência artificial, mas também a biotecnologia e a interação entre ambas. Poderemos ter sistemas de inteligência artificial orientados para a manipulação celular e instrumentos biológicos de custo reduzido. Em breve, poderemos ter capacidade para manipular genes, o que poderá ser tão assustador como a inteligência artificial.

Seja gestor de projetos, gestor intermédio, diretor executivo ou diretor de informação, terá de possuir compreensão e conhecimento técnicos. Isso não significa saber programar um computador, mas ter uma formação técnica mais sólida do que nunca.

Galen Low: A tomada de decisões através da experiência e do conhecimento é a forma como sempre avançámos. O que considero positivo é que estamos a falar de inteligência artificial, que parece ter surgido subitamente, embora exista há 30 anos. Estamos a falar de constituições, de mudanças anteriores e da forma como alterámos a maneira de trabalhar e comunicar.

Não nos tornámos excelentes nisso. Também não nos tornaremos excelentes apenas por analisarmos o desenvolvimento Ágil. Mas tudo faz parte do mesmo exercício.

Jim Highsmith: Fazemo-lo progressivamente melhor.

Galen Low: Sim. Progressivamente melhor. Iremos criar uma máquina que se refatora a si própria e, depois, faremos ciclos de duas semanas de biotecnologia genética. Lançaremos um novo ser vivo a cada duas semanas.

Jim Highsmith: Volto ao meu amigo Gerald Weinberg, que escreveu um livro nos anos 80 chamado Secrets of Consulting. Ele dizia que, se entrarmos numa organização a pensar que vamos alterá-la em mais de 10%, estamos a enganar-nos a nós próprios.

Galen Low: É perfeitamente justo. Gostei muito desta conversa, Jim. Muito obrigado por participar no programa. Houve aqui muitas ideias excelentes. Gostaríamos de o receber novamente.

Jim Highsmith: Obrigado. Gostei muito e teria todo o gosto em repetir a experiência.

Galen Low: Antes de terminar, onde podem as pessoas encontrar o seu livro mais recente?

Jim Highsmith: Podem encontrá-lo em qualquer livraria. Chama-se Wild West to Agile. É metade história do desenvolvimento de software e metade memórias pessoais.

Galen Low: Gosto muito disso. Excelente. Vou incluí-lo nas notas do programa abaixo.

Jim Highsmith: Obrigado.

Galen Low: Muito bem, aqui está. Como sempre, se quiser juntar-se à conversa com mais de mil defensores da gestão de projetos com interesses semelhantes, venha fazer parte da nossa comunidade! Visite thedigitalprojectmanager.com/membership para saber mais. Se gostou do que ouviu hoje, subscreva o programa e mantenha-se em contacto através de thedigitalprojectmanager.com.

Até à próxima. Obrigado por nos ouvir.