Quando falamos sobre times multidisciplinares na metodologia ágil, — aqueles que formam um Squad — inconscientemente, ultrapassamos o espectro profissional (hard skills) e entramos no entendimento sobre o comportamento humano nas relações interpessoais.
De antemão, o objetivo deste artigo não é mostrar uma análise psicológica — por mais que pareça —, mas sim proporcionar um entendimento de como os comportamentos de um time podem impactar a produtividade, o clima e a velocidade de entrega.
Abordaremos também os chamados soft skills e reforçaremos algumas das premissas do Manifesto Ágil. O intuito é apresentar à você, uma visão do que poderá encontrar pela frente trabalhando em um Squad. Acompanhe.
Liberdade de expressão
“Construir projetos em torno de indivíduos motivados, dando a eles o ambiente e o suporte necessário e confiando neles para fazer o trabalho.”
Ambientes impositivos, que não permitem que a voz dos envolvidos seja ouvida, já não se sustentam em nenhum lugar. Esse tipo de gestão pode funcionar muito bem em um quartel general, onde a hierarquia deve ser respeitada, mas não em um Squad.
A metodologia de Squads, consiste na analogia de uma equipe de rugby, onde cada membro possui papel essencial e único dentro de uma estratégia pré estabelecida. Neste contexto, entender as necessidades e dores de cada um dos membros, de maneira democrática, é extremamente importante.
Nas dailys e retrospectivas das empresas por exemplo, é fundamental que todos se sintam a vontade de expor situações que possam impactar o projeto, o clima da equipe, etc.
Transparência
“O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é por meio de conversa face a face.”
A palavra-chave aqui é explicitar tudo a todo momento. Toda relação deve ser baseada em confiança mútua, e no ambiente corporativo não é diferente. Se a equipe não tem clareza sobre as situações que vivenciam, pode-se gerar ruídos que influenciam na função de cada um.
Abaixo, confira exemplos de transparência em um time ágil baseado nos papéis de cada membro:
- Product Owner: backlog que permita a todos do time a informação do que deve ser feito em determinada entrega. Itens priorizados de maneira visual para que toda a equipe saiba sem pestanejar o que deve atacar primeiro.
- Scrum Master: permitir em ritos como a Dailly por exemplo, que as dores e impedimentos sejam sanadas e que todo o time tenha visão. Também consolidar a gestão visual de um projeto (via Quadro Kanban, visão de Sprint) aplicada sempre ao que for mais produtivo no dia a dia dos membros;
- Team members/Dev Team: diagnosticar os problemas e impedimentos de maneira clara, para que o Scrum Master possa atuar na remoção de impedimentos. Importante também traduzir a necessidade técnica de maneira que o PO como especialista no produto, possa ter visão do impacto gerado ao cliente final.
Multidisciplinaridade
“Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.”
Parece simples mas extremamente frágil quando falamos sobre pessoas. Um Squad multidisciplinar tem como principais características:
- Desapego sob papéis e responsabilidades;
- Confiança mútua no trabalho e entrega entre os membros;
- Compartilhamento de conhecimento perene.
Para que isso aconteça com fluidez, existe a necessidade de determinada familiaridade com alguns hard skills. Como exemplo podemos mesclar as atividades de um engenheiro de software com Quality Tester, ou arquiteto de solução e vice versa.
Além disso, esse tipo de prática depende principalmente da percepção dos membros no seguinte sentido: em times multidisciplinares, os membros podem atuar em mais de uma posição dentro do Squad, e a partir disso, encontra-se um ambiente colaborativo onde todos percebem e entendem valor na descentralização de atividades.
Se seu Squad não atua dessa maneira não se preocupe, essa é uma semente plantada por qualquer um dos membros e que em determinadas ocasiões tarda a aflorar. É um tipo de prática que deve ser sempre fomentada e reforçada para que as raízes permaneçam firmes.
Adequação a mudanças
“Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.”
A grande sacada da metodologia ágil é que ela permite entregar software e valor continuamente ao cliente final. Mais que isso, o curso que um projeto leva é mutável e há liberdade de refinar as prioridades de maneira rápida independente da fase do projeto.
Com certeza já ouviu falar que o ser humano é reativo a mudanças, e isso é verdade. Imagine que um projeto está chegando a sua entrega final e o escopo do software é alterado de maneira estrutural. Geralmente, a sensação dos times nesse tipo de situação é que houve falta de planejamento, e que haverá demasiado retrabalho.
Essa mudança de mindset talvez seja o mais complexo de ser conquistado, e assim como falamos acima, a transparência para reforçar as mini regras do Manifesto Ágil e a importância de gerar valor ao usuário final pode ser de grande valia.
Quando falamos sobre pessoas, tratamos sobretudo as diferenças e valores de cada indivíduo. Isso permeia estudos teóricos sobre comportamento humano e as reações perante determinadas situações. O ágil prega uma série de boas práticas positivas, que foram desenvolvidas para serem colocadas em prática!
