Work agreement para equipes distribuídas

Trabalhando sozinho ou com uma quantidade pequena de pessoas em um projeto, não é tão difícil de organizarmos as coisas. Entretanto, os desafios aumentam quando estamos falando de equipes maiores, distribuídas geograficamente ou equipes com uma disparidade significativa de conhecimento dos processos e/ou falta de familiaridade com as ferramentas que serão utilizadas.

Quando essas equipes são muito especializadas, corremos o risco de uma centralização de informações muito grande, gerando ilhas de conhecimento que são muito perigosas em situações críticas. Em outro post vou falar um pouco mais sobre como podemos diminuir essas ilhas de conhecimento!

Sempre haverá projetos que exigem processos complexos e uma certa especialização em determinadas áreas. Entretanto, isso deve ser tratado com atenção, de forma a minimizar a dependência em uma só pessoa. Podemos resolver este problema através de uma documentação mínima como, por exemplo, um roteiro ou uma wiki do projeto. Lembrando que esta documentação deve ser algo acessível para a equipe, não uma bíblia do projeto gerando um desperdício enorme de tempo de documentação inútil.

Nestas situações é que um Work Agreement (acordo de trabalho, em português) pode te poupar um tempo precioso e evitar impactos nas entregas.

O que é work agreement?

Na Taller nós enxergamos o work agreement como um guia de conduta com definições para determinadas situações quando se está trabalhando em equipe. Isso abrange todas as áreas envolvidas no processo passando pela gestão até o desenvolvimento propriamente dito.

Vale lembrar que estes acordos são documentos vivos, passíveis de adaptação e melhoria contínua e serão muito importantes para dar maior coesão e deixar o processo mais afiado, uma vez que todos estão alinhados.

Outro aspecto fundamental é que este documento deve estar sempre disponível para todos da equipe, de preferência fisicamente, como por exemplo, próximo ao board de kanban. No caso de equipes distribuídas, em um lugar público e de fácil acesso, como uma wiki ou um documento compartilhado com todos do time.

Quais são os benefícios de um work agreement?

A utilização de work agreement é uma ferramenta imprescindível para equipes que ainda não trabalharam juntas ou com uma disparidade de conhecimento significativa, pois permite um momento de interação e troca de experiências entres os membros da equipe. É uma ótima forma de estimular o engajamento do time e o protagonismo por parte de todos os envolvidos no processo.

Estes acordos de trabalho são uma ótima forma de:

• Estimular a autonomia do time
• Incentivar a postura de liderança
• Melhorar o entrosamento da equipe
• Manter a troca de experiências
• Garantir a evolução contínua do processo

Quem define o work agreement?

São determinados pela própria equipe, que discute as práticas e decide a forma de trabalho que será adotada para o projeto em questão com a finalidade de manter um ambiente de trabalho positivo e produtivo. Para iniciar este processo, a equipe deve marcar uma reunião de definição inicial com um timebox definido. Na minha experiência, algo em torno de 2 horas já é um tempo suficiente para que se possa levantar uma quantidade viável de itens para o time focar.

A partir daí, uma pessoa deve se encarregar de explicar qual a finalidade da reunião e dar alguns exemplos de pontos a serem discutidos, tais como: horário do daily meeting, atualizar o board diariamente, etc. Então a equipe deve tirar uns minutos para fazer um brainstorming de pontos cruciais para o sucesso do projeto. Vou dando mais exemplos ao longo do post.

Depois de ter os pontos levantados, cada membro da equipe deve ter um número definido de votos (a critério da equipe) para selecionar os itens mais importantes e então discutir as ações que devem ser tomadas com relação aos mais votados. É importante reforçar que estes itens são acordos entre os membros da equipe, logo, qualquer objeção deve ser reavaliada a fim de que todos estejam realmente de acordo com as definições.

Apesar de não estarem escritos em pedra, estes acordos devem ser seguidos à risca e, sempre que o time identificar que um acordo foi quebrado, isso deve ser comunicado o quanto antes e então o time poderá seguir por dois caminhos, dependendo da criticidade:

1) Stop the line para corrigir esta falha no processo e, de preferência, haver uma reunião de levantamento de causa raiz (5 whys).
2) Registro do incidente para tratamento na próxima retrospectiva.

Estes acordos devem ser sempre revisados nas retrospectivas com a finalidade de verificar se estão sendo cumpridos e então selecionar novos itens de melhoria para o time focar.

O que deve estar contemplado neste documento?

Como este é um documento co-criado por todos da equipe isso irá variar bastante, porém considero que alguns pontos devem ser tratados como tópicos a se discutir e tirar acordos com relação a eles. Alguns exemplos desses tópicos principais são:

• Comunicação
• Reuniões
• Documentação
• Core time (Período que o toda a equipe estará on-line)
• Fluxo de tarefas e histórias
• Fluxo de desenvolvimento
• Fluxo de Testes

Minha experiência

Aqui na Taller tivemos uma melhora significativa na comunicação e no entrosamento das equipes após a adoção dessa prática. Outro fator importante foi facilitar a troca de informação entre diferentes times de desenvolvimento.

Alguns dos acordos que funcionaram muito bem nos times que participei foram:

“One piece flow” (Uma história de cada vez)

Diminuir a troca de tarefas (task switching) e foco total em finalizar uma história por vez. Dessa forma o time trabalha unido para resolver os impedimentos e não deixar tarefas diminuindo a vazão do fluxo.

“Limitar WIP (Work in Progress)”

Definir um número máximo de tarefas que poderão estar em cada fase do processo. Isso nos ajuda a manter o fluxo contínuo e evita desperdícios.

“Ler o kanban board da direita para a esquerda”

Esta prática, em conjunto com as duas anteriores, melhorou muito a comunicação da equipe e com o cliente, uma vez que todos passam a ser responsáveis pelo fluxo e as restrições de WIP nos fazem dar mais atenção para as tarefas que não estamos mais diretamente envolvidos.

“Escrever os critérios de aceitação em formato Gherkin“

Essa prática otimizou a criação dos testes, evitou documentação excessiva e tornou os critérios de aceitação mais detalhados.

Por hora vamos ficar por aqui. No próximo post vou falar mais sobre as decisões tecnológicas que fazem parte deste work agreement. Fluxo de trabalho com git, padrões de código e testes serão alguns dos pontos que vamos tratar. Fique ligado!

Como estes acordos são uma documentação viva, estamos totalmente abertos a sugestões. Vamos continuar evoluindo esses processos? Compartilhe com a gente suas ideias nos comentários!