Você já ouviu o termo time tarefeiro? Recentemente vi um tweet do nosso amigo Samuel Cavalcante sobre isso e decidi falar um pouco sobre esse tema no post da semana. Quem aí nunca trabalhou em um time assim?
Mas, partindo do princípio, o que é um time? Gosto de pensar que é um grupo de pessoas alinhados em alcançar um mesmo objetivo. Esse tipo de definição é muito mais fácil ser percebido em esportes, como times de futebol, por exemplo.
E o que seria um time tarefeiro? São times que pensam apenas em suas tarefas (ou tasks) e não se preocupam com entregas relacionadas ao negócio. Quando uma time é novo, é possível perceber muitas disfunções assombrando essa equipe. Além disso, é possível encontrar sintomas claros: falta de multidisciplinaridade, silos muito bem definidos, comunicação falha, falta de visão do todo, desalinhamento com o objetivo do produto, entre muitos outros.
Quando a gente fala sobre times novos e sem um mindset voltado para a entrega de valor, destaco um fator muito recorrente: a falta da visão de todo fluxo da cadeia de valor em que estão trabalhando. E o que isso quer dizer? Expectativas desalinhadas, ou seja, desenvolvimento espera entregar uma coisa e negócio espera receber outra.
Ora, trazendo a discussão para uma questão de princípios, gosto de pensar que agilidade é uma meio para entregar/agregar valor para o negócio. Por isso, times ágeis devem ter clareza em relação a definição de pronto. Entregar apenas partes de uma funcionalidade (e não sendo possível incrementar o produto), resulta na ineficiência de um time.
Outro ponto que destaco são os silos. Quando temos silos, a multidisciplinaridade é bastante afetada. Ou seja, por que ajudar o restante do meu time se não é minha especialidade, certo? Errado! Caso o outro silo não consiga finalizar suas atividades, no final não temos uma entrega que agregue valor para o negócio.
Um exemplo muito claro que me vem à cabeça é: temos determinada funcionalidade e a meta dos designers é entregar uma imagem da tela, com determinada documentação explicando como deve ser o comportamento da funcionalidade. Já a equipe de desenvolvimento, divida em front e back-end, esperam entregar suas respectivas partes. E assim, sucessivamente.
O grande problema nesse contexto é quando algum desses grupos não conseguem finalizar suas responsabilidades. Atrasa todo o fluxo que depende daquela “entrega” e acaba criando um estoque de atividades para serem continuadas pelos outros silos. O resultado disso é que não se tem uma entrega garantida. Provavelmente, nesse fluxo não temos cadência e nem o WIP limitado.
Para começarmos a desconstruir essa ideia, penso que é importante para o time entender o motivo de sua existência. Perguntas como:
- Por que existimos?
- Qual nossa missão como um time?
- Atender todas as demandas que aparecem ou apenas aquelas que estão relacionadas ao objetivo do produto?
Penso que são perguntas para nortear o time a encontrar a resposta.
Outro fator que pode ajudar a buildar um time, é demonstrar a relação entre problema e solução. Ou seja, qual problema nosso produto pretende resolver? Parece bobo, mas entender essa questão é primordial para pensarmos em soluções simples que possam facilitar tanto a vida dos nossos usuários e também do time como um todo.
Para ajudar melhor nesse ponto, recomendo ao leitor a nossa categoria de Agile UX.
Mas Diogo, e o lado técnico, como fica? Bom, não devemos deixar de lado. Como falei no post sobre eficácia e eficiência, times ágeis devem estar buscando sempre a eficácia. Ações que ajudem a descentralizar o conhecimento é essencial para tornar mais eficaz um time. A partir do momento em que uma equipe consegue ser multidisciplinar, a dependência de pessoas diminui cada vez mais. Recomendo fortemente o pair programming entre membros de silos diferentes para fortalecer a multidisciplinaridade.
Outra recomendação que faço é considerar o teste e design como parte do desenvolvimento. Algo muito comum que já vivenciei por aí, são times considerando essas áreas como algo fora do desenvolvimento. O resultado disso é muito simples: mais tempo investido nos testes depois que a funcionalidade está desenvolvida e mais tempo gasto para corrigir os bugs que aparecem, devido a falta de entendimento do que deve ser feito.
Algumas boas práticas você pode acompanhar nesse post aqui.Portanto, quando pensamos em times ágeis, devemos levar em consideração uma série de fatores. Desde entendimento de negócio até a busca da excelência no desenvolvimento da solução. Acredito que um time é uma unidade e não um agrupamento de várias pessoas. Uma grande forma de ajudar a times alcançar esse status é buscar a multidisciplinaridade.
Um grande abraço.
