Outro dia desses uma pequena celeuma se estabeleceu onde trabalho, na Lambda3, quando o Scrum Master, que aguardava a chegada dos membros do time passou a colar adesivos vermelhos ao lado das fotos do quadro dos membros do time que, segundo ele, estavam atrasados para a reunião de grooming.

Acho que foi a vigésima vez que acompanhei um time discutindo pontualidade em reunião (na maior parte é sobre a reunião diária). Como eu me sento perto do quadro (que tem o burndown) e gosto de uma bagunça, fiquei acompanhando a argumentação que se intensificava conforme cada novo membro do time, segundo o Scrum Master, também atrasado, ia chegando.

Parece que o horário marcado para a reunião era 10 horas da manhã, contudo, o Scrum Master marcou pessoas que chegaram às 9:58, 10:00, 10:02, e assim por diante.

A discussão rolava solta, chegaram a mencionar um novo conceito, o de “meio atraso”. Pelo que ouvi, o meio atraso ocorria quando a pessoa liga avisando que vai se atrasar até 15 minutos antes da reunião (por exemplo, quando está no metrô, acontece algum problema e você nota que não vai chegar a tempo), depois o pessoal começou a discutir conceitos como “tolerância”, se ela existe ou não, para que serve.

Quase todas as afirmações tinham um quê de “para mim isso quer dizer tal coisa”, era uma tempestade de intervenções, ideias e críticas à atitude do Scrum Master (que tem um jeito todo especial de levar o time a discutir algum assunto que ele acha relevante). Tenho convicção de que quando o pessoal do time ler isso vai lembrar dos argumentos com mais detalhes, só que isso está longe de ser uma questão sobre certo ou errado.

Fui acompanhando até que alguém olhou para mim e perguntou: e você sr. analista de negócios, o que acha disso?

Eu disse algo assim: “Caro SM, essas ideias que estão saindo dessa discussão não vão sair do lugar até que você comece a colocar isso em um cartão. Claramente a estória “chegar na hora na reunião” não está bem escrita.

Começamos a ponderar e eu fiquei incomodando o time para que tratasse isso como um requisito. Eu sei que para quem só tem martelo tudo fica com jeito de prego, mas vamos lá, definir as regras para chegada em uma reunião entre sete, oito pessoas e definir uma estória do usuário tem exatamente a mesma estrutura de pensamento e características.

“Por que nos infernos estamos fazendo isso?”

Bem, essa é a primeira pergunta que precisa ser respondida por todos: “por que queremos estar todos aqui uma determinada hora do dia para realizar essa reunião?”.

Ela é a razão pela qual as pessoas vão acordar uma determinada hora e vão se dirigir para um determinado local. Para estabelecer a resposta é necessário que todos compreendam o que é essa reunião e para que ela serve, além do seu funcionamento.

Esse é o primeiro nível do consenso, é o mais fundamental: se não houver consenso a respeito das nossas motivações, todo o resto fica abalado. Quem nunca viu uma discussão descambar para o “eu nem sei porque estamos fazendo isso afinal!” ou “desde o começo vi que fazer isso não tinha sentido”. Sim, eu também penso, automaticamente lendo isso em algo “por que você não falou isso lá atrás?”, claro que nesse momento isso não nos leva muito longe.

Essa discussão pode levar a uma melhor compreensão dos membros do time a respeito da reunião e da sua utilidade e necessidade ou também pode levar o time decidir a descartar a reunião. Já vi isso acontecer e foi, naquele caso, benéfico.

Bem, vamos dizer que a primeira parte da estória definida pelo time seja:

“Para que morram menos pandas, vamos chegar na hora na reunião de grooming”.


O que significa “chegar na hora”?

Legal, a motivação está clara e é consenso, agora, o que quer dizer “chegar na hora”? Bem, isso pode variar muito. Só naquele dia ouvi essas possibilidades:

  • “Colocar o pé na porta até as 10 em ponto.”
  • “Não, não! Não adianta chegar às 10 em ponto, sentar ao computador, checar e-mails, ir no banheiro, não vai dar”.
  • “Ahh, mas é necessário ter alguma tolerância, afinal pode acontecer muita coisa no caminho, hoje mesmo o metrô passou lotado três vezes até eu entrar”.
  • ” Tolerância!? Eu não acredito em tolerância, se der 5 minutos depois vamos ter que dar a tolerância da tolerância”.

Esse é o segundo nível do consenso. Ele pode até fazer parte do corpo da estória se for simples:

Para que morram menos pandas, todos do time estarão na frente do quadro usando uma camisa polo em posição de sentido cantando o hino do manifesto ágil às 10 da manhã”.

Contudo, os critérios para que possamos considerar se alguém chegou na hora podem ser muitos, o que deixaria o corpo da estória muito grande. Esses detalhes todos nós colocamos no verso do cartão, como critérios de aceite. Note como podem ser variados:

  1. A camisa será considerada “polo” se constar “polo” na sua embalagem. (Necessário trazer a embalagem da camisa na primeira reunião).
  2. A versão do hino é a de 2002, gravada no acústico MTV.
  3. O horário de referência será a hora oficial de Brasília. Em caso de controvérsias, o horário de referência será o apresentado no celular do Scrum Master.
  4. Não há tolerância. Não estar usando sua camisa polo e cantando o hino do manifesto ágil às 10 em ponto da manhã classificará o membro do time como “atrasado”.
  5. O membro do time considerado “atrasado” que tenha ligado para o Scrum Master até 15 minutos para as 10 da manhã (hora de início da ligação) avisando do potencial atraso terá seu status alterado de “atrasado” para “meio atrasado”.
  6. O membro que chegar após as 10:10 será considerado “sequestrado”.
  7. O membro que chegar após as 10:45 será considerado “abduzido”.

Caramba! Quanto trabalho por causa de uma reunião!

Pois é, esse trabalho é custo, é tempo que poderia ser investido em outra coisa e esse é justamente o questionamento que precisamos fazer continuamente. Existe uma matemática por trás disso e ela se aplica à marcação da reunião e aos requisitos do produto de software sendo construído:

O nosso investimento de tempo e atenção na elaboração da estória é inversamente proporcional ao entrosamento do time.

É por isso que não consigo responder diretamente quando me perguntam “qual é o melhor artefato para comunicar as necessidades do negócio para um time?”.

Não respondo porque isso varia ao longo do tempo, conforme nosso entrosamento muda. É por essas que já comecei produtos usando requisitos bastante estruturados, tão completos que comunicavam sem mesmo a necessidade de apresentação e terminei minha atuação escrevendo rabiscos em um papel qualquer.

Esse nível de entrosamento é como um ativo do time e do produto como um todo. Aliás, é por isso que vivo pregando que:

Temos sempre dois produtos sendo desenvolvidos: o software e o time.

Dois produtos

Se você já está assustado com o custo para gerar o consenso, espere até ver o custo de manutenção. Como dizem por aí, “manter consenso é como manter um filho” (ok, não dizem não), mas é caro. As pessoas mudam e o ambiente muda, o que pode (felizmente) nos transformar em metamorfoses ambulantes, afinal, aprendemos.

Como ficou a reunião daquele time?

Não sei! Eu fiquei curtindo a discussão enquanto estava divertida, falei a minha opinião porque adoro falar e na hora do trabalho duro, de se acertar e definir as coisas eu deixei a bomba na mão deles, afinal, nesse ali usei a minha prerrogativa de galinha.

Claudio Kerber

Claudio Br é o melhor analista de negócios do Brasil. Ok, quem fala isso é a busca do Google e digamos que o algoritmo, por melhor que seja, (ainda) não consegue concluir esse tipo de coisa. De qualquer forma, ele sabe um bocado do assunto e o que mais gosta é de questionar premissas, desafiar o status quo e de ajudar com que desenvolvedores de sistemas e as pessoas do negócio se entendam e trabalhem em harmonia ao ponto dele poder simplesmente sair de mansinho. Para Claudio Br trabalhar na Lambda3 é um privilégio e uma satisfação.