„Desculpa, mas Agile não melhora os teus produtos"
Já publicamos o post de Jeff Sutherland, no qual ele responde a uma publicação de Adam Pisoni, que afirma que o Agile na verdade não melhora seus produtos. Aqui está justamente esse post de Adam Pisoni, cofundador e ex-diretor técnico do Yammer e fundador da Responsive.org.
Se você não lê regularmente os trabalhos de Steve Denning, recomendo que comece a fazer isso. Ele é um dos melhores autores quando se trata do futuro do trabalho. Em um artigo que escreveu para a Forbes, ele diz que o desenvolvimento ágil de produtos se tornou mainstream, mas também levanta a questão de se ele também se tornou uma moda passageira, assim como tantas outras teorias de gestão. Sua conclusão é que o Agile não é realmente uma moda passageira, pois
„Agile e Scrum abordam diretamente questões empresariais atuais que as iniciativas do século 20 evitaram. Em Agile e Scrum, os clientes ganham voz através do Product Owner e as competências são colocadas acima da autoridade."
Embora eu concorde em geral com muitos pontos do artigo dele, preciso discordar da sua conclusão. O Agile realmente deu um bom passo na direção certa, mas para mim isso não vai longe o suficiente. Antes do Agile existir, acontecia com muita frequência que equipes precisavam de muito tempo e recursos para construir algo, apenas para descobrir no momento da conclusão que o cliente nem queria aquilo.
O Agile deveria principalmente possibilitar a construção de produtos bem-sucedidos em um mundo que muda rápido demais para prever o que as pessoas querem e como melhor construir isso para elas.
Embora o Agile tenha ensinado a toda uma geração de desenvolvedores de software a importância da experimentação e do feedback dos clientes, o Agile não conseguiu mudar o antigo sistema centralizado de comando e controle na gestão, o que representa uma grande parte do problema. Mesmo com Agile, desenvolvedores que têm pouca influência e pouco contexto ainda demoram muito para desenvolver produtos que os clientes na verdade nem querem. Isso resulta em clientes insatisfeitos, desenvolvedores desmotivados e gestores frustrados.
Só para informação, de 1995 a 2014 eu sempre fui – exceto por uma breve interrupção após o estouro da primeira bolha das pontocom – ou desenvolvedor de software em tempo integral ou líder de equipes de desenvolvimento. Em 1997 eu liderava uma equipe que usava o método cascata (predecessor do Agile). No cascata, todo o trabalho de design e planejamento era feito antecipadamente, assumindo que o trabalho poderia então ser dividido e concluído.
Em 2004 eu trabalhava para uma empresa que confiava fortemente em análises e testes A/B e tinha até releases semanais – com tudo isso ela estava à frente do seu tempo. Lembro-me de quando as pessoas falaram de Scrum pela primeira vez, e lembro-me de ter uma visão clara do problema que eu estava tentando resolver: má gestão.
Para ser justo, preciso dizer que reli o Manifesto Ágil e seus princípios e concordo com cada ponto. Eles são tão bons e pertinentes hoje quanto eram em 2001, quando foram escritos. No Agile, deve-se construir algo de forma iterativa e aprender continuamente durante o processo, em vez de seguir um grande plano. Além disso, o cliente deve ser um parceiro próximo em todo o processo, para que se possa aprender com ele durante toda a fase de desenvolvimento. Como o objetivo deve ser absorver permanentemente novas informações, também se deve esperar mudar de direção regularmente.
Antes do Agile existir, a gestão criava um plano que documentava exatamente (previa) o que deveria ser construído, como deveria ser construído e quanto tempo isso levaria – sendo este último provavelmente a parte mais importante. Como sabemos, esses planos eram dificilmente previsíveis e raramente podiam ser cumpridos. O resultado eram expectativas e prazos irrealistas.
Para piorar as coisas, devido ao atraso entre a conclusão do plano e a entrega do produto, era muito provável que a gestão mudasse de opinião sobre o produto sem nenhum entendimento dos custos. Isso naturalmente irritava muitos desenvolvedores, cujo trabalho era executar o "plano". Isso significava que a situação com prazos irrealistas só piorava e forçava muitas equipes a tentar minimizar mudanças posteriores através de ainda mais planejamento. Ironicamente, a falta de transparência no processo de desenvolvimento dava às equipes de desenvolvimento mais autonomia para decidir em que ordem realizariam os trabalhos, como os construiriam, quem faria isso, etc. Naturalmente, a consequência dessa forma de autonomia e da falta de transparência é frequentemente desconfiança entre gestão e equipe de desenvolvimento. No final, ninguém estava feliz.
E então veio o SCRUM. Ele deveria aumentar a transparência no processo e melhorar a eficiência no desenvolvimento. Semanalmente, os gestores podiam decidir quais stories (ou features) queriam em seguida e os desenvolvedores podiam então estimar quanto tempo e recursos precisariam para isso. A equipe podia então determinar o custo total de todas as stories priorizadas e descobrir quanto desse trabalho conseguiriam assumir para o próximo Sprint.
O Scrum aumentou drasticamente a transparência e tornou mais difícil para os gestores exigirem mais do que é possível realizar. A necessidade de atualizar planos de forma iterativa também foi considerada. Porém, através da transparência aumentada no Scrum, os desenvolvedores têm ainda menos autonomia do que antes. Os poderes dos desenvolvedores foram reduzidos a definir quanto tempo provavelmente levará para algo e escolher a próxima story de uma lista que é em grande parte determinada pela gestão.
Um desenvolvedor trabalhando em uma story pode não ter nenhuma noção do contexto e por que essa story é tão importante ou qual é a iniciativa por trás dela.
Embora o Scrum tenha conseguido conter gestores impulsivos, no final das contas acabou sendo sobre exercer mais controle sobre os desenvolvedores e seu trabalho.
A gestão ainda toma decisões, prioriza as features e determina quem trabalha em que equipe e em quê. Com seu foco na estimativa de esforço de trabalhos predeterminados e pouco contexto, o Scrum olha para a virada do século, quando Frederick Taylor dava instruções detalhadas aos trabalhadores de fábrica.
No Taylorismo, assume-se que os gestores são aqueles que possuem a expertise e o contexto para determinar no que se deve trabalhar. Portanto, era tarefa deles dar planos detalhados aos funcionários, para que estes precisassem tomar o mínimo possível de decisões próprias.
Bem no final dos Princípios Ágeis aparece um fundamento bastante deslocado que é ignorado pelo Scrum:
As melhores arquiteturas, requisitos e designs surgem de equipes auto-organizadas.
Teoricamente, é possível usar Scrum para acompanhar o trabalho em equipes auto-organizadas, mas isso não é o objetivo e acontece muito raramente. A maioria dos livros sobre Scrum aborda o tema da perspectiva do gerenciamento top-down e não através da auto-organização.
Agile foi um passo importante para reconhecer a importância dos testes e do trabalho iterativo baseado no feedback dos clientes. Em grande parte, porém, está orientado para maior eficiência e controle vs. empoderamento ou equipes auto-organizadas. Um dos autores do Manifesto Ágil, Andy Hunt, também vê dessa forma.
Claro, pode-se argumentar que o Agile não é o problema, mas sim métodos como Scrum. Essa diferença sutil se perde, já que Scrum e Agile se tornaram praticamente sinônimos. Quando o Agile se tornou mais conhecido, infelizmente foi desvirtuado por modelos tradicionais de comando e controle, de onde surgiram métodos como Scrum.
Qual é a alternativa? Dê uma olhada nos métodos de desenvolvimento do Spotify ou nas estruturas do Yammer. Em vez de sobrecarregar pessoas individualmente com trabalho, dê às equipes mais autonomia para decidir o que querem construir e como. Essas equipes também são compostas por pessoas das mais diversas disciplinas, para garantir que possam realizar tudo o que for necessário sem precisar esperar pela permissão ou apoio de outros.
Independentemente de você estar usando Scrum na sua organização ou não – se você tem a sensação de que está avançando muito devagar e não está construindo o que seus clientes querem, existem várias formas de experimentar novos modelos sem precisar mudar tudo de uma vez.
Escolha um projeto e monte uma equipe pequena e dedicada com pessoas que tenham todas as habilidades necessárias, mesmo que essas pessoas tenham gestores diferentes. Apresente o problema a elas e dê a oportunidade de resolvê-lo da forma que acharem melhor.
Idealmente, esse projeto é curto o suficiente para descobrir rapidamente se o experimento funciona. Se você hesita em dar essa autonomia à equipe, ou você escolheu as pessoas erradas, ou talvez o problema esteja em você mesmo. Chamar de "experimento" pode ajudar a vender sua ideia. Muito provavelmente você vai descobrir que equipes pequenas, dedicadas e multifuncionais de especialistas conseguem realizar muito em pouco tempo.
O próximo desafio é descobrir como escalar isso, caso funcione. Para isso, normalmente são necessárias novas soluções, o que leva a novos problemas, para os quais são necessárias novas soluções. Não é fácil, mas vale a pena.
Você vai perceber que está funcionando quando sua equipe conseguir apresentar mais ideias novas aos clientes de forma mais rápida do que antes. Esse é o objetivo.
Autonomia requer confiança e isso, por sua vez, requer contexto compartilhado. É por isso que esses modelos mais recentes dependem de transparência total para manter todos informados. Na Yammer, temos equipes de projeto de curta duração, para que as pessoas tenham mais oportunidades de realmente trabalhar e aprender com uma variedade de pessoas diferentes – mas essa é apenas uma forma de abordar isso.
Não basta que a gestão seja apenas a voz dos clientes. Desenvolvedores e designers precisam entender e internalizar por conta própria as necessidades e objetivos das pessoas para quem estão construindo.
Agile foi um passo importante para longe das organizações e métodos da era industrial. No entanto, se você quer criar uma organização para o século 21, precisará olhar além do Agile para modelos mais recentes que distribuem autoridade, são auto-organizados e realmente convidam seus clientes, parceiros e colaboradores a se tornarem "donos" do processo.
Este texto é do [Blog da First Round]8https://firstround.com/revisao/im-sorry-but-agile-wont-fix-your-products/ "Produtos Ágeis") e foi traduzido por nós para o alemão.
Para Scrum Masters oferecemos os seguintes treinamentos e oportunidades de formação gratuitas:
