"Pule a cerca" ou a história de como se tornar uma equipe em três horas

Existem diferentes opiniões sobre como as equipes se tornam equipes. Existem alguns dos modelos mais populares que falam sobre a incapacidade de se tornar uma equipe rapidamente. Esse pode ser um longo processo com dinâmica própria.



As empresas, no contexto do tema, muitas vezes se interessam pelo fato de que, mesmo que não em um curto espaço de tempo, então quando você pode transformar a transformação em uma equipe, porque sabe-se que é o “trabalho em equipe” que permite alcançar os resultados mais eficazes. Aqui, eles contam com líderes - gerentes de projeto, Scrum Masters, líderes de equipe. Alguém falará sobre a importância de “irmos juntos ao bar” na fase inicial, alguém - sobre a escolha de um nome ou logo como forma de definir e enfatizar a identidade da equipe.



O que mais gosto é a visão da equipe como um grupo de pessoas que tiveram sua primeira experiência conjunta de sucesso. Ao treinar sobre um tópico semelhante, encontrei a metáfora de "pular a cerca". Nela, a cerca é a nossa capacidade de desenvolver soluções para problemas comuns e, para "ultrapassá-la", é necessário ter calor, sentido de humor e vontade de trabalhar juntos.



Neste verão, comecei a trabalhar em um projeto que atualmente é uma das maiores prioridades da empresa. Seu principal objetivo é substituir back-ends de legados antigos por arquitetura moderna de micro-serviços e, assim, tornar o mundo das telecomunicações um lugar melhor. A expectativa é grande e o ritmo é acelerado, o que implica em forte crescimento e necessidade de recrutamento e lançamento de novas equipes. Uma dessas novas equipes seria montada e lançada por mim.





Bem, essa é a ideia.



Mergulhei em um período de seleção criteriosa de candidatos que durou algum tempo. Conheci pessoas e numa conversa informal tentei saber o seu ponto de vista sobre vários assuntos, mas com a aposentadoria completa e datas diferentes de lançamento do projeto, nem todos tivemos uma boa oportunidade de nos conhecermos realmente. No entanto, a composição de “profissionais altamente motivados e multifuncionais” (trabalhamos no Scrum) foi gradualmente recrutada.



E, como costuma acontecer, em algum ponto o volante começou a girar cada vez mais rápido e agora não há tempo para explicar ou para um bom pontapé inicial. Você precisa pegar as pessoas recrutadas para a equipe e começar rapidamente. Ao mesmo tempo, o regime pandêmico impôs uma restrição severa à possibilidade de eventos notórios de formação de equipes. Embora deva ser inútil lamentá-lo: com todos os preparativos, ainda não tivemos tempo para um relacionamento normal.



Então, pela primeira vez, todos nós nos "vimos" apenas no primeiro planejamento. E como não se tratava apenas de planejamento, mas do PIP (Product Increment Planning - um evento no SAFe dedicado ao planejamento de alto nível do trabalho das equipes para os próximos sprints), então tivemos que descobrir muitas coisas em um período de tempo limitado.



Imagine este momento. Esta é sua primeira experiência de tal evento. Você se vê em uma teleconferência com nove estranhos e, embora tenha acabado de ser declarado uma “equipe”, não tem ideia de quem são essas pessoas, quais são as habilidades que elas realmente possuem, e você tem três horas para formar uma “equipe” juntos. plano de trabalho para os próximos três meses.



Você também tem um pouco de medo da difícil tarefa, que se propõe a ser decomposta em vários pontos do plano, uma vez que a descrição não é inequívoca.





A propósito, nosso planejamento de incremento de produto, se fosse offline, poderia ser assim.



No início, ficamos literalmente parados, metaforicamente aglomerados em torno do backlog existente e discutimos o que pode ser feito. Em resposta, a equipe de desenvolvimento muitas vezes respondeu apenas ao silêncio, o processo não foi fácil.



E ainda assim eu, como aquele bombeiro, incansavelmente batendo pedra em pedra repetidamente, continuei a animar amigavelmente a equipe de desenvolvimento. Como uma faísca esculpida inesperadamente se transformou em uma pequena chama.



Em resposta, um dos desenvolvedores fez uma pausa e ... apenas expressou tudo que preocupava cada um dos presentes. Incerteza, constrangimento, um alto nível de incerteza ... Sim, tudo isso está lá, e todos nós o sentimos. Mas isso nos impedirá de cumprir o que reunimos agora? Me diga isso!



De repente, outro engenheiro confessou suas próprias dúvidas. E depois outros. Alguém considerou seu nível de especialização insuficiente, alguém hesitou em fazer perguntas de esclarecimento “estúpidas”. Alguém apenas se sentiu incomodado, porque acabara de nos conhecer e não queria causar a impressão “errada”.



Quando dissemos em voz alta todas as fontes de nossa ansiedade, parecia que ficou mais fácil respirar. Cada um de nós fez sua própria confissão e ninguém nos condenou. A atmosfera estava ficando mais quente. Houve piadas.



Um fogo tímido se transformou em uma chama brilhante e confiante.



Nosso grupo de pessoas que mal se conheciam se sentia muito diferente. Gradualmente, desenvolvemos uma estratégia de análise do backlog. Os desenvolvedores avaliaram os requisitos e trabalharam juntos: eles discutiram o que precisa ser feito e quais níveis de decomposição são necessários para uma tarefa específica. Tudo isso foi imediatamente gravado no JIRA. Em seguida, eles distribuíram o trabalho. Todos participaram da discussão.



Foi incrível ver como eles descobriram em questão de minutos que todos faziam parte da equipe.



Eu me deparei com uma palestra TED sobre esse assunto muito mais tarde.



Entretanto, o Product Ouner também trabalhava com força e força, apesar de uma boa parte do trabalho ter sido feito por ele antes desta reunião: afinal, foi ele quem preparou todos os requisitos. Ele explicou as metas de alto nível nas quais a equipe precisava se concentrar, atualizou a lista de pendências, respondeu às perguntas e esclareceu tudo o que pudesse ser esclarecido.



Eu, como Scrum Master, direcionava o movimento da discussão quando era necessário, evitando o surgimento do sentimento de que a própria discussão estava chegando a um beco sem saída.



Após três horas de trabalho árduo, a equipe terminou de construir um roteiro em relação às suas metas para os próximos três meses e, assim, concluiu o planejamento.



No dia seguinte, o Product Owner apresentou este plano às partes interessadas e, levando em consideração alguns pequenos comentários sobre o texto, ele foi acordado e aprovado.



Todos nós conseguimos fazer isso agindo juntos. Ajudando uns aos outros, tivemos nossa primeira experiência conjunta bem-sucedida antes mesmo de começar a trabalhar nas tarefas. Nesse planejamento, nossa equipe encontrou uma conquista comum (é claro, a primeira de muitas). Nós nos tornamos os “conquistadores do planejamento de PI” e isso nos deu a sensação de que certamente seríamos capazes de implementar com sucesso todas as outras partes de nosso complexo projeto.



E se me perguntassem: “Como as equipes se tornam equipes? É um processo longo? ”, Responderia que adquirem uma verdadeira identidade de equipa ao“ pular a cerca ”, ou seja, ultrapassar a primeira dificuldade, agindo de forma harmoniosa e solidária. E é responsabilidade do líder fazer isso acontecer o mais rápido possível.



E o que exatamente ele pode fazer para isso soa como um tópico para o próximo artigo :)



All Articles