=== Script
Olá pessoal, Fabio Akita
O vídeo que eu fiz chamado "Esqueça metodologias Ágeis" fez um sucesso enorme no canal e vocês andaram compartilhando pra lá e pra cá e eu agradeço bastante por isso! Eu fiz o video como faço todos os outros: eu peguei um assunto que me interessa e tentei explicar de uma forma que a maioria consiga entender, e eu realmente não esperava que fosse viralizar assim. Ao que parece muito mais gente do que eu pensava estava incomodado com as mesmas coisas.
No vídeo de hoje quero fazer uma continuação. O problema original foi como uma Boa idéia que é o conceito de agilidade foi prostituído e transformado em um produto que consultorias e coaches vendem e cuja implementação em nada lembra os objetivos originais do Manifesto. Quando nós agilistas dizemos que Ágil está morto significa dizer que o que você consome hoje como Ágil provavelmente não é mais Ágil.
Eu venho pesquisando, aplicando e escrevendo a respeito do assunto geral de gerenciamento faz mais de 10 anos. Se você entrar no meu blog na url akitaonrails.com/management vai encontrar artigos e traduções que eu acumulei desde 2007 até pelo menos 2017. Recomendo dar uma olhada nesse material também.
À medida que os termos de agilidade se tornaram diluídos ao ponto de quase não reconhecermos mais, assim também aconteceu com outros conceitos do passado como o Lean da Toyota que hoje virou o irreconhecível Kanban ou Lean Startup. E agora outro conceito que vem sendo esticado além do que deveria que é o tal modelo do Spotify ou modelo de Squads. A idéia desses episódios não é dizer que agilidade, lean ou Squads não funcionam. Claro que funcionam, só que eu vou argumentar que quase todas as pessoas implementando esses modelos vão fracassar.
(...)
O que é o tal modelo do Spotify? Eu não vou explicar em detalhes, porque assim como Scrum ou Lean, você pode ir no Google e vai achar dúzias e dúzias de posts de blog, palestras e até eventos repetindo as estruturas como se não houvesse amanhã. Então vou resumir. Todo mundo a essa altura já conhece o conceito de equipes cross-funcionais, ou feature-teams, que no Spotify eles decidiram chamar de Squads. São como unidades de negócios numa organização em matriz, estrutura que se conhece desde os anos 80 por causa da Digital Equipment Corporation, ou DEC.
Teoricamente, um Squad é responsável por uma funcionalidade ou feature inteira, do design, programação até deployment. Por exemplo, um squad que lida só com a feature de playlist, ou outro só com a organização de álbuns. Você também pode ter dois ou mais squads que no fim acabam lidando com a mesma funcionalidade ou experiência do usuário, então esses squads se coordenam no que eles chamaram de tribes.
Cada squad é composto por profissionais de diferentes capacidades, então além do Product Owner ou PO, você pode ter um designer, quatro programadores, dois devops, um tester e assim por diante. Dois ou mais testers de múltiplos Squads formam outra organização horizontal chamada Chapters, por exemplo Chapters de devs front-end ou chapters de QA.
Por fim, você pode ter grupos com interesses similares mas não necessariamente do mesmo squad e nem do mesmo chapter, e pra isso eles se organizam em Guilds. Em termos de estrutura é só isso. Basicamente você chama departamentos de chapters, unidades de negócio de squads e tribes, e grupo do bebedouro ou cafezinho de guilds e boom, temos o modelo do Spotify.
Mais importante do que a estrutura são os princípios e aqui a coisa fica mais interessante. Nenhum dos pontos que o Spotify listou no seu modelo são novidades ou estão errados, são todos os mesmos pontos que qualquer um que já tenha lido The Mythical Man Month, Extreme Programming, The Pragmatic Programmer, Continuous Delivery do Martin Fowler, e mesmo os originais de Scrum do Ken Schwabber, ou Feature Driven Development do Jeff de Luca e Pete Code já ouviram falar várias vezes.
Quando o Spotify fala de Release Trains, Feature toggles ou feature flags, é tudo conceito de continuous delivery. Pra chegar ao nível de continuous delivery você precisa ter tudo que o Extreme Programming já ensinou: incluindo continuous integration.
Como eu disse no começo, o modelo Spotify não tem nenhum problema em si. Ele é meramente uma descrição do estado que supostamente, supostamente, estava a organização do Spotify por volta de 2012 a 2014 que foi quando eles soltaram o post de blog com o paper descrevendo o modelo e quando o Henrik Kniberg começou a palestrar e evangelizar o modelo em eventos de agilidade.
Eu fico pasmo vendo gente agora em 2019 vendendo explicitamente a implementação do tal "modelo Spotify" quando temos pessoas como o Marcin Floryan, diretor de engenharia do Spotify explicitamente explicando em palestra que Não existe um modelo Spotify. Vou deixar linkado a palestra dele do ano passado, onde ele mesmo diz que o que estava no paper de 2012 sequer descrevia corretamente como as coisas eram em 2012 e certamente já é diferente de como estava em 2018. Por isso eu disse “supostamente” agora a pouco. Ele fez questão de dizer: sabe porque chamamos as estruturas de Tribes ou Chapters? Porque ninguém estava usando esses termos antes! A idéia era criar um vocabulário próprio pra diferenciar dos outros. Por isso mesmo se você começa a copiar o modelo do Spotify pelo vocabulário, você já perdeu o ponto.
E sendo justo, se você pesquisar direito, no Google mesmo vai achar diversas pessoas, inclusive no Brasil, corretamente explicando porque o modelo do Spotify não é algo que você deva sair copiando. Exemplo disso é a palestra de Thiago Soares e Raphael Molesim chamado “3 razões porque o modelo do Spotify não serve pra você”, que vou deixar linkado os slides nas descrições abaixo. As explicações variam em qualidade e escopo, mas em princípio eles estão corretos. Por isso me deixa pasmo ainda ver empresas contratando coaches pra implementar esse elusivo pseudo-modelo.
E onde funciona o modelo do Spotify? Bom, se você for uma plataforma de música com milhões de usuários, em Stockholm, com várias pessoas que vieram da universidade KTH, em 2012, talvez esse modelo se encaixe. Ou seja, se você for o Spotify, então o modelo Spotify talvez faça sentido, por um período de tempo. Parem de comprar balas de prata! Balas de prata não existem! Qualquer empresa que compre um modelo como o do Spotify pra alguém implementar é só preguiçoso e não quer de fato entender como organizações funcionam. Parem de comprar implementação de modelos, seja de Spotify, seja de Lean, seja de Ágil ou qualquer variante.
Agora vem a parte difícil da minha explicação e eu vou ser o primeiro a dizer que eu mesmo tenho muita dificuldade de explicar isso. Se implementar modelos não funciona, o que a gente deve fazer?
Primeiro de tudo vocês precisam entender o que são modelos. Modelos são nada mais, nada menos, do que a descrição em forma de texto de uma observação em algum ambiente específico durante um período curto e finito de tempo. Por exemplo, eu poderia definir o modelo "Nature", natureza mesmo. Poderia falar que eu vejo como ecossistema nas savanas da África são eficientes e auto-sustentáveis, poderia dizer como os animais se organizam em Bandos ou, em inglês pra ficar mais marketável, vamos chamar de Herds. Então esqueçam Squads, vamos implementar Herds.
Posso dizer como a natureza foi sábia em fazer as leoas atacar os antilopes, zebras e gnus, então podemos implementar herds que se alimentam de outros herds, afinal é uma cadeia alimentar e isso faz sentido, o herd que ganha fica com o budget do herd que perdeu. O Herd Lead é o leão, claro. Mas outros herd leads podem clamar a posição e então eles podem se desafiar e quem matar o outro se torna o lead daquele herd. E assim eliminamos a necessidade de precisar fazer reuniões e stand ups pra discutir o assunto, basta um lead tomar a posição do outro. E como diz o nome da metodologia "Nature" é tudo naturalmente justificado e fácil de entender. Olha só que da hora, acabamos de inventar mais um modelo. Coaches, quero meus royalties se vocês implementarem!
Piadas à parte, agora vamos falar sério. O que está errado não é a configuração das estruturas de Squads ou Tribes do modelo descrito. O problema é que modelos são meras fotografias de um processo em constante mudança. Você não implementa modelos de gerenciamento de cima pra baixo e espera que tudo funcione. Por exemplo, eu sou uma instituição que por N motivos é gigante, uma instituição financeira, vamos dizer. Ao longo dos anos acumulamos 4000 funcionários. Só que a cada ano a entrega das coisas fica mais lenta e mais custosa. Enquanto isso essa nova onda de fintechs tá aí, atacando sem parar, sendo mais rápidos e mais eficientes. Precisamos evoluir!
E pra evoluir o que fazer? Oras, vamos ver os modelos que tem no mercado e reconfigurar todas as nossas equipes! Vamos desintegrar as unidades de negócios e departamentos que temos hoje, dividir todo mundo em equipes cross-funcionais, mudar fisicamente o lugar de todo mundo em Squads! Pronto! Agora vamos começar a entregar com velocidade de startup! Menos, bem menos ... Em qualquer implementação desses tipos de modelos, você sempre vai ver alguns resultados muito acima da média com alguns resultados medíocres ou bem abaixo do esperado. Você esconde os resultados ruins, reporta os bons pra diretoria e pro conselho e a vida segue.
O problema é o seguinte: em qualquer empresa, se você implementar qualquer modelo dessa forma, você vai sim ver algum resultado, especialmente se sua empresa era uma porcaria pra começo de conversa. Qualquer coisa é melhor do que nada num ambiente estagnado, você adiciona energia, joga um pouco de caos num lugar onde a entropia já começou a desintegrar a eficiência, e naturalmente vão emergir nichos de resultados até que bons. Isso acontece em qualquer lugar. Porém isso é um efeito colateral, não o efeito principal. Se for só isso que você fez, muito em breve a mudança vai se tornar o novo status quo, o nível de energia vai voltar ao normal, e a entropia volta a aumentar começando a deteriorar o novo modelo também. É inevitável.
Agora vem uma parte que eu pessoalmente gosto mas que é tão difícil de explicar que você vai ser obrigado a meio que engolir minha cagação de regra e depois buscar os detalhes. Como eu disse, eu escrevi bastante sobre isso no meu blog, tem vários artigos com mais detalhes. Mas você vai notar que no paper e palestras do povo do Spotify, bem como em material original de Scrum ou no próprio Manifesto de Desenvolvimento Ágil de Software, um termo que aparece bastante é Auto-organização e em alguns lugares aparece o tempo Complex adaptive systems, e com mais frequência mas sempre interpretado da maneira errada aparece a palavra Autonomia. Esqueça todas as estruturas, squads, chapters, sprints, scrums, kanbans, six sigma, e qualquer outra coisa. Enquanto você não entender o que é auto-organização, nada mais interessa.
Complex adaptive systems ou sistemas adaptativos complexos é um termo que vai aparecer em lugares tão diferentes quanto biologia, física, matemática. Se eu for explicar de maneira muito, muito grosseira, vamos pensar no seguinte: o que estamos tentando fazer é criar uma organização o mais eficiente possível. O que são organizações? São formas de organizar pessoas em torno de algum objetivo em comum. Ou mais corretamente, são formas que as pessoas se organizam pra atingir algum objetivo. Complexo não quer dizer difícil ou que você precisa de um phd pra entender. Pense num sistema como um grupo de agentes, onde cada agente tem possibilidades de se comunicar com outros agentes. Como já expliquei no vídeo sobre The Mythical Man Month, as linhas de comunicação aumentam muito rápido, de forma não-linear, com a inclusão de poucos agentes. Quanto mais agentes, mais complexas se tornam as linhas de comunicação. É muito difícil prever o comportamento desse sistema só observando o comportamento de um agente individualmente. A interação dessas linhas de comunicação criam redes dinâmicas complexas. Complex adaptive systems é um sub-grupo de uma área maior chamada Non Linear Dynamical Systems. A palavra chave é não-linear. Ou seja, se dobrarmos a quantidade de agentes, a complexidade não dobra, ela pode ser exponencial e aumentar ao quadrado ou mais.
Quando eu tento aprender uma coisa, mesmo em software, eu não procuro só na área de software. Obviamente outras áreas provavelmente já apanharam no assunto muito antes de nós, então eu tento estudar fora e ver o que já foi estudado. É claro que existem formas de organização diferentes de empresas. Todos nós vivemos já em alguma organização fora das empresas. Nossa família é uma organização, com hierarquia baseada na senioridade dos membros, onde teoricamente você devia respeitar sua mãe e seu avô, por exemplo. As famílias vivem em bairros ou comunidades, onde elas interagem e convivem umas com as outras, uns ajudando os outros ou fofocando sobre os outros pelos cantos, como todos gostam de fazer. Essas comunidades formam cidades, que se aglutinam em estados, que são unidos num grupo maior chamado país. E por último os países se organizam em blocos econômicos pra realizar comércio entre si.
Mas muito, muito antes disso, centenas de milhões de anos atrás, tivemos os primeiros seres monocelulares. Esses seres não tinham cérebro nem nenhum tipo de cognição, não tinham ambições de dominar o planeta ou mesmo consciência de que eles estavam em um lugar chamado planeta. Com os objetivos mais simples e imediatos como conseguir comida e reproduzir, eles foram se organizando e se aglutinando. Milhões de anos se passam e eles foram organismos multicelulares. Algumas dessas combinações dão errado e eles não sobrevivem no ambiente, alguns dão certo e eles conseguem reproduzir e criar mais cópias com características similares. Alguns desses grupos se separam do original e vagam pra mais longe, eventualmente alguns saem do mar e encontram terra. E agora temos grupos que vivem no mar e grupos que vivem na terra. Se você nunca leu a fascinante história da evolução recomendo que leiam livros como The Selfish Gene de Richard Dawkins.
Enfim, todo mundo aprendeu em biologia como literalmente do nada, por mero acaso e coincidência, uma combinação aleatória de fatores permitiu o surgimento das primeiras proteínas no ambiente precário da Terra do passado e com o passar dos milênios esses organismos foram se auto-organizando e evoluindo. Tentativa e erro atrás de tentativa e erro. Cada nova tentativa que deu certo deixando descendentes. E ao longo de centenas de milhões de anos saímos dos organismos monocelulares até chegar ao Homo Sapiens moderno e seja lá qual for a próxima evolução da nossa espécie. E antes que alguém comente, não, isso não é teoria que ainda não se tem certeza, já é um fato e uma lei. Nenhum ser divino fez um plano ultra detalhado e um belo dia disse "que se faça o ser humano" e boom, tudo apareceu como é hoje. É exatamente o que eu estou falando que também não funciona com implementação de modelos, um plano master que já nasce pronto e os divinos CEOs e COOs mandam implementar e você ganha um Spotify no dia seguinte. Aproveitando, se você nunca leu sobre o que é o método científico propriamente dito, recomendo que leia o clássico The Demon-Haunted World, Science as a Candle in the Dark do lendário Carl Sagan.
Eu brinquei falando da metodologia Nature antes mas foi uma meia brincadeira, porque foi exatamente assim que as coisas aconteceram e continuam a acontecer. O ecossistema natural, que compreende não só os grandes animais mamíferos que conseguimos ver mas até os micróbios e bactérias, todas existem num ambiente em equilíbrio dinâmico. Aliás, esse é outro conceito que vocês precisam entender: quando falamos em equilíbrio a maioria pensa em equilíbrio estático, que significa chegar num certo nível e não mexer em mais nada. Equilíbrio dinâmico é assim: nesta década nasceram pessoas demais, na década passada morreram pessoas demais, beleza, na média deu 0, estamos em equilíbrio, dinâmico. Nunca considere equilíbrio como sendo algo fixo ou estático mas sim sistemas que trocam energia entre si e na média estão em equilíbrio.
Essa história toda é pra encaixar alguns termos. Na sopa primordial do começo dos tempos na Terra tínhamos praticamente puro caos. Caos é basicamente desordem. Milhares de tipos diferentes de componentes químicos expostos numa terra em formação, ar irrespirável, trovões e raios. A parte interessante do Caos é que ao contrário do senso comum, a ordem tende a emergir do Caos. Da ordem surge entropia e entropia pode levar de volta ao caos. Por pura sorte, se você der tempo suficiente, milhões de anos, numa sopa de caos, é probabilisticamente inevitável que uma combinação de materiais químicos e energia vai acabar resultando em elementos como aminoácidos. E isso é o processo de evolução: seleção natural em mutações que surgem aleatoriamente. As mutações são aleatórias, a seleção natural não é, ela é cumulativa, por isso a evolução tende, no geral, a andar pra frente.
Agora entenda uma limitação da biologia: carregar a melhor combinação de genes acontece via reprodução. Dois animais precisam reproduzir pra gerar um filhote que carrega a combinação dos seus genes e talvez uma ou outra mutação acidental. É uma combinação de 2 pra 1 durante semanas ou meses. Idéias, ou o que Richard Dawkins cunhou como memes, tem a vantagem de ser N pra M em vez de só 2 pra 1, e não precisa de mais que alguns segundos pra reprodução de um novo meme. Fora que memes não precisam andar pra frente, ele pode fazer o equivalente a incesto e reproduzir com os pais, ou com os irmãos. Idéias podem ser misturadas pra qualquer direção. E a propagação de memes é muito mais rápida que a propagação de genes, por isso podemos fazer tentativas e erro muito mais rápido, criar mutações de memes e fazer seleção artificial dos melhores memes. O que no mundo biológico levaria centenas ou milhares de anos, no mundo da memética, das idéias, podemos executar em minutos ou horas. Organizações ou modelos de organização são idéias, memes, e eles podem e devem estar evoluindo constantemente. Nenhuma idéia é sagrada demais que não possa ser contestada e substituída.
Teoria do Caos é uma vertente da física, a maioria das pessoas vai reconhecer por causa do exemplo clichê da borboleta que bate as asas no Brasil causando um furacão no Texas. Ou os filmes do Efeito Borboleta como Ashton Kutcher, a idéia de que um pequeno evento causa efeitos em cascata imprevisíveis. E é isso mesmo: sistemas dinâmicos, que são altamente sensitivos a condições iniciais, embora aparentemente aleatórios, começam a demonstrar padrões emergentes, constante feedback loops - outro termo usado na palestra do Spotify - repetição, auto-similaridade, fractais e por fim, auto-organização.
Nós estamos acostumados a criar correlações entre causa e efeito de forma linear. É a descendência do pensamento determinista de René Descartes, melhor representado pelas equações da física de Isaac Newton. A física de Newton descreve um mundo determinístico, se eu souber a posição inicial, a velocidade inicial e a aceleração de alguma coisa, eu consigo saber onde no futuro esse alguma coisa vai estar com precisão. Consigo saber onde certo planeta vai estar, com precisão, daqui 50 anos. Se você parar pra pensar nisso, seu pensamento foi naturalmente treinado pra pensar em determinismo, previsibilidade, e praticamente a acreditar em destino.
Porém, o mundo real não é tão determinístico assim, especialmente depois da Teoria da Relatividade e Física Quântica. Aliás, aqui tome muito cuidado: você tem certeza que está vendo um charlatão quando ele aplica conceitos de física quântica no mundo macroscópico. Entanglement só existe no mundo sub-atômico, então esqueça essas teorias new age de consciência coletiva. Trabalhos como esse (What the bleep to we know) ou esse (The Secret) ou esse (Deepak Chopra) são todos bullshit de pseudo-quânticos e pseudo-ciência.
Agora, o comportamento de animais num ecossistema, o comportamento de seres humanos em mercados, o comportamento de particulas sub-atômicas, o comportamento da luz ao redor de um buraco negro, tudo isso não é trivialmente determinístico. E agora temos diferentes escolas com modelos pra entender essas coisas, em particular Teoria do Caos.
Existem alguns autores que eu vou recomendar que vocês leiam se tiverem interesse: Chaos, the new Science do James Gleick. Se você não sabia, o personagem Iam Malcolm de Jurassic Park foi inspirado em Gleick. Um autor extremamente importante pra entender sistemas não lineares e emergência é Steven Strogatz, começando pelo NonLinear Dynamics and Chaos. Daí Sync: How Order Emerges from Chaos in the Universe. Strogatz foi mestre de outro autor importante pra entender como as idéias de sistemas não lineares afetam relacionamentos em grupos, que descrevemos como networks ou redes, Duncan Watts que escreveu sobre o famoso Six Degrees: The Science of a Connected Age. Se você já ouviu falar sobre os seis graus de separação e porque isso acontece, recomendo ler Watts e outro autor importante: Albert Lazlo Barabási com seu excelente livro Linked. Finalmente pros mais inclinados a matemática provavelmente um dos nomes mais importantes na área que é Paul Erdös.
Agora, como tooodo esse mambo jambo de ciências se encaixa na nossao discussão de modelos de organizações? Simples, porque pra todos os efeitos, especialmente quando você tem um número grande de pessoas, você pode tentar usar os efeitos de emergência e auto-organização. Em teoria do caos, pense em caos quando você tem desordem entre um número grande de agentes. Agentes podem ser qualquer coisa, um micróbio, um animal, um ser humano, ou até mesmo um ser inanimado, nem precisa estar vivo.
Steven Strogatz tem um vídeo interessante sobre emergência, do TED Talk de 2004, uma época onde TED Talks ainda valiam alguma coisa. Eu gostava muito de mostrar em palestras que eu fiz até 2009. Nós tendemos a achar que sistemas tendem a aumentar sua entropia e isso leva inevitavelmente à desordem, a entropia no universo tende sempre a aumentar e por isso não é tão óbvio de entender que ordem pode emergir desse caos. Mas sem entrar em muitos detalhes sobre segunda lei da termodinâmica, entenda que o universo como um todo pode aumentar a entropia, mas a entropia em sub-sistemas menores pode decair e sua ordem pode aumentar à medida que trocamos entropia de um sistema pelo outro. Recomendo que procure sobre o demônio de Maxwell e a entropia de Shannon, de Claude Shannon que escreveu sobre Teoria da Informação.
(starlings)
De qualquer maneira, entenda que no mundo real, coisas tendem a demonstrar comportamento de sincronização e ordem tende a emergir desses sistemas. O mambo jambo todo anterior é meio pra dizer que sim: sabemos que esse tipo de comportamento realmente acontece naturalmente. E como eu disse, você sequer precisa de seres vivos pra obter esse comportamento. Veja este exemplo de Strogatz.
(metronomes)
De tudo que já li a respeito, resumindo de forma bem simplória, temos organizações da era da Teoria X, onde assumimos que as pessoas que contratamos simplesmente nunca vão ter vontade de realizar nenhum trabalho, então criamos estruturas de microgerenciamento, pra garantir que cada engrenagem da máquina esteja funcionando como deveria. Seja numa empresa com 10 pessoas ou com 10 mil pessoas, colocamos todo mundo em pequenas caixas altamente reguladas e limitadas, com o mínimo possível de liberdade. É um sistema de baixa entropia, porém é um sistema com baixas chances de ordem emergente, pelo contrário é a que tende a entrar em decadência mais rápido e exige quantidades maiores de energia entrando nesse sistema para manter a baixa entropia. Por isso custa caro, precisamos de grandes hierarquias, enormes quantidades de regras e procedimentos, pra manter o sistema em ordem.
Na teoria Y as premissas são diferentes. A palestra do Spotify de Marcian cita leituras como o livro Drive de Daniel Pink. Por acaso outro autor que eu citei como se não houvesse amanhã lá por 2008 e que fala sobre motivação, não era mais pra ser nenhuma novidade hoje. O conceito é simples mas não deve ser confundido com o que se fazia nos anos 90 onde começaram movimentos motivacionais, o famoso vamos juntar todo mundo da empresa pra se conhecer numa chácara, e fazer todo mundo se importar uns com os outros, todo mundo abraçar árvore e mimimi. Esse conceito até eu já considero bem antiquado.
A hipótese de Daniel é que empresas, chefes, não tem como motivar as pessoas. É impossível. As pessoas motivam elas mesmas. Segundo Daniel, o que as pessoas procuram é Autonomia, Mastery que eu não sei como traduzir em português mas seria a vontade de ser melhor no que faz, e Propósito. E daí você vê de novo a palavra Autonomia que aparece no paper do Spotify e inúmeras outras metodologias.
Na teoria de emergência de Strogatz existe outro insight que eu considero importante. Vemos no vídeo aquele bando enorme de pássaros todos voando em sincronia, formando uma coreografia no ar, e conseguindo desviar de predadores e rapidamente avisar os pássaros que estão dezenas de metros mais à frente através da propagação de ondas, que é uma maneira de propagar informação de forma eficiente pra frente. Entao os pássaros vão desviando dos ataques e rapidamente retornam à formação próximo um dos outros. O bando inteiro, olhado de longe, parece um grande organismo.
É a propriedade de auto-similaridade e fractal do comportamento emergente de sistemas complexos adaptativos. O mesmo comportamento pode ser observado no nível microscópico como células ou no nível macroscópico como bando de pássaros ou peixes. E ao contrário da nossa tendência antropomórfica de imaginar que os pássaros de alguma forma se importam uns com os outros e por isso andam em bando, não, não existe essa correlação. No exemplo da simulação de computador, basta termos agentes completamente egoístas, que tendem a voar perto dos demais, desviar de outros agentes tentando voar por cima deles, e tentar retornar pra perto do bando quando puder.
Por que eles voam em bando? Por que aumenta as chances individuais de sobrevivência de cada indivíduo. O predador vai acabar pegando alguns, mas se você tentar voar sozinho separado do bando, você é o alvo fácil. Portanto pra ter comportamento emergente de grupo, trabalhando em sincronia, sequer existe a necessidade de alguma causa em comum. Basta que cada agente do grupo tenha liberdade de reagir em favor de seu próprio interesse individual e encontrar valor em preservar sua estadia no grupo pra atingir esses objetivos.
Como eu disse, eu poderia ficar semanas esmiuçando todas as vertentes de teoria do caos de maxwell, mandelbrot, lorenz, começar a chegar na física termodinâmica, explorar todas as derivações da segunda lei da termodinâmica, entropia, conservação e transferência de energia, teoria da informação, até esbarrar na teoria quântica com von neumann. E mesmo depois de tudo isso, a aplicação em teoria das organizações continua sendo mais especulativa do que uma aplicação consistente. A idéia não é dizer pra começar a fazer equações físicas pra descrever organizações, mas já que todo mundo fica roubando vocabulário da física e biologia eu resolvi mostrar de onde vem essas palavras que todo mundo usa sem saber do que se trata.
A maioria dos trabalhos de organizações, por alguma razão, tende a convergir pra essas vertentes de estudo. Mas, isso só vai ser útil se você é nerd como eu e gosta de tentar entender os mecanismos das coisas. Mas com tudo isso dito o que eu concluo é o seguinte. Comece pensando no indivíduo. Evite pensar em grupos ou comunidades. Todo mundo gosta de ser politicamente correto pseudo-socialista pró-causas sociais e bla bla bla. Tudo isso é bonito, é marketável, mas falando friamente em organizações, elas são irrelevantes.
O erro é tentar formar grupos de cima pra baixo, é mais fácil dar a direção e deixar os grupos se formarem sozinhos, emergirem a partir das vontades individuais de cada agente no sistema. Você tem duas maneiras de obter ordem nesse tipo de sistema. Um deles é de alto gasto de energia, que é via microgerenciamento. Você precisa tornar as coisas difíceis pra todo mundo, gastar muita energia pra conseguir fazer alguma coisa, e assim você obtém o maior grau de ordem, porém com o menor grau de mobilidade. Você estabelece um microestado e cada agente vai ficar preso no mesmo lugar, o sistema fica estático e tende a se linearizar.
Você pode ir pelo caminho do mínimo esforço, que seria literalmente apostar no caos e esperar a ordem emergir naturalmente. Porém a probabilidade de você chegar num microestado dentre milhões de combinações aleatórias diferentes em tempo hábil tende a zero. Ou seja, simples anarquia não vai te levar a um lugar algum, a menos que você seja muito sortudo. E nem vou dizer que isso não acontece.
Por fim, só existe uma outra solução: trabalhar no limite do caos, o Edge of Chaos em Teoria do Caos. E aqui vou ter que ser nerd de novo. Em termos simples pensa em transições de fase. Da água líquida pra cubo de gelo, é uma transição de fase de um estado de maior desordem pra um estado de menor desordem. Quando pesquisadores começaram a explorar esse limite entre as fases começamos a falar sobre adaptação.
Adaptação no limite do caos se refere à ideia de sistemas complexos adaptativos de intuitivamente evoluir a um regime próximo às fronteiras entre caos e ordem. Muitos começaram a discutir alguns anos atrás sobre aprendizado no limite do caos. E eu não lembro onde li que tentava demonstrar que uma organização de aprendizado é justamente uma organização que consegue andar na linha bamba próximo ao limite do caos. Na realidade, variando de forma controlada entre momentos de ordem e momentos de caos.
Se de novo isso parece um pouco familiar com o comportamento de um modelo circular ou iterativo, não é mera coincidência. Pode ser uma das razões de porque modelos circulares parecem funcionar tão bem, e justamente porque quando você trabalha sobre muita coisa desconhecida, ir e voltar do limite do caos aumenta sua probabilidade de resolver o problema e aprender alguma coisa.
A vantagem desse tipo de organização é que ela teoricamente gasta menos energia pra manter com o trade-off de causar erros e desperdícios. E ao contrário de uma anarquia, ela maximiza a probabilidade de se chegar num estado de entropia que forneça máxima eficiência mais rápido. A forma de fazer isso é abrir mão do micro-controle. Você nunca, mas nunca, deve confiar cegamente nas pessoas. Porém você não deve controlá-las tão de perto. Você precisa ter mecanismos de auto-preservação no ambiente. De preferência deve fazer parte do interesse de cada agente nesse sistema trabalhar somente do lado de outros bons agentes, assim como no bando de pássaros, não pelo bem da empresa ou qualquer outra causa, mas pelo seu próprio bem, porque não faz bem pra reputação dele estar num grupo de gente ruim, por exemplo.
Finalmente chegando na parte importante, o que o paper do Spotify faz corretamente é falar sobre alinhamento e autonomia. Alinhamento é outro termo vago, mas é basicamente dar direção ao barco. Se os C-level da empresa não sabem pra onde o barco deve ir, fodeu, pra todo mundo. Mas partindo do princípio que a direção está clara, você pode dar a autonomia aos funcionários pra atingir esses objetivos da forma como quiserem. Mas não de qualquer jeito, direção exige regras claras. Não se trata de criar organizações democráticas ou holocracias.
Na prática, nenhum funcionário jamais deve ter autonomia completa numa empresa, por exemplo via voto da maioria. Uma empresa não é e nunca deve ser uma democracia, que é basicamente a máfia da maioria. E a explicação é simples: qualquer pessoa que continua ganhando a mesma coisa todo mês, independente se fez tudo certo ou tudo errado, não pode ter autonomia completa. Somente os sócios majoritários podem ter essa autonomia porque se tudo der errado, quem vai sofrer os ônus do prejuízo vão ser eles. Os funcionários ganham se forem mandado embora, inclusive. Por isso você como funcionário, nunca deve se sentir mal de não poder decidir o gasto do orçamento da empresa, não é da sua responsabilidade. Se quiser que seja, assuma o prejuízo e torne-se sócio. Por esse simples fato, democracias puras não tem como funcionar no ambiente privado. Pra assuntos mais relevantes como por exemplo, quais ferramentas de trabalho vão usar, quem vai fazer parte de qual equipe, ou seja, tudo que tem a ver diretamente com a competência para os quais os funcionários foram contratados, então sim, eles podem e devem ter autonomia.
E só essa autonomia já é suficiente se você não contratou um bando de idiotas. Essa é outra coisa que pouco se fala: um modelo de auto-organização só acontece com bons agentes no sistema, agentes que não se sabotam e atiram no próprio pé sem perceber. Novamente, definir o que são boas pessoas é complicado. A maioria das pessoas de recursos humanos é incompetente em reconhecer boas pessoas, porque elas procuram ou por quantidade de capacitações e experiência ou personalidade das pessoas, se elas parecem boazinhas ou simpáticas. E nenhuma das duas coisas está correto, boas pessoas são aquelas que procuram Mastery.
Se você assistiu meus videos neste canal, já deve ter ficado muito claro que eu estou tentando falar com um tipo muito específico de profissional, e não com todos: os que programam ou estudam programação porque gostam de programar. Não importa se vai trabalhar num produto unicórnio ou num legado de repartição pública. Não importa se vai ganhar 4 dígitos ou 6 dígitos de salário por mês. Claro, todo mundo gosta de reconhecimento, mas não é esse o drive mas sim o mastery, e por causa disso também não gostam de trabalhar com pessoas medíocres do lado deles, e não gosta de coisas mal feitas dos outros e, se puder, vai ajudar os demais ao redor espalhando conhecimento, ou se isso não der certo, vai expurgar os maus elementos. Mastery. O problema é que somente pessoas que são assim conseguem enxergar outras pessoas que são assim. Como diria Jobs: pessoas A contratam outras pessoas A, pessoas B sempre contratam C. E recursos humanos, desculpem, nesse quesito vocês são C contratando D, deixe esse trabalho pros A.
Partindo da premissa que você contratou gente A, e partindo da premissa que você tem direção bem definida, naturalmente uma organização que se parece com Squads, Tribes e Chapters vai emergir. E aqui parece um pouco mágica, mas é basicamente isso: dê a pessoas A, um ambiente A, e naturalmente uma auto-organização A vai emergir. E dar um ambiente A não significa piscina de bolinhas ou xbox na sala comum. Ambiente A significa um ambiente estável e simples, onde salários não atrasam, onde reuniões sem sentido não aparecem aleatoriamente, onde a direção não muda toda hora obrigando o trabalho a recomeçar o tempo todo, onde a comunicação é liberada e não precisa de formalidades, nem rituais, nem reuniões especiais, onde feedbacks podem ser repassados o tempo todo pra cima ou pra baixo, novamente, sem formalidade de avaliações 360 ou qualquer bullshit assim, ou seja, onde adultos podem trabalhar como adultos sem babás tentando trocar as fraudas deles toda hora.
Outra coisa é quando falamos de transparência, que é outra coisa importante. Transparência não é terapia de casal pra ficar expondo tudo. Informação inútil demais também não ajuda ninguém. No caso de programadores, todo programador deveria ter acesso a todo o código da empresa. Todo devops precisa ter acesso a toda a infraestrutura da empresa. Todos os designers precisam ter acesso a todo o roadmap de produtos da empresa. Porém, coisas como abrir faturamento, lucro, dívidas, conversas com investidor e todas essas coisas, é bonitinho mas é inútil pra maioria das pessoas. De novo, uma empresa não é nem deve ser uma democracia. Novamente, se você é sócio da empresa sim, deveria ter que ler essas chatices. Se você não é, então não faz diferença. Por muitos anos eu pensei o contrário, mas de fato nunca achei nenhum bom argumento pra justificar. Empresas privadas Não são órgãos públicos ou ONGs.
Todo o resto que você já viu sobre esse modelo está melhor descrito em todos os materiais que eu já repeti mil vezes como extreme programming. Por exemplo, continuous delivery. O código no master do repositório deveria estar sempre pronto pra deploy em produção. Pra isso nenhum desenvolvedor deveria subir código incompleto ou que crasheia o sistema. Pra isso todo desenvolvedor deveria desenvolver num branch, ou pull request no caso do GitHub, e só quando o código estiver completo, com testes automatizados, que passam pelo sistema de integração contínua, só aí ele deveria ser mergeado na master e somente quando pelo menos um colega de equipe revisar. É uma coisa meio básica, bem arroz com feijão mesmo, mas incrivelmente poucas empresas fazem isso.
Outra coisa é releases frequentes, porque se demorar demais pra lançar em produção começa a acumular muito código que nunca foi testado de verdade por gente de verdade, e quanto mais demorar maiores as chances desse deploy falhar. E quanto mais aumenta essas chances mais todo mundo prefere protelar pra fazer deploy e vira um ciclo vicioso. É melhor fazer deploys constantes, com bastante frequência. Assim, mesmo se tiver um bug, é mais fácil de reverter e consertar do que lançar uma tonelada de código novo de uma só vez e depois virar um pesadelo pra saber o que exatamente quebrou aonde. E é isso que nas palestras do Spotify o CEO fala que eles falham rápido toda hora. Fail Fast é um conceito que ficou famoso no Lean Startup, novamente nenhuma novidade.
Mas claro, ser assim o tempo todo é uma utopia, e nem no Spotify é assim. Nessa entrevista de 2018 com Joakim Sundén, que é "coach" de equipes e liderança no Spotify ele mesmo diz: Não me entenda mal: amo o Spotify, a nossa cultura e forma de trabalhar, mas está longe de ser um "Nirvana Ágil". Aliás, uma coisa que sempre surpreende aqueles que tem uma vasta experiência com o Ágil é que as práticas de engenharia como TDD, programação em par, código limpo e design simples não são tão comuns por aqui. Squads que usam estas práticas geralmente são exceção, e não a regra. Na verdade, muitos squads não estão habituados nem com as práticas ágeis em geral. Talvez até fazem reuniões de planejamento, mas não necessariamente revisam o plano ou refletem sobre como melhorá-lo. As equipes que usam kanban raramente usam a limitação de trabalho em progresso, ou se usam, frequentemente a ignoram. Não estou dizendo que esta seja a realidade de todos as equipes, mesmo porque tendo na organização cerca de 150 equipes, não teria como saber detalhes de cada um. Estas observações vêm do trabalho feito com dezenas de equipes ao longo de seis anos, além de conversas com muitos outros coaches e Spotifiers.
E aqui vem uma coisa que eu digo faz anos: nenhuma metodologia vai salvar pessoas ruins. Se você já sabe que a maioria dos seus funcionários não é boa, não tem essa vibe de mastery e está lá mais porque não tem outro lugar pra ir e ninguém contrataria eles, então esqueça metodologias. Scrum, Lean, Kanban, Spotify, nenhum modelo vai jamais salvar profissionais ruins ou mal caráters. Aliás, pouca experiência técnica é algo que sempre podemos evoluir, mas mal caratismo não tem cura. Eu digo que se nem a coitada da mãe dele conseguiu dobrar o mal caratismo do filho por toda a vida dele, não sou em que em um mês vou conseguir. Portanto quando alguém se mostra mal caráter corte imediatamente, não tem salvação. Nunca, jamais, mantenha alguém mal caráter na equipe mesmo que ele pareça ser o melhor técnico. A pior coisa que uma empresa novata pode fazer é acumular escória assim.
Pra concluir. Esqueça metodologias ágeis, lean, kanban, spotify ou qualquer outra coisa. Na verdade, esqueça quem vende essas coisas. Se quem vende essas coisas não começou com a questão de tirar do cargo de chefia quem emperra decisões ou demitir os mal caraters que ainda estão no cabideiro da empresa, já começou errado. A primeira coisa que qualquer empresa que quer implementar esse tipo de processo precisa fazer é cortar a gordura fora e começar com o essencial: evitar desperdícios. O diretor de marketing que está lá só porque é cunhado do CEO, e todo mundo sabe que só fala besteira e não entrega nada? Precisa ir embora. O tal líder técnico que diz que manja bastante mas os programadores juniors que varam noite consertando os bugs que ele comitou direto na master, e que só aparece pra trabalhar 2 horas da tarde? Esse precisa ir embora. O gerente de projetos que sempre promete A pro diretor, manda a equipe fazer B, e depois muda de idéia pra C no meio do projeto mas mantém o prazo igual porque não quer contar pro diretor que fez merda? Esse precisa ir embora.
Eu não acredito em nenhuma tentativa de se implementar um novo modelo de gestão que não inicia com uma limpeza de RH. De departamentos inteiros se possível. Depois disso é ver toda a burocracia que se tem hoje em dia e jogar tudo fora se possível. Eu já vi casos imbecis de empresa com sprints de Scrum de 3 semanas ou mais! 3 semanas é ridículo. Uma semana é o ideal, na minha opinião. E quando você vai perguntar porque é tão longo eles falam que as reuniões de grooming, planning, review e retrospectiva acabam levando tantos dias que não cabe em 1 semana. Ou seja, estão desperdiçando o tempo da equipe toda em reunião 1 semana inteira por mês.
E isso tudo porque alguém leu que se deveria ouvir a opinião de todos os membros da equipe toda hora, que é uma desculpa pro PO e pro líder técnico não fazerem os trabalhos deles que é definir exatamente o que se precisa fazer e daí só discutir com a equipe toda quem vai fazer o que e como, o que deveria ser super rápido. É de novo a falta de alinhamento. Ninguém sabe exatamente que direção precisa ir, e na última hora durante o planning tem que ficar especulando cenários, começar a fazer pra alguém decidir diferente no meio e aí ter que parar tudo e recomeçar. Daí claro, 3 semanas de sprint, 6 semanas de sprint, não importa, você nunca vai ser ágil. Porque dessa forma toda vez você começa um sprint de 3 semanas, as coisas dão errado e só nas 3 semanas seguinte dá pra corrigir e potencialmente você atrasa as coisas 1 mês e meio toda vez, e isso vai acumulando. Daí seus deploys são atrelados ao aceite total no final de 2 ou 3 sprints, e você só tem coisa indo pra produção a cada 2 ou 3 meses. E, lógico, bugs vão se acumulando, todo deploy é uma dor de cabeça, daí na sequência todo mundo vara noite resolvendo bug e o próximo sprint já começa com burn out.
Isso porque a prioridade tá errada: você precisa criar restrições pro processo e fazer caber. O sprint é 1 semana. Mas daí não cabe as reuniões, oras, elimine as reuniões. Mas metade do backlog tá mal definido e não dá pra começar, oras corte fora do backlog tudo que tá mal definido. Ah, mas foi o diretor que pediu, oras, devolva pro diretor definir o que quer direito e escolher uma das opções, porque todas não dá pra fazer. É assim que se começa a tomar decisões. Se isso não é possível, então não adianta escolher metodologias, a fundação da empresa tá errada. Começa se livrando desse diretor e metade dos problemas vão embora com ele. Squads não vão ajudar.
É como o caso de microserviços que eu gosto de comentar como sintoma de más empresas. A Lei de Conway é outra lei das antigas que até hoje todo mundo cai nela. Melvin Conway postulou que qualquer organização que desenvolve sistemas vai inevitavelmente produzir um design que reflete a estrutura de comunicação da organização. Microserviços ficaram famosos porque ela aparentemente resolve um problema em organizações: a inabilidade de duas equipes de colaborarem entre si. Qual a melhor solução? Cada um cria seu próprio microserviço e eles não precisam colaborar agora. Uma organização com 10 equipes cria 10 ou mais microserviços. Claro, existem usos legítimos de microserviços, mas é muito mais comum ver eles sendo usados como tapa buraco em problemas de organização.
Toda implementação de bala de prata é alguém incompetente querendo esconder sua incapacidade atrás da muleta de uma metodologia. Daí quando tudo der errado você sempre pode dizer, ah mas a culpa não foi minha, nós seguimos todos os passos da metodologia, então outra pessoa deve ter implementado um passo errado. E pronto, todo mundo vai ficar discutindo ad eternum sobre especificidades de uma metodologia genérica. E ninguém vai ter o culhão de discutir o elefante no meio da sala: foda-se a metodologia. Qual é o real problema? É a quantidade de bugs em todo release? É a demora em se fazer deploys? É a quantidade de mudanças frequentes no backlog a cada sprint? Defina o problema objetivamente e ataque um de cada vez. Se fizer dessa forma, um modelo de organização naturalmente vai emergir.
Mas comece eliminando desperdícios. E contratar coaches é um desperdício. Se você como diretor ou C-level não fez merda demais, você já deveria ter tech leads ou similares na empresa que sabem o que precisa ser feito, mas não podem porque você enterrou todos eles em burocracia ou em backlogs impossíveis e estão todos varando noite correndo atrás do próprio rabo. A coisa mais óbvia? Desatole eles, assuma o prejuízo de fazer isso do que jogar dinheiro fora numa consultoria de agilidade que, se eles fizessem o trabalho deles direito, deveria te dizer pra fazer exatamente isso: desatole seus líderes e deixe eles fazerem o que eles já sabem que precisa ser feito.
Por fim, o próprio Spotify vem repetindo ao longo dos anos que nem eles seguem o modelo que eles mencionaram em 2012. E nem deveriam. Porque qualquer organização que esteja seriamente pensando à frente em sua qualidade e eficiência, está mudando as coisas o tempo todo. Um modelo, assim como a tal “Cultura”, que tooooodo mundo adora ficar falando em palestra ou post de blog é nada mais do que uma fotografia num determinado momento. Toda cultura muda, cultura é simplesmente o conjunto de costumes e valores de um grupo num determinado local e num determinado momento no tempo. Em 2019 a maioria das pessoas que trabalhava em 2012 talvez nem esteja mais lá, a cultura com 100 pessoas e com 2000 pessoas é diferente. Não se pode nunca achar que cultura é algo que vai ser preservado ou mesmo que deve ser preservado. Pelo contrário, é algo que deve estar em constante mudança, por isso eu acho meio idiota quando uma pessoa quer entrar numa empresa pela “cultura” que ela leu num post de blog.
Em Lean se popularizou um conceito que é melhoria contínua. É a única coisa importante depois de evitar desperdícios, Kaizen. Incentivar as pessoas a errarem rápido, aprender com os erros, ensinar os outros, e não errar a mesma coisa na próxima vez. É meio óbvio, mas parece que tudo que é óbvio precisa ser explicitamente dito numa organização. E esquece Kanban, foda-se OKR e rhythms e dibbs, que porra é dibbs? Fuck. Se quiser saber sobre Lean de verdade só tem uma fonte pra ler: Taiichi Ohno e seus discípulos como Shigeo Shingo. Na verdade, quem vende Kanban hoje já até avisa que o Kanban de software não tem mais nenhum paralelo com o Kanban da Toyota. É mais uma apropriação de vocabulários pra vender os mesmos produtos de sempre.
Como eu já disse no vídeo de Ágil: esqueça metodologias. O objetivo é entregar valor, software que funciona. O objetivo é maximizar os lucros. O objetivo é que todos trabalhem num ambiente minimamente funcional, com salários pagos em dia, com poucas interrupções, onde feedback não precise de burocracias e comunicação seja livre e aberta, onde cada profissional possa executar seu trabalho no máximo das suas capacidades, em vez de ter que se conformar com um padrão de ferramentas ou plataformas ou processos. Onde exista incentivo para que as pessoas vejam que existem ganhos individuais quando ele contribui com as outras pessoas, seja direta ou indiretamente. Use a ambição do indivíduo em prol da organização em vez de tentar convencer as pessoas a participar de um grupo só porque é politicamente correto colaborar com os outros. E, principalmente: demita esse maldito CMO ou C-FUCK-O ou VP de sei lá o que, que só atrapalha, só toma decisões erradas e só fica inventando de implementar o próximo Squad da moda.
Não menos importante, na dúvida sempre se lembre: um scrum master, um agile coach, um arquiteto, um chapter lead, ou qualquer coisa assim que vêm cagar regra em programação e nunca ele mesmo programa e não consegue se expressar em código pra explicar o que quer, não tem lugar numa equipe de desenvolvimento de software. E pra finalizar, tudo que falamos até agora não é novidade pra quem leu o Manifesto de Desenvolvimento de Software Ágil de 2001. Ele tem os famosos 4 valores, mas também tem 12 princípios, lembra? Vamos alguns deles e você vai ver como tudo que aparece no modelo Spotify e outras metodologias vem de lá também.
Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. - olha squads aqui Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. - voltando ao ponto de autonomia e alinhamento O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara. - ou seja, sem rituais, simplesmente fale Software funcional é a medida primária de progresso. - esse é o objetivo: software que funciona e não estruturas de controle Contínua atenção à excelência técnica e bom design, aumenta a agilidade. - que é o pré-requisito a profissionais A Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. - e o que eu sempre repito que o melhor software é zero software. Se não precisa ser feito, não faça. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis. - e o manifesto também trás auto-organização Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo. - e aqui é o manifesto remetendo ao princípio de melhoria contínua de Lean
Eu não vi nada de novo surgindo no mundo de teorias de gerenciamento faz mais de 10 anos já. É tudo a mesma coisa que a gente já sabia até o fim do século XX. Em vez de olhar pra esse tanto de bullshit quero que pensem outra coisa. Vejam software livre, código aberto. Você que é uma empresa de desenvolvimento de software, tentando implementar squads e scrums, nunca se sentiu meio envergonhado que um grupo aleatório de voluntários, que sequer ganham salário, consegue se juntar num projeto e entregar código de melhor qualidade do que seus squads com 10 coaches? Quando você se vê conseguindo entregar um framework como React? Quando você se vê entregando um banco de dados como Redis? Quando você se vê entregando um sistema como Git? Você está criando uma tonelada de estruturas inúteis de controle e sequer consegue entregar um formulário de login sem erro. Não tá muito claro que as prioridades estão erradas?
O mundo de software livre funciona porque ele tem só o mínimo necessário pra funcionar. O voluntário consegue baixar o código, rodar os testes e avaliar como prosseguir. Os bugs e roadmap estão expostos de forma transparente no issue tracker e wiki do projeto. Os membros estão disponíveis em mailing list ou chats. Existe um indivíduo ou grupo que é o ditador benevolente do projeto que é quem garante a integridade conceitual - como Fred Brooks já disse que era necessário no The Mythical Man Month. Discussões longas que se arrastam são cortadas por alguém que toma uma decisão. Boa ou ruim, ela é tomada. A principal métrica do projeto é sua utilidade aos usuários, caso contrário o projeto simplesmente morre. Como deveria.
E com isso eu vou fechar o assunto sobre agilidade por algum tempo. Acho que já falei tudo que eu queria falar. Prometo não voltar nesse assunto tão cedo porque quero falar de outras coisas mais interessantes: software. Então se ficaram com dúvidas, nao deixe de mandar nos comentários abaixo, se curtiram o video mandem um joinha, assinem o canal e cliquem no sininho pra não perder os próximos videos. Compartilhem o video com seus amigos pra ajudar o canal. A gente se vê semana que vem, até mais!