BT

Formando equipes de alto desempenho, parte 2: Fase de Formação e o papel do Scrum

Postado por Alércio Bressano em 29 Fev 2012 |

Na primeira parte dessa série, foi abordada a teoria sobre equipes de alto desempenho e as características de cada um dos cinco estágios de maturidade pelos quais passam as equipes. Vimos ainda um pouco da experiência do autor na utilização de práticas do Scrum, para subsidiar a evolução das equipes.

Nesta parte será mostrado como as práticas ágeis de gestão, especialmente as do Scrum, podem ser aplicadas a uma equipe de desenvolvimento em formação (estágio 1). Será apresentado também como os membros da equipe e o líder desse processo de mudanças, que transformará um grupo de pessoas em uma verdadeira equipe (ou time), se comportam nesse primeiro estágio de maturidade.

Através da utilização do Scrum no trabalho com times de desenvolvimento de produtos de tecnologia, o autor observou evidências de que as práticas ágeis de fato promovem um ambiente de maior alinhamento de expectativas dos projetos em andamento com as necessidades dos clientes.

Foi observado também como as práticas mudam a atitude das pessoas e propiciam o ambiente e a cultura adequados para o trabalho em equipe. A evidência principal foi a ocorrência de conflitos durante os trabalhos (o segundo estágio de maturidade de formação de uma equipe). A partir desse momento, o autor concluiu que a implementação das práticas do Scrum promoviam a formação de um time, seguindo os cinco estágios descritos na primeira parte dessa série.

Elementos do Scrum

Antes de prosseguir com os detalhes da formação da equipe, é importante rever rapidamente alguns conceitos fundamentais do Scrum. O Scrum é um framework com práticas para gerenciamento de projetos, que define cerimônias (eventos com tempo fixo), papéis, artefatos e regras a serem utilizadas para conduzir o processo de desenvolvimento de produtos por uma equipe. Mais detalhes, podem ser vistos no Guia Oficial do Scrum (PDF em português).Segue os três papéis do Scrum:

  • O Product Owner ou PO é responsável pela consolidação das demandas dos projetos (definindo o produto que a equipe vai entregar aos clientes) e também pela sua priorização baseada no valor de negócio gerado. Itens com maior valor terão mais prioridade. O PO é o representante do cliente e cuida de toda a negociação que envolva a priorização das demandas. O artefato resultante é o Backlog do Produto. O foco do PO é o produto e o cliente.
  • O Scrum Master é responsável pela implementação das práticas do Scrum e pela execução de cada cerimônia (veja abaixo) respeitando o seu tempo delimitado (time-box).Também remove impedimentos que surjam e que comprometam a produtividade da equipe. Seu foco é o processo e a equipe.
  • O Time é o conjunto de pessoas responsável pela entrega do produto comprometido com o PO dentro dos parâmetros de qualidade definidos. Seu foco é a execução.

O Scrum define quatro cerimônias, que são eventos de tempo fixo que devem ser executados em cada ciclo de entregas (os ciclos são chamados de Sprints):

  • A Reunião de Planejamento do Sprint (Sprint Planning Meeting) acontece no início do ciclo de entrega e tem como pré-requisito o backlog atualizado pelo PO com as prioridades. Toda a equipe deve executar o seguinte: selecionar cada item, discutir como vai desenvolver e estimar. Ao final, o PO e a equipe entram em negociação (o Scrum Master conduz esse processo) e devem sair com um consenso sobre o que será feito no ciclo, com duração de duas a quatro semanas, gerando como produto o Backlog do Sprint.
  • A Reunião Diária (Daily Meeting) acontece durante a execução do Sprint, e é a principal ferramenta de autogestão da equipe; não existe chefe e a equipe faz uso da reunião para se gerenciar. A reunião não pode durar mais que 15 minutos e todos os membros da equipe ficam de pé. Cada membro fala o que fez e o que vai fazer; isso permite que todos saibam o que os outros estão fazendo e possam se organizar da melhor maneira para entregar o resultado planejado para o sprint.
  • No Sprint Review, que acontece ao final da execução do sprint, a equipe apresenta o que produziu ao PO e ao cliente. O objetivo é alinhar o entendimento entre todos, a respeito do que foi entregue no sprint. Ao final, é fundamental que o PO dê feedback à equipe sobre o produto recebido e quanto à sua satisfação em relação à entrega (realizado x planejado).
  • Na Retrospectiva do Sprint, a equipe avalia o que fez de positivo no sprint (e que deve continuar fazendo) e o que precisa melhorar (o que não foi bom para os resultados e precisa mudar). O Scrum Master deve promover um ambiente propício para que todos participem e expressem sua opinião.

Vale observar que o Scrum é baseado no ciclo PDCA. Veja na figura abaixo a correlação entre as etapas desse ciclo e as cerimônias do Scrum, em cada sprint:

Iniciando a formação da equipe com Scrum

Na fase de Formação, as pessoas estão inseguras em relação ao novo método de trabalho e é responsabilidade do Scrum Master, líder do processo, deixar claro os papéis (PO, Time, Cliente e o seu próprio papel), além de explicar para todos os participantes os objetivos de cada cerimônia e o tempo máximo de cada uma delas.

Nesse momento, o papel da liderança é fundamental, pois no estágio de Formação, as pessoas ainda seguem o paradigma do trabalho individual. O Scrum Master deve trabalhar para que os membros da equipe passem a colaborar e pensar no todo, pois a partir de agora todos passam a buscar somente um resultado: a soma dos pontos de cada item do Backlog do Sprint (os Story Points ou simplesmente "pontos", que são as unidades usadas para medir o esforço estimado no Scrum).

O Scrum Master deve garantir que as cerimônias do Scrum sejam cumpridas e que cada colaborador do projeto saiba onde está contribuindo para o resultado. É fundamental que o Scrum Master observe e aja para que as práticas sejam seguidas, mostrando sempre a importância de cada uma delas para o resultado final.

Implementação de Scrum na fase de Formação

O Scrum Master deve trabalhar para garantir a produtividade do time. Através do seu papel de remover os impedimentos e garantir que o time fique focado na execução, é recomendado definir um processo de "blindagem", que consiste em definir atividades que envolvem Usuários Chave, o PO e o Cliente, com o objetivo de garantir que, somente chegarão ao time demandas que efetivamente devem ser atendidas. É comum existirem demandas que chegam aos desenvolvedores e que são somente dúvidas que um colaborador de atendimento (sem perfil técnico) ou um usuário chave (mais experiente) poderiam solucionar. A blindagem visa impedir que demandas desse tipo interrompam o time e comprometam os trabalhos.

Toda mudança de processo tira as pessoas da zona de conforto e é natural a resistência ao novo modelo de trabalho. Um método utilizado para minimizar essa resistência é possibilitar que as pessoas da equipe participem da construção do processo. Veremos agora um exemplo prático de como aplicar esse método.

Uma técnica muito utilizada para promover a autogestão do time é utilizar um Task Board (veja um exemplo abaixo), que consiste geralmente em um quadro com post-its indicando as tarefas planejadas pelo time com o PO. Em um projeto que o autor participou, não foi utilizado esse recurso no primeiro Sprint e, na retrospectiva, alguns membros da equipe (que conheciam um pouco de Scrum) notaram a falta do quadro e indicaram sua não-utilização como um ponto a melhorar. O Scrum Master prontamente providenciou o quadro para o sprint seguinte, conforme registro real a seguir:

 

Além de promover a participação do time na definição da nova forma de trabalho, é fundamental que o Scrum Master mostre os resultados da utilização do Scrum. Em um time, por exemplo, notou-se que havia reclamações sobre o alto número de telefonemas de usuários solicitando demandas. Com o processo de blindagem em funcionamento, observou-se que isso acabou, conforme feedback do time na retrospectiva do segundo Sprint.

Outra ponto importante para a autogestão da equipe é a Reunião Diária. O Scrum Master deve ficar atento nessa reunião, pois será natural que as pessoas se preocupem em falar o que fizeram e o que vão fazer naquele dia e em seguida não prestarem atenção aos demais membros da equipe (evidência do individualismo). O Scrum Master deve observar tal postura e dar um feedback reservado a cada um da equipe que esteja agindo dessa forma. Observe que o Scrum Master não pode exigir ou dizer como cada pessoa irá se comportar, mas um bom questionamento para que haja essa reflexão e mudança de postura seria: "Se você entregar as 'suas' tarefas e o restante das pessoas não entregar as delas, o resultado final será positivo?". A partir desse momento, deve ser lembrado que não existem mais resultados individuais; existe um único resultado do grupo.

Ainda na cerimônia da reunião diária, o Scrum Master deve deixar claro que a reunião é uma ferramenta de gestão do time. Somente quem fala é quem está executando uma tarefa. Outras pessoas podem participar como ouvintes, mas o Scrum Master deve garantir que somente a equipe fale, não permitindo que outra pessoa externa ao time interfira no encontro. Algumas pessoas somente conseguem "trabalhar" sob cobrança e esse é mais um paradigma a ser quebrado. As pessoas não possuem mais "chefe", alguém para cobrar resultados. Portanto, devem se unir e definir a melhor forma de entregar resultados e fazer entre si as devidas cobranças.

Na Sprint Review, que formaliza a entrega feita pelo time ao Product Owner/Cliente, após a execução do sprint, é fundamental que o Scrum Master solicite ao PO feedback sobre a entrega, seja ele positivo ou negativo. Essa retroalimentação do processo é fundamental para o comprometimento do time.

Entretanto, na fase 1 de formação, é natural que os resultados variem bastante, pois o time ainda está aprendendo como planejar e está conhecendo sua capacidade produtiva; também está percebendo mais claramente o volume de interrupções ao longo do sprint, devido a tarefas não planejadas. O gráfico abaixo mostra o percentual de pontos entregues por sprint (planejado x realizado) em um caso real, nos sete primeiros sprints; observe a variação dos resultados ocorrendo na prática:

A retrospectiva do sprint pode ser vista como uma "sessão de lições aprendidas". O Scrum Master deve garantir que o que for discutido seja confidencial e que somente a equipe participe. Nesse momento, cada um deve expor o que ocorreu de positivo na execução do ciclo e onde o time precisa melhorar para vencer os desafios. É um momento de transparência e integração da equipe.

O Scrum Master deve conduzir a restrospectiva de forma que os problemas sejam analisados e as soluções, definidas, além de garantir que essas soluções sejam executadas nos próximos sprints. É importante também fazer uma ligação entre as ações definidas e os efeitos dessas ações nos produtos entregues e na satisfação dos clientes.

Conclusões

Podemos concluir que o framework Scrum, através de seus papéis e cerimônias, contribui com o ambiente necessário para o início da estruturação de uma equipe, permitindo com que um grupo de pessoas tenham suas responsabilidades claramente definidas e usem as melhores práticas de gestão. Isso permite o início do processo de integração das pessoas (primeiro estágio dos cinco para formação de equipes de alto desempenho), em busca de melhores resultados nas entregas dos produtos aos clientes.

Na terceira parte, falaremos sobre a evolução do grupo de pessoas para o próximo estágio na direção de uma equipe: o estágio 2, de Conflito. Também será abordado como o Scrum Master, líder do processo, deve agir nessa fase turbulenta.


Sobre o autor

Alércio Bressano (@alercio) é consultor e coach em Agile, Professor Universitário e Mentor em Produtividade Pessoal. É Diretor de Marketing e Comunicação do chapter do PMI em Sergipe, e desde 1999 trabalha com projetos de tecnologia. Atua como Gerente de Projetos e/ou Scrum Master em empresas de diversos ramos de negócio, fornecendo coaching na implementação de métodos de gerenciamento de projetos e formação de equipes.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Muito bom by Fábio Cruz

Excelente post Alércio, também sou entusiasta do Scrum e escrevo sobre suas práticas e é muito ver bons post como o seu evidenciando os benefícios do Scrum nos projetos de TI.

Temos outra coisa em comum também, sou diretor de Marketing do PMI-SC, ou seja, temos que trocar mais figurinhas sobre estes assuntos em comum.

Um grande abraço,

Fábio Cruz
Diretor de Comunicações do PMI-SC
blogueiro em www.fabiocruz.com

Muito bom by Vinicius AC

Parabéns! Um post inspirador e coerente. Sem dúvida uma ótima referência.
Aproveito para sugerir uma discussão. A Retrospectiva, apesar focada no "Act", para mim não é o Act. O Act é a implementação das melhorias identificadas durante a retrospectiva. Aqui na SWX, a equipe identifica e vota as melhorias durante a retrospectiva, depois cola no quadro estas melhorias, ordenadas por importância. Depois, tentamos implementar as melhorias no dia-a-dia, principalmente as consideras mais importante. Na retrospectiva seguinte, entre outras coisas, avaliamos o sucesso do Act.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT