“Os maiores aprendizados ocorrem às margens da discordância” Frank Vega
Já faz um tempo que eu penso sobre um episódio da minha vida que até aproximadamente 6 meses atrás eu julgava como uma péssima experiência. Esse episódio servirá como pano de fundo para essa série de posts sobre a tal complexidade, ou melhor, sobre o domínio complexo e suas relações com o Agile. Antes de mais nada já adianto que a visão da comunidade Agile sobre o tema é no mínimo superficial, muitas vezes enviesada, várias vezes errada… Pretendo terminar a série em 4 ou 5 artigos, mas o céu é o limite. O assunto é bastante abrangente e vou resumir 5 anos de descobertas com esse tema.
Uma história…
No inverno de 2011 tive a sorte de estar com Alisson Vale, Juan Bernabó, Alexandre Gomes, Vinicius Teles, Klaus Wuestefeld, Bruno Pedroso, Paulo Fagiani, Marcelo Murad, Renato Willy, Sylvestre Mergulhão, Rafael Lima, Henrique Bastos, Rodrigo Toledo, Clavius Tales e Saulo Arruda na praia da Taiba no Ceará. Talvez alguns de vocês são saibam quem são esses caras – eles são a primeira geração de agilistas daqui do Brasil. São os caras que antes do Agile cruzar o abismo estavam lá aplicando principalmente XP e evangelizando numa época que ser Agile não era “cool”. Ser ágil antes de 2009 era pedir para ser taxado de louco inconsequente no mercado. Esses caras nessa época de 2011 já estavam em outra “onda” – hoje eles são empreendedores seriais, nômades digitais ou fazendo carreira internacional. Agile para eles se tornou uma ferramenta junto a muitas outras. São os caras mais inteligentes que conheço.
Eu não vou conseguir citar nomes ou detalhes da parte interessante da história que vem a seguir. Tentei reunir algumas narrativas com os que estavam ali presentes nos últimos dias, porém, reconheço que minhas qualidades como historiador são bem limitadas. Contarei aqui os fatos como os vi. Neste encontro de 2011 passamos o dia na piscina, tomando cervejas, conversando, rindo e discutindo sobre startups. Era um momento pré-lançamento do livro Lean Startup do Eric Ries e todos estávamos envolvidos em produtos ou empreendedorismo digital de alguma forma. Tivemos um belo por-do-sol naquela tarde quente e logo após o jantar – estimulados pelo bate-papo que rolou durante todo o dia – alguém deu a ideia: “- Vamos codar!!”. Excelente ideia, mas as coisas não saíram como queríamos. Antes mesmo de começarmos a criar algo, ainda na definição dos objetivos, aconteceu o inesperado: a discussão se acalorou bastante e evoluiu para algo em que estávamos falando alto uns com os outros, 
discutindo duramente e não se concordando de jeito nenhum. Teve uma grande, não pequena, dissensão entre nós totalmente irreconciliável. Todos ali, amigos, experientes, bons conhecedores da importância da auto-organização e do trabalho em equipe, simplesmente não conseguimos nos entender. Sem a emergência de uma liderança que poderia nos unir, o grupo se dividiu em três times menores de 2 ou 3 pessoas e partimos para nossas mesas para desenvolver os experimentos pareando. A situação ficou assim, sem os grupos conversarem entre si e senti até uma certa animosidade competitiva entre nós. Eu era e ainda sou um aprendiz de líder, o sentimento de derrota que tive foi abissal. Conversei com alguns tentando bancar o líder carismático usando a falácia etílica (vamos abrir uma cerveja!), mas isso só os irritou ainda mais.
Os times separados trabalharam de forma bastante energizada e depois de algumas horas colocamos os experimentos no ar. Foram 3-4 horas de trabalho, escrevendo código, colocando conteúdo em redes sociais e até mandando SMS para conhecidos – um MVP de verdade. Um dos experimentos estava se direcionando para um aplicativo onde seus amigos poderiam “dar um toque” em alguma pisada na bola sua: ele se chamava “Bafo de Onça” (bastante sugestivo). O outro experimento que emergiu se chamava “A fim de você” que em 2011 facilmente poderia evoluir para um Tinder. Durante 5 anos essa história me assombrou bastante. Como um time dos sonhos não conseguiu ter um consenso ou ao menos entendimento para trabalharmos juntos por algumas horas? Se o que fizemos separados foi tão bom o que será que teríamos conseguido juntos? Outra pergunta inevitável: o que faltou?
Antes mesmo de continuar esse texto quero que você faça um experimento: pegue um papel ou abra um editor de texto e responda: se algo parecido acontecesse na equipe que você lidera como você agiria? Que técnicas utilizaria? Como solucionaria? Se você realmente quiser ter uma experiência de aprendizado nessa série de artigos registre agora sua resposta antes de continuar.
(você deveria agora investir 3-5 minutos para cumprir meu desafio no parágrafo acima – guarde suas respostas para toda a série de artigos)
Minha história com a tal “Complexidade”
Na virada do milênio eu era “um cara de RUP” (Rational Unified Process). Eu tenho orgulho disso, pois nessa época já usava abordagens iterativas e incrementais na interpretação da literatura de Ivar Jacobson, Grady Booch e James Rumbaught. No RUP complexidade se resume a risco. Você usa as fases do RUP basicamente para saber o que fazer (risco do escopo), estabelecer uma arquitetura (risco técnico), vencer o tamanho do projeto (risco do prazo) e finalmente fazer o roll-out do software para os usuários (risco de implantação). Tudo isso usando iterações (a mãe dos Sprints). Até 2006 eu não conhecia nada diretamente sobre complexidade até ter contato com a obra de Ken Schwaber. O Scrum me ensinou que o risco era uma visão limitada do que realmente acontecia num projeto de software. Infelizmente não estou com meu livro “Agile Project Management with Scrum” aqui em mãos (se você pegou emprestado por favor devolva) para colocar a citação correta, mas Ken diz no livro que “o ambiente de trabalho do século XXI é complexo” – e nesse fundamento está baseado o empirismo do Scrum, destacando a necessidade da descentralização e auto-organização do time. Sem dúvidas isso foi uma “sacada” incrível para mim. Guiados por um cara de negócios o time Scrum se concentra dentro da Sprint para cumprir um objetivo. Entender que o ambiente de desenvolvimento de software é complexo e que havia outros riscos ocultos do RUP me trouxe uma nova luz sobre como gerenciar projetos de TI.
Em 2011, alguns meses antes do relato do que aconteceu no encontro da Taiba, sob influência do Alisson Vale, participei da minha primeira conferência de Kanban. A Lean Systems and Software Conference em Long Beach – Califórnia (a LSSC11 foi precursora dos eventos da Lean-Kanban Inc) foi uma conferência fenomenal, uma das melhores que já fui. Lá conheci o Dave Snowden. Dave é um galês bonachão muito erudito e um tanto crítico. Ele tem o senso de humor bastante ácido que notei ser um traço comum com David J. Anderson (o criador do Kanban) que é escocês. Tem alguma zica ali pra cima no Reino Unido. O Dave apresentou o framework Cynefin na sua palestra e o que tinha no meu modelo mental teve que ser quebrado mais uma vez. Eu entendia até aquele momento que o Scrum era um mecanismo para fazer as coisas funcionarem na presença da complexidade. Lean Startup também dizia para rodar experimentos e aprender em ambientes de incerteza. O Dave na sua palestra disse “temos que transformar nossos ambientes de trabalho de fail-safe para safe-to-fail” (livre-de-falhas e livre-para-falhar não me parecem traduções plausíveis). Logo em seguida, em crítica ao mecanismo de Timebox do Scrum ele disse: “ao entender Complexidade você não precisa mais de caixas (boxes – criticando os timeboxes), você está num fluxo”.
Desde 2009 eu já questionava muito o timebox do Scrum. É um mecanismo inteligente, mas engessado demais e eu estava sofrendo em alguns clientes com Sprints. Criar urgência com prazos não me parecia coerente com complexidade entre outras coisas. No fim da Sprint emergem umas coisas muito bizarras. O Dave tinha uma explicação melhor dos fenômenos que via no meu trabalho como consultor. O Cynefin era superior à teoria do Scrum para explicar a Complexidade. Então, a partir de 2011, comecei a devorar material do Dave pois ele parecia saber o que dizia. Tive o previlégio de encontrar com o Dave mais uma vez no Lean-Kanban North America 2014 em San Francisco e participei de um punhado de excelentes discussões no Twitter com ele, o que até me rendeu uma menção modesta no seu blog. O Cynefin ferveu na comunidade Kanban mundial. Introduzi o assunto na comunidade brasileira algumas vezes (Agile Brazil 2012, QCon 2013, Scrum Gathering Rio 2015) e tem algumas menções ao assunto aqui no blog.
Paralelamente a esse começo da minha história com a complexidade surgiu o Management 3.0, um movimento que poderia levar a Complexidade para o mundo Agile. O M3.0 não me convenceu e alguns boatos surgiram no mercado das minhas reservas com o modelo. Um dos objetivos desse artigo é deixar claras minhas posições sobre o Management 3.0: o Jurgen Appelo no seu livro fez um trabalho bibliográfico singular – sem dúvidas é um erudito – porém, o que ele apresenta sobre complexidade é bem pouco prático. O autor me parece ter uma necessidade insana de querer passar a imagem que sabe muito de complexidade, tornando-a uma arte para poucos iluminados. Para ele conhecer sobre complexidade é um pré-requisito para poder gerenciar. Seu modelo “Structure/Behavior” é no mínimo precipitado. Durante o restante essa série de artigos irei apresentar porque complexidade não é um bicho de 7 cabeças, como usar a teoria a seu favor e, principalmente, porque sua startup pode ser MUITO prejudicada pelo Scrum ou Agile Ortodoxo.
Continuar para a Parte 2 – Cadência Básica >>