Fragmental

O Guilherme Chapiewski causou uma bela confusão com seu último post. Uma chuva de comentários debate: O Scrum Master deve ser técnico?

Eu já conversei com o Guilherme sobre isso algumas vezes e sei o que ele quis dizer, mas acho que colocou de uma forma meio confusa. Para mim o ponto é: o Scrum Master deve ser um gerente de projetos/facilitador/babá em tempo integral?

Após alguns anos nessa estrada dá para entender porque algumas pessoas se preocupam tanto em afastar o papel de gestor (seja Scrum Master of Universe ou qualquer outro termo que você preferir) do papel de técnico. Muitas vezes técnicos quando postos no papel de gestor não conseguem tirar a mão da graxa e isso atrapalha o andamento das coisas. Eu já tive gerentes de projeto que afundaram todo um release porque pegavam para si tarefas técnicas e não conseguiam exercer suas tarefas oficiais.

Isso acontece bastante mas não quer dizer que vá acontecer sempre, ou que não possa ser resolvido. Dizer que o gestor não pode exercer tarefas técnicas e ponto final é ignorar a característica empírica de um processo ágil.

Quem assume que isso é uma verdade absoluta está buscando respostas fáceis ao invés de tentar resolver o problema. Isso não é diferente em nada do cidadão que usa todos os templates, artefatos e papeis do RUP no seu projeto, ou daquele que acredita que um selo como CMMI ou MPS.BR traz qualidade.

Seguir à risca todos os documentos possíveis ou acreditar piamente que um selo traz qualidade é buscar respostas fáceis.

Desde outubro que eu não trabalho com Scrum. A ThoughtWorks não possui exatamente uma metodologia de trabalho, nós entendemos que agilidade é um processo empírico:

The empirical model of process control provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs.

Cada projeto é um projeto, cada time é um time e aplicar uma receita de bolo, seja ágil ou não, é ruim. No meu projeto atual temos um time de desenvolvedores do mesmo nível. O papel de gestor de projetos fica com o tech lead e isso basicamente quer dizer que ele é quem perde 1/2 do dia em reuniões e é quem pede cerveja para a retrospectiva de sexta-feira. No resto do tempo está na máquina dele com o Eclipse aberto.

A diferença é que ele atua como tech lead, não como desenvolvedor. Ele não pode se comprometer com uma tarefa grande, ou em programar em par. O que ele faz é (1) ter certeza que possui entendimento sobre o que está sendo feito e dar sua posição sobre isso e (2) servir como palavra final quando algum assunto técnico atinge um impasse.

Eu pedi demissão da Globo.com um pouco antes do projeto acabar. Alem de atuar como Scrum Master e líder técnico da equipe eu ainda tinha que resolver algumas milhares de coisas relacionadas à minha viagem. Mesmo assim eu não abdiquei da minha responsabilidade de líder técnico. Eu desenhei com o Guilherme os WebServices que utilizávamos e não só sabia como eles funcionavam bem como enchi o saco dele para que tal coisa fosse desse jeito e não do outro. Eu trabalhei na primeira versão do framework JavaScript que criamos com o Tiago e depois fizemos algumas sessões de pair programming nas últimas alfinetadas.

Nas primeiras iterações eu ainda consegui pegar tarefas para mim, com o tempo isso foi ficando impossível mas eu não deixei de ser o líder técnico do projeto por isso. Assumir o papel de gestor do projeto me deixou com tempo fragmentado mas quanto mais ágil seu processo (e sua empresa) menos você precisa assumir o papel de gestor. Quando a empresa não requer muita burocracia desnecessária não há muito à facilitar, quando o time se gerencia não há muito há resolver.

Como o Antônio comentou no blog é muito bom chegar ao nível de ter essas discussões, pensar sobre o que é feito, mas é melhor ainda quando percebemos que processos ágeis são sobre pessoas e adaptação. Eu diria que um time não precisa muito mais de um Scrum Master Power Turbo do que de um tech lead, ambos são papeis importantes. Se você coloca seu tech lead como gestor de projeto e o impede de exercer suas funções técnicas você tem que ter uma estratégia para substituir essa perda.

Você pode ter certeza que as práticas que você mais odeia em uma metodologia de desenvolvimento não-ágil não foram criadas por pura maldade dos autores (bem, não sempre…). Estas práticas fizeram (e fazem) sentido nos cenários experimentados. Elas foram úteis e resolveram problemas. A grande questão é que não é porque uma coisa faz sentido em um cenário que ela deve ser aplicado à todos, ou sequer à maioria.

Cuidado para não ficar preso às respostas fáceis. Cuidado para não transformar processos empíricos em processos prescritivos. Cuidado para não tentar programar FORTRAN em qualquer linguagem.

This entry was posted on Monday, April 7th, 2008 at 7:13 pm and is filed under comunidade, gerencia, metodologias, programando, thoughtworks. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.