Fazer o Agile Funcionar com Metagility (Com David Bishop da Agile Worx)

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa de software. Perdoe quaisquer erros tipográficos, uma vez que o bot não está correto a 100% do tempo.

Ben Aston: Então deixe-me adivinhar: estava a fazer as coisas em Cascata, isso não funcionou e depois experimentou Agile — e bem, isso também não está propriamente a funcionar.

Por isso, agora está a misturar e combinar. Tem uma colher de Agile e uma colher de Cascata e está a tentar encontrar alguns granulados para colocar por cima. Bem, continue a ouvir o podcast de hoje sobre metagility. Talvez aprenda uma ou duas coisas sobre como um manual Agile pode ser utilizado para combinar o melhor dos dois mundos.

Obrigado por nos ouvir. Eu sou Ben Aston, fundador do The Digital Project Manager. Bem-vindo ao podcast do DPM. Estamos empenhados em ajudar os gestores de projetos a ter sucesso e as pessoas que gerem projetos a entregá-los melhor. Estamos aqui para o ajudar a levar a gestão dos seus projetos para o nível seguinte. Visite thedigitalprojectmanager.com para saber mais sobre a formação e os recursos que disponibilizamos através da adesão. Este podcast é-lhe apresentado pela Clarizen, líder em software empresarial de gestão de projetos e portefólios. Visite Clarizen.com para saber mais.

Hoje, estou acompanhado por David Bishop. O Dr. David Bishop é tecnólogo, consultor, empreendedor de investigação e formador, com mais de 25 anos de experiência nos setores das telecomunicações, transportes, administração pública e serviços públicos. É CEO e fundador da Agile Worx, LLC. Pode consultar o site em Agile-worx.com. A empresa disponibiliza ferramentas de software para gestão de programas e projetos, formação e serviços de consultoria. É também autor de Metagility: Gerir o Desenvolvimento Agile para Obter Vantagem Competitiva. Muito obrigado por se juntar a nós hoje, David.

David Bishop: Obrigado pelo convite.

Ben Aston: Quero aprofundar esta ideia de construir uma estrutura a partir do nada. Pode falar-nos um pouco sobre o seu percurso e sobre como decidiu que o mundo precisava de uma nova estrutura? Que experiência o conduziu até esse ponto?

David Bishop: Tenho trabalhado no desenvolvimento tecnológico há cerca de 25 anos, sobretudo como arquiteto de sistemas e engenheiro de sistemas, desenvolvendo soluções com novas tecnologias. Trabalhei no setor das TI, bem como nas áreas da aviação, das comunicações móveis e das telecomunicações. Como referiu anteriormente, há cerca de 10 anos comecei a trabalhar com uma empresa profundamente envolvida na Internet das Coisas Industrial e uma das coisas que tentava desesperadamente fazer era adotar metodologias Agile.

Ben Aston: Certo.

David Bishop: A razão era os clientes pedirem isso. A empresa encontrava-se numa área relativamente nova, sobretudo no que dizia respeito à tecnologia. Tentava integrar-se nesse setor e havia muitos concorrentes a desenvolver esta nova tecnologia de redes inteligentes, com todas as diferentes comunicações de radiofrequência.

A empresa tentou várias vezes adotar Agile, porque era fundamental conseguir utilizar Agile para colocar os seus produtos no mercado tão rapidamente quanto possível. Tentou várias vezes, contratou muitos consultores altamente remunerados e falhou completamente, uma vez após outra. Eu fazia parte desse processo. Ajudava a organização a desenvolver esses produtos e também a adotar Agile. Pensei que tinha de existir uma forma diferente de fazer aquilo.

Porque é que tantos consultores muito inteligentes que contratávamos tinham tantas dificuldades? Percebi que, infelizmente, embora Agile tenha tido muito sucesso e seja certamente uma excelente ideia, também apresenta algumas limitações. Uma delas está relacionada com equipas distribuídas, equipas grandes, ambientes de desenvolvimento muito complexos e produtos complexos ou complicados. Estes aspetos podem ser enormes desafios para quem tenta adotar a metodologia Agile na sua forma mais pura.

Ben Aston: Sem dúvida. Pode falar-nos um pouco da sua experiência nesses projetos? Estou curioso sobre o que acontecia no terreno, no dia a dia. Consigo compreender a visão geral dos desafios de uma implementação Agile, mas como era a realidade quotidiana? O que lhe indicava que algo não estava bem?

David Bishop: Havia uma enorme resistência por parte de algumas equipas. Não estou a falar de uma resistência superficial; era uma resistência muito forte e havia queixas de que o processo simplesmente não funcionava nem poderia funcionar. Isto acontecia porque estávamos num ambiente de sistemas incorporados. Como estavam a desenvolver produtos de IoT industrial, esses produtos não eram apenas software: eram dispositivos. Os dispositivos são normalmente compostos por sistemas incorporados, nos quais o hardware, o firmware e o software são desenvolvidos por equipas, departamentos ou até empresas diferentes.

Em determinado momento, os três componentes têm de ser testados e lançados como um único produto coeso. Era isso que a empresa fazia. Esta é a razão pela qual este contexto é tão interessante: é aí que está a acontecer grande parte da inovação atual. Há muitos anos, quando o manifesto surgiu, tudo se centrava no software. Hoje, não se trata apenas de software.

Trata-se de dispositivos, dispositivos inteligentes, contadores inteligentes, carros inteligentes e telemóveis. Atualmente, praticamente tudo é um dispositivo com sistemas incorporados. Por isso, as empresas que desenvolvem este tipo de produtos têm mais dificuldade em trabalhar com agilidade devido à complexidade. No dia a dia, trabalhávamos com consultores que tentavam dizer: “As vossas equipas de software trabalham em ciclos de duas semanas e fazem reuniões diárias, mas não conseguimos fazer com que as equipas de hardware façam o mesmo. Elas não consideram isso necessário.”

Ben Aston: Certo.

David Bishop: As equipas de firmware tinham o mesmo problema. Diziam que aquilo não funcionava bem para elas e que não fazia sentido. E era verdade, porque as equipas de software trabalhavam muito mais depressa. Conseguíamos desenvolver em iterações, mas isso não funcionava tão bem com as equipas de hardware, que trabalhavam de outra forma. Os seus produtos tinham ciclos de lançamento de 12 a 18 meses.

Leva muito tempo a integrar um conjunto de circuitos no hardware e a testá-lo cuidadosamente. Além disso, a maioria das organizações que desenvolvem sistemas incorporados trabalha em setores com muito mais regulamentação, conformidade regulatória, supervisão governamental e aspetos semelhantes.

Se pensarmos em contadores inteligentes e empresas de energia, carros inteligentes ou sistemas aviônicos numa aeronave, é fácil perceber que os riscos são muito maiores, devido à possibilidade de perda de vidas ou de falhas catastróficas. Por isso, têm de cumprir padrões muito mais elevados de qualidade, desempenho e sucesso do que uma aplicação de software normal ou um sítio Web de comércio eletrónico.

Ben Aston: O que é perfeitamente compreensível.

David Bishop: A maioria das metodologias Agile foi adotada mais rapidamente e mais cedo precisamente pelos setores onde estas condições não se verificavam.

Ben Aston: Se quiser saber mais sobre a origem da Metagility, pode consultar o artigo em thedigitalprojectmanager.com. O artigo explica a evolução da ideia e a história da criação do livro. Em vez de aprofundarmos essa história, quero explorar a própria estrutura e perceber que elementos podemos aplicar aos nossos projetos. Isto é particularmente relevante porque muitos de nós experimentámos elementos de Cascata.

Trabalhamos sequencialmente porque parece fazer mais sentido, devido às partes interessadas e à forma como os nossos compromissos estão estruturados. Mas também utilizamos alguns elementos Agile: colaboramos, trabalhamos iterativamente e aproveitamos partes de diferentes abordagens. Adotámos a filosofia de iterar e entregar valor com frequência.

Construímos, testamos e aprendemos. No entanto, na prática, temos de trabalhar sequencialmente. Quero falar sobre metagility e sobre como podemos aplicá-la aos nossos projetos. As metodologias Agile são populares e amplamente aceites como a melhor forma de gerir o desenvolvimento de software, mas o significado concreto de metodologia Agile está aberto à interpretação.

Esta abordagem híbrida, embora nem sempre seja apresentada como a melhor solução, é na realidade o resultado adotado por muitas pessoas que tentam combinar diferentes estruturas e formas de trabalhar com as limitações das organizações. O hardware tem ciclos de construção mais longos do que o software e o middleware situa-se algures no meio. O desafio é construir componentes que possam ser lançados com uma cadência semelhante.

David Bishop: Quando falamos de estruturas como Scrum, Kanban e muitas outras, cada uma tenta abordar o problema de uma perspetiva diferente. Existem DSDM, LeSS e DA, ou Disciplined Agile, que foi recentemente adquirido pelo PMI. Cada estrutura se concentra num nível diferente.

A verdadeira finalidade de Agile é a competitividade: ser o número um no seu mercado. O Manifesto Agile foi influenciado pela produção Lean, que por sua vez surgiu do sistema de produção da Toyota. A ideia da agilidade é reproduzir esse tipo de sucesso e tornar-se líder no mercado.

O SAFe concentra-se no nível empresarial; o Scrum concentra-se no nível das equipas; o Kanban concentra-se no nível do processo e do trabalho em curso. A metagility concentra-se no motor de desenvolvimento do produto: gestão de produto, gestão de projetos, equipas de desenvolvimento e de testes, desenvolvimento e interpretação de requisitos, testes, lançamento no mercado e colaboração com o cliente.

Se quiser ganhar uma corrida de arrancada, concentra-se no motor, na transmissão e no sistema de tração, não nos vidros elétricos ou no ar condicionado. De forma semelhante, algumas estruturas concentram-se demasiado na periferia em vez de se concentrarem no que é necessário para ser o número um no mercado.

A metagility baseia-se em estudos de caso de organizações que conseguiram alcançar uma adaptação Agile extraordinária. Essas organizações utilizaram a agilidade para se tornarem líderes de mercado. A metagility reúne o que essas empresas fizeram corretamente e tenta transformá-lo num modelo que outras organizações possam reproduzir.

Ben Aston: Como descreveria a metagility? É uma estrutura de entrega, uma metodologia ou um manual?

David Bishop: Descreveria-a simplesmente como uma estrutura. A metagility começa por determinar que tipo de adaptação Agile é necessário. Antes disso, o livro ensina a pensar de forma diferente, utilizando metodologias de investigação e métodos científicos para tomar decisões empresariais.

Quando se chega à transformação Agile, uma das primeiras perguntas é que tipo de implementação deve ser adotada: uma implementação Agile pura, uma abordagem híbrida ou Cascata? Em alguns casos, Cascata pode ser a escolha certa.

A investigação indica que a decisão deve considerar a complexidade das dependências e interdependências do produto e da organização, bem como o tamanho das equipas. Em sistemas incorporados, com produtos complexos e equipas distribuídas, uma abordagem Agile pura normalmente não funciona. É necessário adotar uma abordagem híbrida de forma intencional.

Por exemplo, as equipas de software podem trabalhar em ciclos de duas semanas e realizar reuniões diárias, enquanto outras equipas podem trabalhar em ciclos de 30 dias. As equipas de hardware, com ciclos de 12 a 18 meses, podem utilizar uma abordagem mais próxima de Cascata, recorrendo a técnicas como a prototipagem rápida para acompanhar as restantes equipas e evitar bloqueios.

A metagility define como as diferentes equipas podem adotar conceitos Agile ou de Cascata. Os pontos de controlo de fases podem funcionar como verificações e equilíbrios para garantir que as equipas, que trabalham a velocidades diferentes, permanecem sincronizadas.

A metodologia também define as métricas a utilizar e seis categorias de interações, com base nos estudos de caso mais bem-sucedidos. Explica que interações devem existir, como implementá-las e como geri-las. Assim, transforma-se num manual detalhado para gerir uma implementação Agile híbrida.

Ben Aston: Como se determina a combinação adequada dessas características Agile? Como se sabe quando o estado atual é aceitável e quando é necessária uma evolução ou uma revolução do processo?

David Bishop: A melhor forma é utilizar uma metodologia científica e investigação empresarial participativa. Muitas vezes, as pessoas usam a intuição, as melhores práticas ou entrevistas para chegar a um consenso. Isso pode funcionar para decisões comuns, mas uma transformação Agile, DevOps ou digital exige uma abordagem mais rigorosa.

Os ambientes de sistemas de informação são altamente contextuais. Diferem muito de empresa para empresa, e o que funciona num lugar pode não funcionar noutro. Através de metodologias científicas, como estudos de caso interpretativos e etnografias, é possível identificar o que pode ser generalizado entre organizações.

Ben Aston: Portanto, esta não é uma estrutura única para todos; é uma estrutura personalizável. Como se avalia se uma implementação é realmente metagility e se foi bem-sucedida?

David Bishop: A metagility inclui também a teoria da vorticidade Agile. Este conceito surgiu da investigação e responde à pergunta: quão Agile é a sua organização? Durante muito tempo não existiu uma forma real de medir a agilidade. A vorticidade Agile fornece essa possibilidade e permite avaliar o sucesso da transformação.

Ben Aston: Que impacto observou nas organizações que implementaram a sua estrutura?

David Bishop: Muitos dos nossos estudos de caso foram realizados no mercado dos sistemas incorporados, que é um dos mais exigentes. As empresas que adotaram conceitos de metagility conseguiram, na maioria dos casos, tornar-se líderes de mercado ou aproximar-se dessa posição.

Isto traduz-se em maior quota de mercado e na colocação de mais dispositivos nas mãos dos clientes do que os concorrentes. A chave para a longevidade é conquistar uma quota de mercado crítica antes dos concorrentes, adotando tecnologia inovadora e disponibilizando-a no mercado primeiro.

Ben Aston: Onde viu a metagility falhar? Quais são os principais desafios?

David Bishop: Existem dois pontos específicos. O primeiro é a falta de apoio executivo. Qualquer transformação precisa de apoio e compromisso da liderança. É necessário apresentar um caso de negócio convincente, mostrando como a transformação afeta os resultados financeiros e a competitividade.

O segundo é uma gestão deficiente dos requisitos. Muitas organizações concentram-se nas equipas de desenvolvimento e testes, mas dão pouca atenção à forma como os analistas de negócio desenvolvem requisitos. Num ambiente Agile, não se recolhem simplesmente requisitos: desenvolvem-se requisitos em colaboração com o cliente.

Num ambiente de Cascata, existe um âmbito bem definido e a preocupação com o aumento do âmbito. Num ambiente Agile, os requisitos são desenvolvidos iterativamente. Se os analistas tentarem identificar tudo através de sessões de brainstorming, criarão cada vez mais requisitos, tornando impossível priorizá-los. As versões ficam sobrecarregadas, surgem funcionalidades pouco utilizadas e a dívida técnica aumenta.

Ben Aston: Qual seria o primeiro passo para uma organização aplicar metagility?

David Bishop: O primeiro passo é estabelecer novas relações com os clientes. A colaboração com o cliente e a negociação contratual são, na realidade, partes do mesmo processo. Essa negociação ocorre continuamente entre as partes interessadas de toda a organização.

É necessário estabelecer uma relação colaborativa com o cliente, que deve participar no processo, sobretudo quando se pretende lançar rapidamente um produto inovador. Também é necessário definir uma visão e escolher os clientes que estão dispostos a colaborar. Os estudos de caso mais bem-sucedidos recusaram alguns clientes que não queriam participar nesse processo.

Ben Aston: São excelentes palavras de conselho. Muitas vezes aceitamos tudo o que entra pela porta, mas, para entregar valor real aos utilizadores finais e aos clientes, precisamos de um modelo de compromisso que incentive a colaboração. Muito obrigado, David, por se juntar a nós e falar sobre metagility.

David Bishop: Muito obrigado.

Ben Aston: Gostaria de saber o que pensa. Já leu o livro metagility ? Diga-nos nos comentários o que achou. Se ainda não o leu, incluiremos uma ligação na transcrição. David, onde podem as pessoas saber mais sobre si e sobre o seu livro?

David Bishop: Pode pesquisar a palavra metagility no Google, onde encontrará muitos recursos. Também pode visitar Agileworx.com (Agile-worx.com) para conhecer a nossa empresa e o nosso trabalho. Também disponibilizamos alguns cursos. Pode consultar o calendário atualizado em metagility.technology e inscrever-se nos cursos. Também pode contactar-me através de David@agileworx.com (Agile-worx.com).

Ben Aston: Muito bem. Obrigado, David. Se quiser saber mais e progredir no seu trabalho, junte-se a nós. Faça parte da nossa comunidade através da adesão ao DPM. Visite thedigitalprojectmanager.com/membership para obter acesso à nossa equipa no Slack, aos nossos modelos, workshops, sessões AMA, horários de atendimento, livros eletrónicos e muito mais. Se gostou do que ouviu hoje, subscreva e mantenha-se em contacto através de thedigitalprojectmanager.com. Até à próxima. Muito obrigado por nos ouvir.