Qual é a principal maneira de um Scrum Master manter uma equipe de desenvolvimento trabalhando em seu mais alto nível de produtividade?

O que é Scrum

Scrum é gestão de produtos

No Scrum, as entregas de produto são divididas em time box (tipicamente de 2 a 4 semanas) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software, são iterativas, ou seja, o trabalho é dividido em iterações que são chamadas de Sprints no Scrum.

As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.

A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.

Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo. 

Pilares do Scrum

Transparência

Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Esta transparência requer aspectos definidos por um padrão comum para que os observadores compartilharem um mesmo entendimento do que está sendo visto.

Exemplo:

Uma linguagem comum referindo-se ao processo deve ser compartilhada por todos os participantes;

Uma definição comum de “Pronto”, deve ser compartilhada por aqueles que realizam o trabalho e por aqueles que aceitam o resultado do trabalho.

Inspeção

Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção a detectar variações. Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar.

Adaptação

Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, e que o produto resultado será inaceitável, o processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível para minimizar mais desvios. O Scrum prescreve quatro Eventos formais, contidos dentro dos limites da Sprint, para inspeção e adaptação, como descrito na seção Eventos do Scrum deste documento.

• Reunião de planejamento da Sprint
• Reunião diária
• Reunião de revisão da Sprint
• Retrospectiva da Sprint

Os pré-requisitos para se trabalhar com Scrum

Como Scrum é fundamentado em um processo iterativo e empírico, se faz necessário estar preparado para se executar um projeto dessa forma! Muitos conceitos parecerão contra intuitivos e alguns impossíveis de se implementar, porém, isso se resume a uma questão de costume. Os requisitos são:

1. Flexibilidade e mente aberta: compreender que há sempre espaço para melhorar é fundamental. Você também ainda tem muito que aprender!

2. Não ter medo de experimentar: no coração de todo processo empírico está o método de tentativa e erro. Devemos estar preparados para experimentar de forma controlada. Fazer a coisa certa, rápido e corretamente: é possível?

O ditado "fazer certo da primeira vez“ pode por pressão desnecessária naqueles que estão em processo de aprendizado, como uma equipe nos seus primeiros Sprints. Sendo assim, precisamos entender que falhas não devem ser punidas e que toda equipe atravessa uma curva de aprendizado.

Daily Scrum

A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.

Os Daily Scrums normalmente são realizadas no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho.

Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas também podem estar presentes, mas só poderão escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informações sobre o estado do projeto.

O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucioná-lo. Durante o Daily Scrum, cada membro da equipe provê respostas para cada uma destas três perguntas:

O que você fez ontem?

O que você fará hoje?

Há algum impedimento no seu caminho?

 A Daily deve ser realizada em 15 minutos

Quinze minutos é tempo mais que suficiente para que que todos os membros de times pequenos (três pessoas do Development Team) interajam. Já para times maiores (nove membros do Development Team) isso pode ser considerado pouco tempo para que todos sejam ouvido.

Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de status report na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual membros da equipe assumem compromissos perante os demais.

O Scrum master fica responsável por resolver qualquer impedimento que o time tenha. 

Uma boa dica para a Daily Scrum(isso não é uma regra do Scrum). Reúna o Time para a reunião diária, de forma com que todos fiquem de pé, e de preferência em um círculo pequeno para que todos possam se olhar. Isso força com que todos sejam objetivos, diretos e breves em suas discussões e explicações. Afinal, ninguém quer ficar horas de pé, não é!

Reunião de Planejamento da Sprint

O trabalho a ser realizado na Sprint é planejado na reunião de planejamento da Sprint. Este plano é criado com o trabalho colaborativo de todo o Time Scrum. Reunião de planejamento da Sprint possui um time-box com no máximo oito horas para uma Sprint de um mês de duração. Para Sprints menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito. O Scrum Master ensina o Time Scrum a manter-se dentro dos limites do time-box. A reunião de planejamento da Sprint responde as seguintes questões:

Qual é o objetivo da Sprint?

O que pode ser entregue como resultado do incremento da próxima Sprint?

Como o trabalho necessário para entregar o incremento será realizado?

Cancelamento da Sprint

Uma Sprint pode ser cancelada antes do time-boxed da Sprint terminar. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele (ou ela) possa fazer isso sob influência das partes interessadas, do Time de Desenvolvimento ou do Scrum Master. A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. Isto pode ocorrer se a organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem. Geralmente a Sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâncias. No entanto, devido a curta duração da Sprint, raramente cancelamentos fazem sentido. Quando a Sprint é cancelada, qualquer item de Backlog do Produto completado e “Pronto” é revisado. Se uma parte do trabalho estiver potencialmente utilizável, tipicamente o Product Owner o aceita. Todos os itens de Backlog do Produto incompletos são reestimados e colocados de volta no Backlog do Produto. O trabalho feito se deprecia rapidamente e deve ser frequentemente reestimado. O cancelamentos de Sprints consome recursos, já que todos tem que se reagrupar em outra reunião de planejamento da Sprint para iniciar outra Sprint. Cancelamentos de Sprints são frequentemente traumáticos para o Time Scrum, e são muito incomuns.

Product Backlog

O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe então determina que itens será capaz de completar durante a Sprint que está por começar. Tais itens são, então, transferidos do Product Backlog para o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.

O Product Owner é o ponto central do projeto ágil e é quem exerce a liderança sobre o produto que está sendo desenvolvido.

É ele quem diz o que precisa e o que não precisa ser feito em relação ao produto que está sendo desenvolvido.

Principais Responsabilidades

Participação no Planejamento

O Product Owner é um participante-chave nas atividades de planejamento de Produto, Release e Sprints:

• Durante o planejamento do Produto o Product Owner trabalha com todas as partes interessadas da empresa (diretoria, demais departamentos, etc.) para conseguir visualizar o produto ideal.
• Durante o planejamento de Release o Product Owner trabalha com as partes interessadas e a Equipe Scrum para definir o conteúdo do próximo lançamento.
• Durante o planejamento do Sprint , o Product Owner trabalha com a Equipe de Desenvolvimento para definir um objetivo para o Sprint.

Refinamento do Product Backlog

É o Product Owner quem supervisiona toda a preparação e refinamento do Product Backlog, o que inclui: criar, atualizar, estimar e priorizar os itens.

Não é o Product Owner quem realiza todo o trabalho de grooming sozinho e ele também não estima os itens (é a Equipe de Desenvolvimento quem faz isso), mas ele deve estar disponível para perguntas e esclarecimentos durante estimativa.

O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto.

O gerenciamento do Backlog do Produto inclui:

Expressar claramente os itens do Backlog do Produto;

Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;

Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;

Garantir que o Backlog do Produto seja visível, transparente, claro para todos,

e mostrar o que o Time Scrum vai trabalhar a seguir; e,

Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.

O Product Owner é, no entanto, o principal responsável para que a atividade de Grooming seja feita em prol de um fluxo de entregas que gere valor ao projeto.

Definir os critérios de aceitação e verificar se foram atendidos

O Product Owner é responsável por definir os critérios de aceitação para cada item do Product Backlog (o Scrum Master é quem o ajuda com isso).

Importante: O Product Owner deve assegurar que os critérios de aceitação (e testes de aceitação com frequência específicas) foram criados antes que o item seja considerado na reunião de planejamento de Sprint. Sem eles, a equipe teria uma incompleta compreensão do item e não estaria pronto para incluí-lo em um Sprint. .

O Product Owner é responsável por confirmar se os critérios foram satisfatoriamente atendidos.

Ele pode optar por executar os testes de aceitação ele mesmo ou pode pedir a ajuda de usuários experientes, mas o Product Owner é quem dá a palavra final se um item atende todas as expectativas.

Outra dica importante: É interessante que o Product Owner verifique os critérios de aceitação durante a execução do Sprint ao invés de esperar até a revisão do Sprint. Ao fazer isso, o Product Owner pode identificar erros e mal-entendidos que a equipe pode corrigir antes da revisão Sprint.

Colaborar com a Equipe de Desenvolvimento

O Product Owner deve colaborar frequentemente com a Equipe de Desenvolvimento de uma forma muito direta e estreita.

O papel do Product Owner exige um, comprometido e engajamento diário. Muitas organizações que recém adotam Scrum falham neste ponto. Não promovendo o engajamento adequado do Product Owner com a Equipe de Desenvolvimento.

É mais fácil compreender a importância disso quando comparamos com o método tradicional de desenvolvimento, onde o envolvimento do usuário é muito maior no início do projeto (concepção, levantamento de requisitos), cai durante o desenvolvimento em si (atividades mais técnicas como design, codificação e testes unitários) e volta a ter envolvimento novamente quase no final do projeto para testar o que foi desenvolvido.

 problema do desenvolvimento tradicional é que, geralmente, o usuário descobre que o que foi desenvolvido não está exatamente como ele esperada e agora muito tarde ou muito caro para fazer as mudanças, pelo menos nesta versão.

Não é raro, em projetos que não usam o Scrum, ver discussões como esta:

Cliente: "Se vocês tivessem lido as minhas especificações com mais cuidado, vocês teriam construído o que eu realmente queria " Equipe de Desenvolvimento: "Bem, se você tivesse escrito o seu documento de forma mais clara, teríamos Construímos algo diferente. Nós construímos o que você pediu! "

Usando Scrum, construímos uma funcionalidade de cada vez, e não uma fase de cada vez. Isto significa que realizamos todas as atividades para criar uma determinada funcionalidade (design, codificação, testes) durante um Sprint.

Portanto, um alto nível constante de engajamento do Product Owner é essencial!

E o melhor disso tudo é que aquele diálogo de troca de acusações que citei acima, raramente (eu diria que praticamente nunca) acontece em projetos onde o Scrum é adotado de forma correta (leia-se, todos executando corretamente o seu papel).

O problema do desenvolvimento tradicional é que, geralmente, o usuário descobre que o que foi desenvolvido não está exatamente como ele esperada e agora muito tarde ou muito caro para fazer as mudanças, pelo menos nesta versão.

Não é raro, em projetos que não usam o Scrum, ver discussões como esta:

Cliente: "Se vocês tivessem lido as minhas especificações com mais cuidado, vocês teriam construído o que eu realmente queria " Equipe de Desenvolvimento: "Bem, se você tivesse escrito o seu documento de forma mais clara, teríamos Construímos algo diferente. Nós construímos o que você pediu! "

Usando Scrum, construímos uma funcionalidade de cada vez, e não uma fase de cada vez. Isto significa que realizamos todas as atividades para criar uma determinada funcionalidade (design, codificação, testes) durante um Sprint.

Portanto, um alto nível constante de engajamento do Product Owner é essencial!

E o melhor disso tudo é que aquele diálogo de troca de acusações que citei acima, raramente (eu diria que praticamente nunca) acontece em projetos onde o Scrum é adotado de forma correta (leia-se, todos executando corretamente o seu papel).

O Product Owner é um gerador de valor para o cliente

Características / Habilidades pessoais

Existem inúmeras características que podemos destacar em um bom Product Owner, porém podemos agrupá-las em quatro grandes categorias:

• Conhecimento de Negócio,
• Habilidades Pessoas,
• Autoridade,
• e Responsabilidade.

Scrum master

O Scrum Master é um dos três papéis que compõem uma equipe Scrum (junto com o Product Owner e o Time de Desenvolvimento).

"Enquanto o Product Owner está focado em construir o produto correto e a equipe de desenvolvimento está focada em produzir corretamente o produto, e o Scrum Master é o cara que ajuda todos a compreender os valores, princípios e práticas do Scrum. "

O Scrum Master age como um Coach para tanto a equipe de desenvolvimento quanto para o Product Owner.

O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum

Master faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. O Scrum Master é um servo-líder para o Time Scrum.

O objetivo do Scrum Master é incentivar a auto-organização.

O Scrum Master é treinador e facilitador.

O Scrum Master não é responsável pela entrega.

O Scrum Master não é o secretário da equipe, mas deve ajudar A equipe remove os próprios impedimentos.

O Scrum Master deve incentivar a equipe a assumir a responsabilidade

O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum. O Scrum Master trabalhando para o Product Owner O Scrum Master serve o Product Owner de várias maneiras, incluindo:

Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;

Claramente comunicar a visão, objetivo e itens do Backlog do Produto para o Time de

Desenvolvimento;

Ensinar a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa;

Compreender a longo-prazo o planejamento do Produto no ambiente empírico;

Compreender e praticar a agilidade; e, Facilitar os eventos Scrum conforme exigidos ou necessários. O Scrum Master trabalhando para o Time de Desenvolvimento

• O Scrum Master serve o Time de Desenvolvimento de várias maneiras, incluindo:
• Treinar o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade;
• Ensinar e liderar o Time de Desenvolvimento na criação de produtos de alto valor;
• Remover impedimentos para o progresso do Time de Desenvolvimento;
• Facilitar os eventos Scrum conforme exigidos ou necessários; e, Treinar o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido.
• O Scrum Master trabalhando para a Organização
• O Scrum Master serve a Organização de várias maneiras, incluindo:
• Liderando e treinando a organização na adoção do Scrum;
• Planejando implementações Scrum dentro da organização;

Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico; Causando mudanças que aumentam a produtividade do Time Scrum; e, Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum nas organizações.

Coach

O Scrum Master deve agir como um coach (algo como um mentor, um treinador) tanto a equipe de desenvolvimento Scrum quanto ao Product Owner.

Quando surge qualquer problema que a equipe pode, e deve, ser capaz de resolver, a atitude do Scrum Master, como o de qualquer bom treinador, é:

"Eu não estou aqui para resolver seus problemas por você; em vez disso, eu estou aqui para ajudá-lo a resolver seus próprios problemas.“

Acredite nas pessoas; Confie neles para fazê-lo por si só

O grande Scrum Master é um líder servo. Construí uma comunidade, Curar relacionamentos e ouve os outros.

Agora, se o problema é um impedimento que a equipe não pode resolver sozinha, o Scrum Master deve tomar para si a responsabilidade de resolver.

O Scrum Master também faz o papel de Coach para novos Product Owners, ajudando-os a entender e cumprir as suas responsabilidades como Product Owner.

Fazendo uma a analogia com equipes de esportivas, é como se o Scrum Master fosse o treinador do time e o Product Owner o dono da equipe. Logo, o Scrum Master é responsável por maximizar os resultados do time através do Scrum.

Líder Servidor

O Scrum Master é também um líder servidor

Um líder servidor nunca perguntaria a um membro da equipe…

"Então, o que você vai fazer por mim hoje?"

Em vez disso, um líder servidor perguntaria…

"Então, o que posso fazer hoje para te ajudar e sermos mais eficazes?"

Autoridade no Processo

O Scrum Master é autoridade do processo.

Autoridade neste contexto não é o mesmo tipo de autoridade que um gerente funcional ou gerente de projeto teria.

O Scrum Master não contrata e nem demite ninguém e também não é ele quem dita para a equipe quais as tarefas que deve fazer ou como fazê-las. Em vez disso, o Scrum Master ajuda a equipe a definir e aderir ao seu próprio processo para ter certeza que o trabalho seja feito da melhor forma possível.

O Scrum Master tem o dever de garantir que todos da equipe Scrum conheçam os valores, princípios e práticas, juntamente com as abordagens específicas da equipe Scrum. O Scrum Master continuamente ajuda a equipe Scrum melhorar o processo para maximizar o valor do negócio entregue.

Escudo contra Interferências

O Scrum Master protege a equipe de desenvolvimento de interferências externas para que eles possam manter o foco na entrega de valor a cada sprint.

A interferência pode vir de inúmeras de fontes, desde gestores que querem mudar os membros da equipe no meio de um sprint até a problemas provenientes de outras equipes.

Não importa qual a fonte da interferência, o Scrum Master atua como um interceptor para que a equipe possa se concentrar na entrega de valor.

Removedor de Impedimentos

O Scrum Master também assume a responsabilidade de remover qualquer obstáculo que possa inibir a produtividade da equipe (quando os próprios membros da equipe não podem removê-los).

Agente de Mudança 

Para muitas empresas o método de trabalho do Scrum é uma mudança muito grande na cultura de trabalho.

O Scrum Master ajuda, então, as pessoas a entenderem essas mudanças, os impactos da adoção do Scrum e os benefícios que o Scrum pode ajudar a atingir.

O Scrum Master também garante que a mudança efetiva está ocorrendo em todos os níveis da organização, permitindo não só o sucesso a curto prazo, mas, os benefícios a longo prazo com o uso do Scrum.

Características pessoais de um bom Scrum Master 

Conhecimento

Para ser um bom Coach, o Scrum Master deve dominar os processos do Scrum.

Ele não precisa ser um especialista técnico nem dominar as linguagens de programação que o time de desenvolvimento vai usar, mas um mínimo de conhecimento é muito importante para ajudar o time a resolver impedimentos.

O Scrum Master também não precisa ser um especialista no domínio do negócio (o Product Owner é quem deve ser), mas, novamente, o conhecimento do negócio também pode ser muito útil.

Questionador

Scrum Masters tem que saber fazer as perguntas certas.

Aquele tipo de pergunta que faz as pessoas pararem e pensarem:

"Hmm. Eu nunca tinha pensado desta forma. Agora que você me fez essa pergunta, isso me faz pensar que pode haver outra forma de resolver. “

Grandes Scrum Masters quase nunca respondeu diretamente às perguntas, em vez disso, ajudam as pessoas a perceberem que eles têm o conhecimento necessário para encontrar suas próprias respostas.

Paciente

Como Scrum Masters preferem não dar respostas, eles precisam ter muita paciência até que a própria equipe consiga chegar na resposta.

Isso ajuda no aprendizado da equipe em relação ao projeto e, além disso, ajuda a amadurecer o processo e elevar o nível de maturidade da equipe.

Colaborativo 

O Scrum Master deve ter excelentes habilidades de colaboração para trabalhar com o Product Owner, a equipe de desenvolvimento, e todos os outros envolvidos.

Além disso, como o Coach do processo, o Scrum Master está sempre procurando oportunidades para ajudar os membros da equipe à alcançar um nível maior de colaboração.

A colaboração é fundamental para o sucesso do projeto Scrum.

Protetor 

O Scrum Master deve proteger a equipe.

Ele age como um cão pastor, guardando o rebanho dos lobos que podem tentar atacar (neste caso, lobos são qualquer impedimento organizacional que possam aparecer).

O Scrum Master também protege o processo. Sempre que as coisas se tornam difíceis é comum algum membro da equipe se desviar do processo ágil e cair na tentação fazer as coisas do jeito que acha mais familiar, da forma tradicional.

Transparente

Finalmente, o Scrum Master é transparente em todas as formas de comunicação.

Ele é transparente em todas as suas ações, não esconde nada de ninguém (não deve existir agendas ou informações ocultas dos demais).

As pessoas não esperam nada além disso de um líder servidor.

O Dia-a-dia do Scrum Master

Como é a vida de um um Scrum Master durante um sprint?

De acordo com Ken Rubin (@krubinagile) a distribuição do tempo de um Scrum Master durante um Sprint ocorre conforme o gráfico abaixo:

"Claro, este gráfico não mostra uma alocação exata de tempo de um Scrum Master para todos os projetos. As alocações percentuais seriam diferente para um Scrum Master de uma equipe de alto desempenho e que trabalhem em conjunto por vários anos."

No início e no final do Sprint, a maior carga é com as atividade do Scrum (planejamento do sprint, a execução de sprint, retrospectivas de sprint e reuniões diárias).

Durante o desenvolvimento do Sprints surgirão muitos impedimentos e a remoção de impedimentos acaba se tornando a atividade de maior carga no dia-a-dia do Scrum Master.

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;
• Devops;
• e assim por diante.

No Scrum é um pouco diferente.

Todos das equipe devem assumir a responsabilidades

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

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

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

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).

Todo mundo tem voz.

O Time vai definindo seus processos e ganhando maturidade suficiente para que não haja um comandante, mas membros de uma equipe que se interagem entre si, em busca de um objetivo comum.

Cada um com o seu papel importante no processo de concepção do produto.

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 de colaboração

“NENHUM DE NÓS É TÃO BOM QUANTO TODOS NÓS JUNTOS!”

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.

Tamanho do Time de Desenvolvimento

O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho dentro dos limites da Sprint. Menos de três integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade. Times de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando um Time de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável. Havendo mais de nove integrantes é exigida muita coordenação. Times de Desenvolvimento grandes geram muita complexidade para um processo empírico gerenciar. Os papéis de Product Owner e de Scrum Master não são incluídos nesta contagem, a menos que eles também executem o trabalho do Backlog da Sprint.

Conclusão

Ao longo desses anos trabalhando com desenvolvimento de software, só posso dizer que, trabalhar com ágil, foi a forma mais eficaz para desenvolver software com qualidade e dentro das necessidades da área usuária que encontrei.

A construção em conjunto, atende a real necessidade da área usuária por meio da concepção do produto. Para isso, devemos contar com todos os papéis e com suas respectivas responsabilidades. Afinal, rodar o Framework Scrum, depende de todos os papéis. Cada papel tem sua importância.

O Scrum é só um conjunto de práticas. A mudança vem do envolvimento e da colaboração de todos para tonar as práticas do Scrum efetivas e alcançar os resultados esperados.

Bom, espero te contribuído!

Qual é a principal forma de um Scrum Master manter uma equipe trabalhando em seu nível mais alto de produtividade?

Qual é a melhor forma para que o Scrum Master otimize a produtividade do time?

Qual é a responsabilidade principal de um Scrum Master para manter uma equipe Scrum desempenhando em nível de produtividade máxima?

Como o Scrum Master ajuda a assegurar que o time de Scrum está trabalhando de forma efetiva?