Como devem ser os times Scrum?

Olá,

Você sabe como compor o Time Scrum?

Em projetos Scrum, muito se fala do Scrum Master ou do Product Owner, mas pouco se ouve sobre o Time Scrum ou Time de Desenvolvimento.

Você acha que para implantar Scrum, basta nomear um Scrum Master, um Product Owner, juntar uma equipe qualquer e pronto?

Não é bem assim.

Abaixo vou detalhar como deve funcionar o Time Scrum, e qual a diferença entre um time tradicional e um Time Scrum.

Boa leitura…

Clique no Botão Para Baixar

[button_1 text=”FAZER%20O%20DOWNLOAD” text_size=”32″ text_color=”#ffffff” text_bold=”Y” text_letter_spacing=”0″ subtext_panel=”N” text_shadow_panel=”Y” text_shadow_vertical=”1″ text_shadow_horizontal=”0″ text_shadow_color=”#ffff00″ text_shadow_blur=”0″ styling_width=”40″ styling_height=”30″ styling_border_color=”#000000″ styling_border_size=”0″ styling_border_radius=”6″ styling_border_opacity=”100″ styling_gradient_start_color=”#ffa035″ drop_shadow_panel=”N” inset_shadow_panel=”N” align=”center” href=”http://www.mindmaster.com.br/e-book-como-implantar-scrum/” new_window=”Y”/]

O Time Scrum

Nas abordagens tradicionais de desenvolvimento de software é comum encontrarmos vários tipos de trabalho bem separados:

• arquiteto,
• programador,
• testador,
• administrador de banco de dados,
• prototipador,
• e assim por diante.

No Scrum é um pouco diferente.

O Scrum define o papel da equipe de desenvolvimento, que é nada menos do que uma coleção de desses tipos de pessoas.

Os membros da equipe de desenvolvimento, em conjunto, devem possuir as habilidades necessárias para entregar o que foi solicitado pelo Product Owner.

O Time Scrum é comumente chamada de Equipe de Desenvolvimento (mesmo que nem sempre é composta somente por desenvolvedores, este é o termo mais usado).

Times com funções especificas

Em muitas empresas você verá a divisão intencional de papéis de trabalho diferentes em equipes especializadas, específicas

Exemplo:

• Equipe de Design
• Equipe de Desenvolvimento
• Equipe de Testadores
• Etc

E estas equipes entregam o resultado dos seus trabalhos para as demais de forma independente e autônoma (cada um com sua responsabilidade).

Novamente, com Scrum é diferente.

A Equipe de Desenvolvimento deve fazer todo o trabalho para produzir uma ou mais funcionalidades do produto em cada Sprint.

Isto inclui a Concepção, Desenvolvimento, Integração e Testes dessa funcionalidade.

Desta forma, precisamos de uma equipe que seja hábil em todas essas tarefas.

Principais Responsabilidades

A figura abaixo ilustra as principais responsabilidades do time scrum durante o processo.

Realizar Execução Sprint

Esta atividade é óbvia.

Durante a execução Sprint, os membros da equipe de desenvolvimento realizam o trabalho de concepção, construção, integração e testes de itens do Product Backlog.

Mas o pulo do gato aqui é que, para fazer isso, eles devem se auto-organizar e decidir coletivamente como planejar, gerenciar, executar e comunicar o trabalho.

Falarei disso mais pra frente.

Inspeção e Adaptação

É esperado que todos os membros da equipe de desenvolvimento participem de cada reunião diária (Daily Scrum), durante os quais os membros da equipe coletivamente inspecionam o progresso em direção à meta do sprint e adaptam o plano para o trabalho para tal.

Se algum membro da equipe não participar, a equipe pode perder algum detalhes importante do contexto geral e isso pode impactar objetivo do sprint.

Grooming do Product Backlog

Se você já leu o nosso artigo sobre o Product Owner, sabe da importância do Grooming durante o planejamento do Sprint.

Uma grande parte desse trabalho se concentrano que chamamos de refinamento do Product Backlog, estimativa de tamanho e priorização dos itens.

A equipe de desenvolvimento deve alocar até 10% do seu tempo em cada sprint para ajudar o Product Owner com essas atividades.

Planejar a Sprint

No início de cada sprint, a equipe de desenvolvimento deve participar do planejamento.

Em colaboração com o Product Owner e com a facilitação do Scrum-Master, a equipe de desenvolvimento ajuda a estabelecer a meta para o próximo sprint. A equipe então determina quais dos subconjuntos de itens do Product Backlog são importantes construir para alcançar esse objetivo.

Dica: Para um sprint de 2 semanas, pode ser gasto meio dia com o planejamento. Um sprint de 4 semana, gasta-se em média 1 dia inteiro planejando.

Ao invés de focar em um plano muito grande, incerto, e excessivamente detalhada no início, a equipe faz uma série de planos menores, mais detalhados, logo antes do início de cada Sprint.

Características do Time Scrum

Tem uma série de características que são essenciais em um time Scrum, conforme a figura abaixo:

Time Auto-Organizado

Os membros da equipe se auto-organizam para determinar a melhor maneira de conseguir o objetivo do sprint.

Não é o gerente de projetos (ou qualquer outro tipo de gerente) que deve dizer à equipe como eles devem fazer o seu trabalho (e o Scrum Master nunca deve fazer isso também).

Para ilustrar melhor como isso funciona, eu vou dar um exemplo que você já deve ter visto por aí (ou em algum documentário da tv a cabo).

Pássaros voando em uma formação em V.

Você já se perguntou: quando as aves decolam como é que eles sabem como devem fazer para formar o seu padrão V?

Você acha que existe um “pássaro gerente”, que antes de todos decolarem, mostra uma apresentação em PowerPoint para os demais pássaros, explicando como eles devem se portarem no ar para fazer a formação?

Claro que não né.

Os pássaros fazem isso através da auto-organização, uma propriedade bottom-up de um sistema adaptativo e complexo (assim como o desenvolvimento de software).

Em tais sistemas, muitas entidades interagem uns com os outros de várias formas, e essas interações são governadas por regras simples, que operam em um contexto de feedbacks constante.

Essa frase acima ficou um pouco difícil de entender né?

Traduzindo para um português claro:

É impossível prever antecipadamente todos os movimentos um ambiente complexo. Se você criar regras simples e estabelecer um objetivo comum para o grupo, estes irão interagir constantemente até encontrarem a melhor forma de chegar ao objetivo.

Assim como acontece com os pássaros.

Mas calma, não estou dizendo que Gerentes não são importantes. Longe disso!

Gestores, têm um papel vital no Scrum sim.

Eles devem criam (e recriar) o ambiente propício para que a equipe possa praticar a auto-organização.

Escreverei um post sobre essa interação de Gerentes com Scrum em breve.

Equipe Multi-Funcional

Membros da equipe de desenvolvimento devem, de forma coletiva, possuir o conjunto necessário de habilidades para fazer o trabalho.

A equipe tem que conseguir construir durante um Sprint, uma funcionalidade potencialmente entregável, ou seja, funcionando!

Equipes compostas apenas de pessoas com as mesmas habilidades (como vemos muitas vezes em empresas tradicionais) podem, no máximo, fazer parte do trabalho, e depois tem que entregar essa parte para outra equipe especializada continuar.

Por exemplo, imagine uma equipe de designers, que só criam protótipos, que os entregam para uma equipe de desenvolvimento (que só codifica), que depois entrega o código pronto para a equipe de testes.

Este cenário representa uma excelente oportunidade para problemas de comunicação e muitas idas e vindas entre uma equipe e outra.

Já na equipe multi-funcional, temos membros de diferentes origens.

Cada membro da equipe traz um conjunto de ferramentas para a resolução de problemas; e essas ferramentas podem envolver diferentes interpretações (dos mesmos dados), estratégias diferentes para a resolução de problemas, diferentes modelos de como as coisas funcionam, e diferentes abordagens e soluções.

Este tipo de diversidade geralmente leva a melhores resultados em termos de soluções mais rápidas, resultados de maior qualidade e maior inovação.

Também deve se esforçar para manter a diversidade na senioridade da equipe.

Muitas pessoas de nível sênior pode causar uma turbulência desnecessária, semelhante a ter muitos cozinheiros na cozinha.

Muitas pessoas júnior, no entanto, pode não ser suficientemente hábil para fazer o trabalho da forma mais eficiente.

Uma boa mistura promove um ambiente de aprendizagem saudável e colaborativo.

Profissionais T-Shaped (Modelo T)

Equipes de desenvolvimento flexíveis são compostos por membros com habilidades em forma de T, ou T-Shaped, conforme a figura abaixo extraída do blog da holistikbrands.com.

Habilidades em forma de T significa que um membro da equipe tem habilidades profundas em sua área, disciplina ou especialidade preferida.

Por exemplo, imagine um grande designer, e prototipação é a sua especialidade.

No entanto, ele também pode trabalhar fora de sua área de especialidade, fazendo alguns testes e documentações.

Pode até não ser tão bom testador ou documentador como aqueles que se especializam nessas áreas, mas certamente pode ajudar com os testes ou a documentação em algum momento que a equipe precise disso.

Os gerentes devem se concentrar na formação de equipes que têm o melhor conjunto de habilidades em forma de T possível.

Para resumir, o objetivo aqui é formar uma equipe com membros que têm as habilidades adequadas para cobrir as principais áreas de especialidade e, globalmente, ter alguma sobreposição de competências para fornecer flexibilidade ao time.

Atitude Mosqueteira

Um por todos e todos por um!

Os membros da equipe devem entender que a responsabilidade das entregas é do time, e não de uma pessoa. Por isso um deve colaborar com o outro.

Para que uma equipe Scrum funcione bem, nunca deve-se esperar que alguém diga:

“Eu já terminei a minha parte. Você não fez a sua, por isso ainda não concluímos”

Os membros da equipe devem compreender que eles devem trabalhar juntos para atender seus compromissos, porque se não, ele vai ser um problema para todos no final.

Tendo os membros da equipe com habilidades em forma de T incentiva essa atitude e torna mais prático, porque as pessoas são capazes de trabalhar em mais de um tipo de tarefa.

Nessas equipes não se deve ouvir de uma pessoa que é capaz de fazer o trabalho de outra dizer:

“Isso não é meu trabalho.”

O que esperamos ouvir são frases do tipo:

“Acho que posso ajudar com isso…”

Afinal, estão todos no mesmo barco:

Comunicação Frequente

Membros da equipe de desenvolvimento precisam se comunicar uns com os outros, bem como com o Product Owner e ScrumMaster, de uma maneira frequente, em que informações valiosas são trocados com rapidez e eficiência com o mínimo de sobrecarga.

Como resultado, a equipe Scrum tem oportunidades mais freqüentes para inspecionar e adaptar-se, levando a melhores e mais rápidas tomadas de decisões.

Há uma série de maneiras que uma equipe pode melhorar a comunicação.

O Manifesto Ágil afirma que comunicação face-a-face é a abordagem preferida (sempre que possível, dê preferência para a interação pessoal da pessoas).

Para as equipes distribuídas, a tecnologia pode ajudar (hoje em dia temos o Hangout, Skype e tantas outras ferramentas que podem colocar todos face-a-face mesmo não estando no mesmo ambiente físico).

Finalmente, ter pequenas equipes também melhora a comunicação.

Os canais de comunicação dentro de uma equipe não escala linearmente com o número de membros da equipe, mas ao contrário, aumentar pelo quadrado do número de pessoas na equipe de acordo com a fórmula N (N – 1) / 2.

Ou seja, se há 5 pessoas na equipe, há 10 canais de comunicação.

Se existem 10 pessoas na equipe, há 45 canais de comunicação.

Comunicação Transparente

A comunicação transparente oferece uma compreensão clara do que está realmente acontecendo para evitar surpresas e ajudar a construir a confiança entre os membros da equipe.

Simplificando, as pessoas devem se comunicar de uma forma que é menos provável para surpreender um ao outro.

Time do Tamanho Certo

O Scrum favorece pequenas equipes.

A regra geral é que ter entre 5-9 pessoas na equipe. Mas minha experiência pessoal diz que o ideal mesmo é entre 5-7.

Mike Cohn, no excelente livro Succeding With Agile, lista um punhado de razões para manter as equipes pequenas, que incluem o seguinte:

• Há menos pessoas exercendo menos esforço, porque eles acreditam que os outros vão perceber.
• A Interação construtiva é mais provável de ocorrer em uma equipe pequena.
• Menos tempo é gasto para coordenar os esforços.
• As pessoas se sentem melhor trabalhando em equipes pequenas.
• Problemas de especialização excessiva é menos provável de acontecer.

Agora, só porque Scrum favorece equipes pequenas não significa que não podemos usar Scrum em esforços de desenvolvimento maiores.

Scrum é freqüentemente usada para construir produtos que requerem mais de 9 pessoas.

No entanto, ao invés de ter uma grande equipe Scrum com, digamos, 36 membros, temos quatro ou mais Equipes Scrum, cada um com uma equipe de desenvolvimento de 9 ou menos pessoas.

Focados e comprometidos

Os membros da equipe precisam estar focados e comprometidos com o objetivo da equipe.
E o que mais atrapalha isso é a pessoa multi-tarefa.

Se uma pessoa está trabalhando em apenas um projeto/produto, é muito mais fácil para a pessoa ficar focada e comprometida.

Mas quando lhe pediram para trabalhar em vários projeto/produtos concorrentes, a pessoa deverá dividir o seu tempo, reduzindo seu foco e compromisso.

É mais difícil para um membro da equipe para fazer um trabalho de boa qualidade quando está pulando de produto em produto. É ainda mais difícil de ser verdadeiramente comprometidos com vários produtos simultaneamente.

Com base nisso, trabalhar em três ou mais projetos simultâneos é uma escolha econômica ruim.

Então, quantos projetos / produtos (e, provavelmente, as equipes diferentes) que uma pessoa pode atuar simultaneamente?

Provavelmente não mais do que dois.

Trabalhando em um ritmo sustentável

Um dos princípios orientadores do Scrum é que os membros da equipe devem trabalhar em um ritmo sustentável.

Ao fazer isso, eles entregam produtos de qualidade em um ambiente saudável e divertido.

No desenvolvimento tradicional, tem-se uma grande carga de trabalho ao final do projeto, no momento das integrações e testes.

É comum ver em projetos tradicionais super-heróis atravessando noites e fins de semana tentando tentando corrigir todos os problemas e bugs para concluir a implantação do sistema.

Algumas pessoas dão valor a este tipo de trabalho, e querem ser recompensados pelo seu esforço extraordinário. Mas o estresse em todos os demais é esmagador!

No Scrum não temos isso, pois o estresse dos testes e implantação ocorre, de maneira mais atenuada, ao final de cada Sprint.

O resultado agregado é um nivelamento do trabalho; ele não vem em enormes pedaços ou intensas rajadas, especialmente no final, quando é mais prejudicial. Este nivelamento significa que equipes Scrum provavelmente vão trabalhar menos horas extras e serem menos estressadas.

Entrosamento

O uso eficaz de Scrum requer equipes, não grupos.

A equipe é composta por um conjunto diversificado, multi-funcional e que trabalham em conjunto para alcançar uma visão. Um grupo é um conjunto de pessoas com um rótulo comum.

Como regra geral, as equipes devem ter entrosamento, e isso só se consegue com muito tempo trabalhando juntos.

Por isso é muito importante, na medida do possível, tentar manter sempre as mesmas equipes, ou pelo menos, manter as pessoas chaves juntas.

A longo prazo, ganhamos maior entrosamento que se reflete em um aumento acentuado de produtividade, pois seus membros sabem como trabalhar juntos, e eles ganharam a confiança de cada um.

Conclusão

A equipe é composta por indivíduos. E, como é dito no manifesto ágil, no Scrum “favorecemos indivíduos e interações”…

Logo, a equipe é o um dos principais pilares para o sucesso de um projeto Scrum.

Ah! Não deixe de conferir o mini curso gratuito

Se gostou deste artigo sobre o Time Scrum…

Deixe um comentário abaixo.