Nem sempre chegamos em uma empresa onde todos os times são coesos, as pessoas sabem o porquê estão ali e onde querem chegar como equipe. Na prática, muitas vezes, temos apenas grupos de pessoas que foram colocadas ali por motivos desconhecidos, não há objetivos comuns e muito menos harmonia entre elas. Em outros casos a equipe já esteve unida, porém entraram novos membros e saíram tantos outros que aquela sinergia que um dia ali existiu ao longo do tempo se perdeu. Desenvolver a identidade de um time nem sempre é fácil, mas quem sabe uma atividade de team building possa dar aquele empurrãozinho?

Team Is – Is Not – Does – Does Not

A atividade Team Is – Is Not – Does – Does Not é uma forma simples de iniciar uma conversa com o time sobre os seus valores, propósitos, responsabilidades, objetivos e até mesmo sobre os seus limites como equipe. Porém, a identidade de um time não se cria da noite para o dia, tão pouco se define apenas com post-its coloridos. Tenha paciência, pois pode ser um processo de médio ou longo prazo onde a liderança precisa suportar essa jornada através de um ambiente seguro onde as pessoas possam exercer as suas individualidades respeitando o senso coletivo. Não se frustre caso essa atividade não flua de primeira, porém fique atento à possíveis disfunções na equipe que podem fazer com que os membros não se engajem na conversa sobre o que o time é, não é, faz e não faz.

O tempo sugerido para esta atividade é de pelo menos 30 minutos. Contudo, vai depender da quantidade de pessoas no seu time e do quanto elas estão abertas para conversar sobre isso. Talvez leve pelo menos uma hora ou mais de um encontro para completar o quadro.

Pro tip: Não deixe que isso acabe esquecido em algum Mural ou Miro da vida. Fique atento a situações em que você possa relembrar o time sobre os valores e responsabilidades que eles mesmos definiram. Geralmente a necessidade surge durante um conflito ou indecisão para resolver um problema. Você também pode marcar encontros recorrentes (a cada um ou dois meses) apenas para revisar o que foi definido anteriormente já que novas características surgirão à medida que o time trabalhe mais tempo junto. Mantenha esse documento vivo no dia a dia do time.

Is (É)

O que o time é? Quais são os seus valores? Quais adjetivos (positivos ou negativos) descrevem o time?

A equipe pode buscar inspiração nos valores do Scrum (Compromisso, Foco, Abertura, Respeito e Coragem), do XP (Simplicidade, Comunicação, Feedback, Respeito e Coragem) ou até mesmo nos valores do Manifesto Ágil como ponto de partida. Caso você note que a conversa não esteja fluindo, proponha ao time pensar sobre como eles gostariam de ser no futuro já que, talvez, nesse momento eles estejam com moral baixa e sem positividade para reconhecer e valorizar as suas qualidades (ainda que sejam poucas).

Exemplos: Comprometido com a qualidade das entregas, proativo na resolução de problemas, pontual com os prazos, transparente sobre impedimentos, teimoso na hora de pontuar as stories, pessimista em relação ao planejamento de longo prazo.

Is Not (Não é)

Alguns times podem achar mais fácil começar listando o que eles não são. Então, se o “Is (É)” não está funcionando, pule direto para o “Is Not (Não é)”. Lembre-se que essa atividade tem o propósito de criar a identidade de um time e, talvez, os membros ainda não tenham a noção clara do conjunto de atributos que os caracterizam. Neste caso, fique à vontade para compartilhar as suas observações sobre como você enxerga o time através de exemplos práticos coletados durante o tempo que vocês estão trabalhando juntos.

Exemplos: O time não é responsável por falar diretamente com o cliente, não é responsável por colocar o código em produção, não é mau humorado, não perde tempo em conversas aleatórias durante a daily, não é aberto para negociar o escopo de uma sprint já iniciada, não é rápido na correção de defeitos críticos em produção.

Does (Faz)

O que o time faz? Quais são as suas principais atividades e responsabilidades? Quais são os objetivos comuns do time?

Este é o momento onde conversamos sobre as práticas realizadas pelo time no seu dia a dia. Instigue as pessoas a pensar sobre a sua rotina e tarefas durante a Sprint (O que eles executam? Como executam?). Note que algumas das ações listadas aqui podem se tornar regras e acordos do time.

Exemplos: O time desenvolve soluções para o produto XYZ, faz testes unitários com cobertura de código de no mínimo 80%, o time corrige defeitos críticos de produção em até dois dias úteis, faz código de qualidade utilizando padrões de clean code, faz pair programming, faz war room quando está pegando fogo em produção, faz validação de user stories com o PO antes de colocar o código em produção.

Does Not (Não Faz)

Esta etapa define os limites do time, serve para alinhar expectativas com stakeholders e outros times sobre o que está fora do seu escopo de trabalho e mostrar o que não devem esperar que eles façam (pois não farão). Obviamente, mesmo que isso esteja “escrito no papel” não significa que o time não possa ser flexível para se adaptar à situação. Não deixe que isso limite o time à novas oportunidades. Contudo, estabelecer limites ajudará manter o time focando naquilo que realmente importa.

Exemplos: O time não atende requisições solicitadas diretamente pelo time de suporte (precisam previamente passar pela avaliação do PO), o time não tem acesso à edição de dados em produção, não faz hora extra a menos que seja aprovado pela gerência, não toma decisões sobre o produto XYZ (apenas pode ser consultado), não move uma user story para QA sem ter passado por code review.

Outras aplicações desta atividade

O Is – Is Not – Does – Does Not também pode ser utilizado para pelo menos duas outras situações.

Definição de um novo produto

A PO apresentou um novo produto ou uma nova feature para o time e você notou que eles ficaram com um ponto de interrogação na cara? Sugira essa atividade para que o time construa o entendimento sobre uma determinada ideia/proposta de forma colaborativa, descrevendo tanto os aspectos positivos quanto negativos do produto.

A partir desse entendimento pode-se mapear possíveis funcionalidades de um novo produto ou até mesmo identificar as características de uma nova funcionalidade para um produto existente. O importante é que esses elementos estejam claros para todos antes de iniciar o desenvolvimento a fim de evitar desperdícios como retrabalho durante a implementação.

Esclarecimento de papéis do time

Talvez você já tenha uma certa experiência e conheça os principais papéis e as suas responsabilidades no desenvolvimento de software. Contudo, para algumas pessoas pode ser a primeira experiência profissional, algumas exerceram mais de um papel na empresa anterior, nunca haviam trabalhado com um Scrum Master no time ou até mesmo conhecia os papéis só que as responsabilidades divergiam de empresa para empresa.

Neste caso, a atividade auxiliará no entendimento sobre o que esperar dos papéis na empresa atual através da definição dos limites e área de atuação de cada um. Apesar dessa construção ser colaborativa, ela deve estar alinhada com as definições de cargos da sua empresa. Consulte previamente o RH e oriente o time de acordo, pois pode ser que expectativas sejam criadas sobre uma determinada responsabilidade que não faz parte da descrição de um cargo, podendo haver conflitos entre o que foi contratado e o que é esperado pelo time.

Você identificou outras formas de utilizar essa atividade? Deixe um comentário aqui, pois adorarei aprender sobre novas formas de aplicar o Is – Is Not – Does – Does Not nos times 🙂

Referências

Essa atividade eu aprendi através de outros Scrum Masters ao longo da minha experiência profissional. Contudo, você pode conferir também no site Fun Retrospectives.