Entenda o conceito de união no Scrum
Esse não é um artigo muito técnico, nele pretendo trazer para vocês um pouco da minha visão e do que a minha experiência com agilidade e o Scrum me trouxeram ao longo desses anos de profissão com relação aos devs.
Mas, mesmo que este não seja um artigo muito técnico, ele tem total embasamento e respaldo nos valores da agilidade, em literaturas e no que dizem os principais autores desse universo. Então, vale a pena ler até o final.
“Dev Team: não somos açúcar, mas precisamos de UNIÃO”
O que quero dizer com esse título? Você saberia dizer? Está certo se pensou ser uma referência ao verdadeiro comportamento de um time, que, aliás, difere do comportamento de um grupo.
Já parou para pensar que nós nunca falamos sobre grupos de Scrum? Por quê? Será que o termo “team” foi escolhido avulso? O que você acha?
Eu te digo que não. No livro “Scrum A arte de fazer o dobro do trabalho na metade do tempo” (recomendo a leitura), o autor menciona que esse Framework nasceu a partir de uma jogada de Rugby que tem uma regra bem interessante, onde para valer a jogada a bola deve passar na mão de todos os integrantes do time enquanto avança no campo do time adversário.
Essa regra tipifica exatamente o conceito de time. É parceria, cumplicidade! Todos sempre envolvidos, todo mundo trabalhando e cooperando para que ao final o resultado seja positivo e válido.
Aliás, deixa eu trazer aqui o conceito de time e de grupo para entendermos a diferença (segundo o dicionário):
Grupo: conjunto de indivíduos que reunidos formam um todo.
Time: indivíduos que se unem para desenvolver uma mesma atividade.
O time no Scrum
O Scrum tem esse nome porque o conceito de time dentro do Framework é muito forte. E se não é, deveria! Foi estruturado para ser.
Por isso, ao fazer as estimativas na cerimônia de refinamento, o time precisa estar em consenso. Ele deve se apoiar e se ajudar nas decisões. E ao se comprometer com as atividades que cabem em sua capacite em uma sprint planning, também deve haver apoio mútuo.
Entenda uma coisa: todo e qualquer comprometimento em um projeto é de todos os devs. Portanto, todos devem se comprometer.
Não dá para trabalhar com a exclusão, sem se enxergar como integrante de fato de um time, entende?
Deixa eu dar um exemplo: lembra dos três mosqueteiros “um por todos e todos por um?” É sobre isso.
Sabe o Jack e a Rose do Titanic “se você pular eu pulo”? É sobre isso também.
É o conceito de união de fato. Aquilo de: Estamos juntos! Vamos trabalhar e conseguir! Não é: eu e você fazendo a nossa parte, cada um em um canto. Somos sempre nós cooperando um com o outro. Essa é a premissa!
Essa é uma consciência que os integrantes têm que ter. Mas também é algo que o Scrum Master pode e deve trabalhar para gerar, assim como o Product Owner que também tem responsabilidade com a união dos devs, embora alguns Pos por ai pensem que não.
Eu já disse isso várias vezes e volto dizer: o PO não tem que trabalhar só com o olhar voltado apenas para o produto e suas funcionalidade. Ele tem responsabilidade no andamento do time também; pois se o time não desenvolver, se não entregar o produto do qual o PO é dono, o PO não terá um produto para chamar de seu.
E aqui fica minha dica: PO, se entenda como parte integrante do time. Você precisa estar junto. Você é uma das engrenagens do desenvolvimento. Promova o engajamento!
E por falar em engajamento, nesse momento onde tudo pode ser feito remotamente, fica um pouco mais difícil de criar laços, mas eles se tornam ainda mais importantes para trazer o sentimento de união; só que para isso é preciso promover ações.
Dá para usar técnicas de PNL e conversar com o time sobre outros assuntos que não sejam só de trabalho e que gerem vínculo e empatia; que desperte a sensação de que do outro lado tem uma pessoa e gere conexão. É importante!
Para terminar, vou deixar aqui a sugestão de artigos onde trago algumas dicas que podem ajudar. Leiam. Maratonem:
Bjs e até o próximo artigo.
Comentários