Capítulo 3 - Equipes
Todo mundo sabe disso, mas, no mundo dos negócios, é comum que a gente acabe se concentrando unicamente em indivíduos, mesmo que a produção seja um esforço coletivo. Pense em bônus por desempenho ou promoções ou em contratações: o foco está sempre em atores individuais, em vez de na equipe. E isso acaba sendo um grande erro. [p.21]
E, quando você examina como essas equipes se saíram, se depara com algo surpreendente. Se a melhor equipe conseguia realizar uma tarefa em uma semana, quanto tempo você acha que a pior equipe levou? Talvez você chute a mesma razão observada em Yale — 10:1 (ou seja, a equipe mais lenta levou mais de dois meses para conseguir o que a equipe mais rápida realizou em uma semana). A resposta verdadeira, porém, é que há uma diferença muito maior no desempenho coletivo do que no desempenho individual. Na verdade, a pior equipe não levou dez semanas para fazer o que a melhor fez em uma semana: ela levou duas mil semanas para fazer o mesmo trabalho. Essa é a grande diferença entre o melhor e o pior. Então, onde você deve concentrar a sua atenção? No nível do indivíduo, onde talvez consiga obter uma melhora de dez vezes, se conseguir transformar, em um passe de mágica, todos os seus funcionários em gênios? [ibid]
Aqui é um item interessante para todos nós como equipe. E esse é um dos trabalhos que vamos fazer se utilizando de um aforismo de Marco Aurélio: “O que não é bom pra colméia não é bom pra abelha”.
Dentro do plano de habilidades da TI estará a integração do time. Ideias? 💡
O trabalho de J. J. era ajudar a equipe a fazer o melhor trabalho que poderiam. Não era mandar as pessoas fazerem as coisas, mas dar aquilo de que precisavam. As ordens da gerência eram contar o fato e entrar no ar várias vezes ao dia, e a equipe no local descobriu como fazer para superar aquele desafio, decidindo quais histórias contar e como conta-lás, usando o rádio como mídia. [p.24]
Essa é a essência do trabalho da gerência. Isso é o que torna as equipes coesas. A principal função do gerente é oferecer os recursos necessários.
Da forma mais verdadeira possível, eles estavam sozinhos. Com a impossibilidade de receberem uma supervisão direta e constante de Washington, e os eventos acontecerem tão rápido, a equipe teve de se organizar. Um dos conceitos-chave do Scrum é que os membros da equipe decidem, eles mesmos, como irão executar o trabalho. A responsabilidade da direção da empresa é estabelecer os objetivos estratégicos, e o trabalho da equipe é decidir como atingi-los. No Cairo, não havia como alguém que não estivesse lá, no território, acompanhar o que estava acontecendo. Quase todos os dias, a equipe da NPR relatava uma série de histórias para o dia seguinte que se tornariam instantaneamente obsoletas devido à velocidade do desdobramento dos eventos. Aconteceria um confronto grande na praça, um discurso ou uma batalha, e todo o trabalho da equipe teria sido em vão. De repente, eles estavam lutando para conseguir colocar no ar alguma notícia importante em tempo hábil. [ibid]
A cada ciclo, J. J. conversava com a equipe e fazia três perguntas simples: “o que você fez desde a última vez que conversamos?”; “O que você vai fazer antes de voltarmos a conversar?”; “O que está atrapalhando o seu trabalho?”. O fato de ele fazer essas três perguntas, que é um dos rituais regulares do Scrum, forçava os correspondentes a falarem e a dividirem informações uns com os outros. [ibid]
A Comissão Rogers que examinou o desastre da Challenger em 1986 concordou. Nas famosas palavras escritas pelo físico Richard Feynman no apêndice F do relatório da Comissão: “Parece que, seja qual for o objetivo, seja para consumo interno ou externo, o gerenciamento da NASA exagera a confiabilidade de seus produtos chegando ao ponto da fantasia” [p.25]
Nicola Dourambeis é responsável pelas práticas “ágeis” na Salesforce.com. O que Dourambeis busca nas equipes é a diversidade — de conjunto de habilidade, pensamento e experiência. Ela quer equipes que sejam altruístas e autônomas, mas também precisa que sejam interfuncionais. Equipes que consigam fazer com que o projeto inteiro seja concluído. [ibid]
Eu sempre acreditei que as pessoas precisam estar onde elas querem estar. Ninguém é igual a ninguém e isso por si só já garante a questão da diversidade em termos de habilidades.
Então, em 2007, o general David Petraeus liderou a operação que ficou conhecida como “Surge” [Tempestade], que consistia em colocar dezenas de milhares de tropas adicionais no país e deixá-los viver entre a população local. Essa nova estratégia teve um resultado extraordinário. Um dos motivos foi que o povo iraquiano passou a acreditar que os americanos estavam realmente do lado deles, lutando contra os rebeldes que estavam explodindo bombas nas vizinhanças e fazendo uma limpeza étnica. Outro motivo foi o fato de os militares americanos conseguirem convencer inúmeros antigos rebeldes a passar para o lado dos Estados Unidos, em um programa chamado “Sons of Iraq” [Filhos do Iraque]. Mas havia um terceiro componente estratégico, que usava algo que o jornalista Bob Woodward considerou tão revolucionário quanto a invenção do tanque de guerra ou do avião. [p. 26]
Aqueles que estavam usando esse modelo de transferência descobriram o que Fujitsu descobrira décadas antes, quando tentaram implementar o sistema de fase/ponto de decisão usado pela NASA, e um dos motivos do desenvolvimento do Scrum: sempre que há transferências entre equipes, existe a possibilidade de desastre. [ibid]
No meio da guerra utilizar uma estratégia que não funciona significa a derrota
Os gestores não costumam querer que outros gestores, suas próprias equipes ou outras pessoas na estrutura organizacional de poder saibam exatamente o que estão fazendo ou o que conseguem fazer e em quanto tempo. Eles acham que manter tal conhecimento em segredo é essencial para seu poder. Em vez de se alinharem com o interesse do bem maior, eles o fazem de acordo com as próprias motivações, que, de forma geral, se resumem a ganância e ambição. Foi exatamente esse tipo de pensamento que levou ao enorme fracasso gerencial que resultou no mais recente colapso econômico. Em muitas empresas, as ações se baseiam apenas no que havia ali para o indivíduo, a curto prazo. Não se pensa no que poderia beneficiar a todos ou limitar os danos à economia global. [p. 27]
Isso merece uma reflexão mais aprofundada ⚠️
Seu trabalho sempre demonstrou que projetos com vinte ou mais pessoas precisavam de mais esforço do que aqueles que contavam com cinco ou menos. Não era só um pouco mais, mas muito mais. Uma equipe grande levaria cinco vezes mais horas do que uma equipe pequena para realizar algo. Ele viu isso repetidas vezes e, em meados da década de 1990, decidiu tentar realizar um estudo amplo para determinar o tamanho certo de uma equipe. Ele analisou 491 projetos de médio porte em centenas de empresas diferentes; todos exigiam a criação de produtos novos ou de novas funcionalidades, e não novas versões de antigos produtos. Lawrence dividiu os projetos de acordo com o tamanho das equipes e logo notou algo interessante: assim que uma equipe ficava com mais do que oito membros, ela passava a levar muito mais tempo para realizar seu trabalho. [ibid]
Manter um tamanho razoável é uma questão de inteligência. Mais do que isso é difícil gerenciar.
Assim como em uma equipe das Forças Especiais, todos em uma equipe Scrum têm de saber o que os outros estão fazendo. Todo o trabalho que está em andamento, os desafios enfrentados, os progressos feitos, tudo tem de ser transparente para todos. E se as equipes ficarem grandes demais, a capacidade de todos se comunicarem de forma clara, ao mesmo tempo, fica confusa. Há informações cruzadas demais. Em geral, a equipe se divide social e funcionalmente em subequipes que começam a trabalhar com objetivos cruzados. A interfuncionalidade se perde. As reuniões que levavam minutos agora duram horas. [p.28]
Isso entra num padrão de interoperabilidade. O Scrum é sobre compartilhamento de informação. Se vc tem uma equipe gigante não dá pra compartilhar informações entre todos de maneira rápida.
Acima é um exemplo do hakka dos all blacks.
Na verdade, são tais interações, como nosso ambiente, que estimulam nosso comportamento. O sistema que nos cerca, em vez de qualquer qualidade intrínseca, é o responsável por grande parte do nosso comportamento. O Scrum foi criado para mudar tal sistema. Em vez de buscar culpados e falhas, ele recompensa o comportamento positivo porque se concentra nas pessoas trabalhando em conjunto e conseguindo cumprir as tarefas. [p.29]
A resposta é que todos somos criaturas do sistema onde estamos inseridos, e o que o Scrum faz é aceitar tal realidade e, em vez de procurar um culpado, tenta analisar o sistema que produziu o erro e corrigi-lo. [p.30]
A lição mais importante sobre o ambiente, chamado pelo autor de sistema, é que com as mesmas pessoas produzimos resultados diferentes.
Link - The Long Gray Line - Douglas McArthur
Fim do Capítulo 3