Trabalho de equipe Scrum coordenado
A fundação do Scrum, a estrutura de gerenciamento Ágil mais popular, começou com um artigo da Harvard Business Review de 1986 escrito por Hirotaka Takeuchi e Ikujiro Nonaka. No artigo, Takeuchi e Nonaka introduziram o termo "Scrum" para destacar as estratégias de trabalho em equipe que os times de rugby usam para marcar pontos e sugeriram que as equipes de desenvolvimento de produtos poderiam usar métodos semelhantes para melhorar suas taxas de sucesso.
A pesquisa apresentada no artigo indicou que equipes pequenas e auto-organizadas tiveram um desempenho significativamente melhor em produtos complexos após receberem os objetivos e determinarem como alcançar esses objetivos por conta própria.
Ken Schwaber e Jeff Sutherland desenvolveram a estrutura e formalizaram as funções dos membros da equipe Scrum na década de 1990. Em 1995, eles publicaram um artigo intitulado "SCRUM Software Development Process". Depois de gradualmente fazer outras melhorias no Scrum e publicar artigos adicionais, Schwaber e Sutherland concluíram a primeira publicação do Scrum Guide em 2010.
O Guia do Scrum refere-se ao Scrum e suas funções de equipe como uma "estrutura dentro da qual as pessoas podem lidar com problemas adaptativos complexos, ao mesmo tempo em que entregam produtos do maior valor possível, de forma criativa e produtiva. (…) A estrutura Scrum consiste em Equipes Scrum e suas funções, eventos, artefatos e regras associados".
Descrições dentro do Guia do Scrum sobre as funções da equipe afirmam que a "Equipe Scrum consiste em um proprietário do produto, a equipe de desenvolvimento e um Scrum Master. As equipes Scrum são auto-organizadas e multifuncionais. As equipes auto-organizadas escolhem a melhor maneira de realizar seu trabalho, em vez de serem dirigidas por outras pessoas fora da equipe. Equipes multifuncionais têm todas as competências necessárias para realizar o trabalho sem depender de outras pessoas que não fazem parte da equipe. O modelo de equipe no Scrum foi projetado para otimizar flexibilidade, criatividade e produtividade. As equipes Scrum entregam produtos de forma iterativa e incremental, maximizando as oportunidades de feedback".
Schwaber e Sutherland lançaram uma edição atualizada do Scrum Guide em julho de 2016. O conteúdo mais notável adicionado à edição de 2016 é a seção Scrum Values, que inclui detalhes sobre como os membros das equipes Scrum devem interagir uns com os outros e com o pessoal da empresa.
Project Management Guide
Your one-stop shop for everything project management
Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.
Recomendações de tamanho da equipe Scrum
Para alcançar o máximo de coesão na equipe Scrum e maximizar o nível de trabalho em equipe dentro do grupo, especialistas geralmente oferecem conselhos sobre o tamanho dela. Schwaber, que fornece treinamento Scrum em sua organização, Scrum.org, dá recomendações sobre o tamanho da equipe em seu livro de 2007, The Enterprise e Scrum. Schwaber explica que as equipes Scrum devem ser "limitadas em tamanho para maximizar a velocidade, conteúdo, precisão e largura de banda das comunicações. O tamanho da equipe é de até nove pessoas".
Mais tarde em seu livro, Schwaber oferece o seguinte conselho: "Mantenha o tamanho da equipe o mais próximo possível de sete. Sete mentes parecem capazes de alcançar e manter um modelo mental compartilhado de um sistema e sua representação em design e código sem ajuda artificial, como documentação. Os desentendimentos e o tempo de registro são minimizados".
Mindi Schnase, gerente de projeto da Renown Health, possui uma certificação CSM (Certified ScrumMaster) da Scrum Alliance e uma certificação PMP (Project Management Professional) do PMI (Project Management Institute). Na International Game Technology (IGT), empresa anterior de Schnase, ela trabalhou como engenheira líder de garantia de qualidade antes de fazer a transição para a função Scrum Master. A experiência de Schnase envolveu trabalhar em equipes Scrum de tamanhos variados.
Schnase aconselha que sete a nove pessoas por equipe é um tamanho bom e gerenciável, mas ela também explica que o tamanho da equipe é influenciado por detalhes do projeto. "Isso realmente depende do escopo do projeto. Eu era uma Scrum Master para várias equipes; um tinha três membros, outros tinham de sete a dez."
Sutherland, que continua a ministrar cursos Scrum pela Scrum Inc., incluiu muitas informações sobre a dinâmica da equipe no site de sua organização, incluindo a seguinte análise sobre tamanhos de equipe e produtividade:
"Lawrence Putnam, uma figura lendária no desenvolvimento de software, tornou o trabalho de sua vida estudar quanto tempo as coisas levam para fazer e por quê. Seu trabalho continuou mostrando que projetos com vinte ou mais pessoas precisavam de mais esforço do que aqueles com cinco ou menos. Não só um pouco, mas muito. (…) Então ele analisou 491 projetos de tamanho médio em centenas de empresas diferentes. Todos esses projetos exigiam a criação de novos produtos ou recursos, não uma redefinição de versões antigas. Ele dividiu os projetos pelo tamanho da equipe e notou algo imediatamente. Assim que as equipes cresciam para mais de oito pessoas, elas demoravam muito mais tempo para fazer as coisas. Os grupos compostos por três a sete pessoas exigiram cerca de 25% do esforço dos grupos de nove a vinte para fazer o mesmo trabalho."
Segundo os especialistas, sete membros na equipe é o número mágico. No entanto, não tenha medo de ajustar a quantidade de membros com base em projetos específicos.
Eventos de fluxo de trabalho e Scrum tornam as equipes Scrum mais eficazes
Equipes de todas as formas e tamanhos participam de um fluxo de trabalho específico quando decidem seguir o Scrum como parte do gerenciamento de projetos Ágil. Os eventos Scrum servem a um propósito valioso: incentivam a comunicação regular, especialmente entre os membros da equipe, e minimizam a necessidade de reuniões extras não definidas no Scrum.
Sem incorporar eventos Scrum em seus cronogramas, as equipes não seriam tão eficazes ou focadas. A lista a seguir representa o fluxo de trabalho típico que os membros da equipe Scrum usam para o desenvolvimento de produtos.
Visão do produto – O proprietário do produto resume a visão dele em uma declaração após receber informações de várias fontes, incluindo usuários finais, clientes, membros da equipe e outras partes interessadas. A declaração de visão do produto inclui detalhes do caso comercial sobre as metas do produto e como o produto se encaixa nas estratégias da empresa.
Backlog e refinamento do produto – Os itens de backlog do produto representam tudo o que pode ser entregue para um projeto de forma independente. A maioria desses itens se concentra em entregar valor aos clientes, assim como os recursos do produto e as histórias dos usuários. (As histórias de usuários apresentam cenários específicos e detalhados para explicar o que os usuários realizarão com um novo recurso). Os backlogs do produto também podem incluir requisitos de mercado, especificações, casos de uso e outros itens.
O proprietário do produto prioriza itens de backlog de acordo com o valor comercial que cada item representa. Em geral, 80% do valor de um produto está em 20% de suas características. Atribuir um valor comercial para priorizar itens de backlog do produto garante que os recursos mais valiosos sejam construídos primeiro. Os itens na parte superior do backlog do produto são bem definidos e incluídos em um próximo Sprint; outros itens precisam ser refinados durante uma reunião de refinamento do backlog do produto.
Alguns proprietários de produtos e equipes de desenvolvimento realizam uma reunião de refinamento de backlog de produto perto do meio ou fim do Sprint atual para refinar ainda mais os itens de backlog do produto para sprints futuros. Outras equipes Scrum tratam o refinamento como um processo contínuo.
Executando Sprints Eficazes: As duas etapas a seguir serão concluídas para ajudar as equipes a executar Sprints eficazes. Um Sprint (às vezes chamado de iteração de comprimento fixo) é o período em que as equipes concluirão uma única iteração de trabalho antes de se reunirem e se prepararem para a próxima, e é um componente importante do gerenciamento de projetos Ágil.
- Planejamento sprint — O proprietário do produto, o Scrum Master e a equipe de desenvolvimento se reúnem durante uma sessão de planejamento de sprint para escolher itens de backlog do produto para o próximo Sprint e se comprometer com uma meta. Os membros da equipe de desenvolvimento selecionam itens na parte superior do backlog do produto até que tenham trabalho suficiente para preencher o prazo do Sprint. Os itens selecionados são movidos para um backlog de sprint.
- Backlog sprint e quadro Scrum — Todos os itens do backlog de sprint precisam ser concluídos até o final do Sprint. Para garantir um senso de responsabilidade compartilhada, os itens são colocados em uma das colunas, geralmente rotuladas como Tarefa pendente (To Do), Trabalho em andamento (Work In Progress, WIP) e Concluído (Done), em um quadro de tarefas Scrum físico ou digital. O quadro Scrum deve ser visível para toda a equipe, e os itens associados (muitas vezes escritos em notas autoadesivas como tarefas ou histórias de usuário) devem refletir o status do Sprint em tempo real. Seguir esta diretriz permite que a equipe faça ajustes se um determinado item estiver atrasado.
Sprint – Sprints duram de uma a quatro semanas. Cada sprint representa um breve ciclo de desenvolvimento e resulta em um incremento de produto (oficialmente conhecido como incremento de produto potencialmente transportável) ou no produto acabado. As equipes nem sempre são capazes de completar um incremento de produto que é transportável, especialmente no início; no entanto, isso é algo pelo qual a equipe deve se esforçar à medida que melhora ao longo do tempo.
Daily Scrum – Durante cada Sprint, os membros da equipe de desenvolvimento participam de reuniões rápidas diárias conhecidas como Daily Scrum. A duração máxima da reunião é de 15 minutos porque os participantes compartilham apenas suas respostas a três perguntas básicas: 1) O que foi realizado desde a última reunião?, 2) O que será feito antes da próxima reunião?, e 3) Quais obstáculos estão no caminho?
O objetivo desta reunião é dar à equipe de desenvolvimento a oportunidade de coordenar esforços, sincronizar o trabalho e relatar impedimentos (problemas técnicos, obstáculos do departamento, etc.). Este não é o tipo de reunião em que os funcionários dão ao seu gerente um relatório de progresso. O Scrum Master pode comparecer para descobrir quais obstáculos ele ou ela precisa resolver, mas o proprietário do produto geralmente não comparece.
Reunião Scrum de Scrums — Uma declaração em destaque do instrutor de Scrum Mike Cohn no site da Scrum Alliance descreve a reunião Scrum de Scrums como "uma técnica importante na colocação em escala do Scrum para equipes grandes de projeto. Essas reuniões permitem que conjuntos de equipes discutam seu trabalho, focando especialmente em áreas de sobreposição e integração. Imagine um projeto perfeitamente equilibrado composto por sete equipes, cada uma com sete membros. Cada uma das sete equipes realizaria (simultaneamente ou sequencialmente) sua própria reunião diária de Scrum. Cada equipe então designaria uma pessoa para também participar de uma reunião Scrum de Scrums".
Nas reuniões Scrum de Scrums que Schnase facilitou, os participantes incluíram Scrum Masters, proprietários de produtos, líderes técnicos, bem como alguns gerentes de QA, patrocinadores do programa e gerentes de departamento que estavam diretamente conectados aos projetos em que as equipes Scrum estavam trabalhando. "A cada duas semanas, teríamos um Scrum de Scrums para discutir realizações, marcos, progresso, dependências e obstáculos", diz Schnase.
Revisão de sprint – No final de cada sprint, a equipe realiza uma revisão de sprint (também conhecida como revisão de iteração ou demonstração de sprint) para demonstrar a funcionalidade do produto criado durante o sprint às partes interessadas, os indivíduos diretamente afetados pelo resultado do produto. As avaliações de sprint, ou demonstrações de sprint, também são uma oportunidade valiosa para demonstrar o produto para as pessoas que usam o software e podem fornecer feedback imediato.
Retrospectiva de sprint — Após a revisão do sprint, a equipe Scrum participa de uma reunião retrospectiva para discutir os sucessos e deficiências do sprint e fazer planos para melhorias. Outro objetivo da retrospectiva é desenvolver ainda mais o processo e as práticas que a equipe Scrum usa e torná-lo mais eficaz para o próximo sprint.
A equipe também encontra maneiras de aumentar a qualidade do produto e, se apropriado, modificar itens de acordo com a definição de feito. “The Basics of Scrum (O Básico do Scrum)” da Scrum Inc. define a definição de feito: "Um item no backlog está pronto se for independente, acionável, foi atribuído um valor de ponto e tem uma definição clara dos critérios que significa que está feito. Isso, por sua vez, é chamado de definição de feito, o que garante que todos saibam exatamente o que se espera de um item quando ele é entregue".
Modelo de desenvolvimento da equipe Scrum
Para construir uma equipe Scrum eficaz, Schnase diz que é importante que todos tenham paixão e uma atitude positiva em relação ao processo para que os membros da equipe trabalhem bem juntos. Vários recursos do Scrum mencionam o modelo de desenvolvimento em grupo de Bruce Tuckman como um método eficaz a ser seguido ao construir uma equipe Scrum ou adicionar novas pessoas à equipe. O artigo de Tuckman, "Developmental sequence in small groups", publicado no Psychological Bulletin em 1965, afirma que novas equipes precisam passar por várias etapas antes de atingir um nível de alto desempenho e entregar resultados ideais. Tuckman rotulou esses estágios como: Forming (Formação), Storming (Confrontamento), Norming (Normatização) e Performing (Performance).
O nome de cada estágio dentro do modelo de desenvolvimento de grupo de Tuckman reflete com precisão a dinâmica da equipe durante esse período específico.
Forming – Tuckman se referiu a esta etapa como um foco na orientação, teste e dependência. Os membros da equipe ainda não se familiarizaram uns com os outros e ainda pensam em seu trabalho como atribuições individuais, em vez de um esforço colaborativo de toda a equipe como um todo. Sessões de construção de equipe e almoços em grupo geralmente ajudam o time a se tornar mais confortável.
Storming — No estágio Storming, os membros da equipe geralmente mantêm suas opiniões e resistem a vários aspectos da influência da equipe, razão pela qual conflitos intragrupos geralmente ocorrem. O estágio Storming é quando os membros da equipe são encorajados a aceitar que haverá diferenças dentro da equipe, mas a diversidade pode resultar em mais ideias e aumento da produtividade. Para passar para a próxima etapa, os membros da equipe precisam de segurança sobre seus requisitos de trabalho e demandas de tarefas. À medida que a confiança e a estabilidade são estabelecidas, a resolução de conflitos fica mais fácil.
Norming – Quando a equipe chega ao estágio Norming, os membros estabeleceram áreas de acordo e chegaram a um consenso. Diretrizes claras foram estabelecidas sobre funções individuais, resultando em uma nova abertura e coesão entre os membros. O objetivo nesta fase é trabalhar em conjunto para desenvolver padrões de grupo e discutir ideias e interpretações relevantes.
Performing – Dentro do estágio Performing, o grupo tem uma visão unificada, energia coletiva e senso de propósito. A equipe aprendeu a ter um bom desempenho juntos e resolver demandas de forma positiva e diplomática. De acordo com Tuckman, as funções se tornaram flexíveis e funcionais, e a estrutura da equipe fica capacitada para um nível mais alto de desempenho.
Schnase recomendou levar em conta o modelo de Tuckman quando as pessoas são adicionadas a uma equipe Scrum porque um novo membro muda a dinâmica da equipe. Cada vez que a equipe muda, ela diz que passará pelas etapas de Forming, Storming, Norming e Performing. "A velocidade vai diminuir quando você adicionar um novo membro na equipe, então você deve levar isso em consideração."
Schnase também apontou outra razão pela qual é eficaz realizar retrospectivas sprint. "As retrospectivas são importantes porque a equipe precisa refletir sobre os pontos positivos e quais itens eles poderiam melhorar potencialmente. Isso ajuda a equipe a avançar para o estágio de Desempenho."
Construção inicial da equipe Scrum
Como na maioria dos modelos de desenvolvimento, leva tempo para alcançar resultados. O mesmo acontece com as equipes Scrum. Uma nova equipe não vai gerar resultados superiores imediatamente. O tempo que leva até que uma equipe chegue ao estágio de performance depende dos indivíduos e outros fatores, incluindo a unidade da equipe, e é por isso que a construção de equipes é imprescindível.
"A construção inicial da equipe é benéfica para estabelecer confiança e para que todos na equipe reconheçam os pontos fortes dos outros membros da equipe", diz Schnase. "Leva tempo para crescer como uma equipe."
A chave para a construção de equipes é encontrar algo que será interessante e divertido para todos, e abandonar os exercícios estranhos de construção de equipe que ninguém gosta de participar. Prepare uma lista de atividades potenciais em equipe e pergunte aos membros quais eles desfrutariam e peça sugestões adicionais. Você pode considerar uma excursão para criar laços fora do escritório, como uma viagem a um museu ou um jogo esportivo local, uma oportunidade de voluntariado em grupo ou um simples almoço em equipe para promover um ambiente coletivo forte. Além disso, participar de um workshop de treinamento Scrum juntos — especialmente um que inclui sessões abertas — o ajudará a analisar os pontos fortes individuais que beneficiarão a equipe em geral.
Equipes Scrum remotas x colocalizadas
A construção de equipes já é difícil quando os membros estão localizados em cidades diferentes, ainda mais em países diferentes. Schnase trabalhou com membros da equipe Scrum de todo o mundo. Embora alguns especialistas recomendem construir apenas equipes colocalizadas porque muitas vezes é mais fácil desenvolver coesão e confiança enquanto trabalham juntos em um único local, Schnase disse que esse tipo de arranjo nem sempre é viável.
As funções de Schnase na IGT, por exemplo, envolviam trabalhar com membros da equipe Scrum da Austrália e da China, bem como várias cidades nos Estados Unidos. Ela diz que, embora as diferenças de fuso horário possam ser desafiadoras, especialmente para a organização de reuniões em grupo, é possível fazer a situação funcionar.
Nessas situações, o processo de construção de equipe pode precisar ser realizado on-line usando uma ferramenta de videoconferência. Algumas empresas entendem o benefício de inicialmente reunir os membros e pagam para que a equipe se encontre em um local central para treinamento ou outras finalidades de construção de equipe. Se este for o caso com seu empregador, você pode querer perguntar aos membros da equipe Scrum se eles apoiariam a ideia de se encontrarem em uma conferência de treinamento Scrum, por exemplo. Se todos aprovarem, sugira a opção ao seu empregador.
Funções, responsabilidades e características preferenciais da equipe Scrum
Os primeiros desenvolvedores do Scrum vislumbraram as funções da equipe Scrum dentro de uma estrutura de auto-organização semelhante à que as equipes de rugby usam à medida que passam uma bola para frente e para trás, avançando no campo como uma unidade coesa. A estrutura de equipe Scrum é agora um modelo comprovado para as equipes de desenvolvimento de produtos seguirem, alcançando resultados contínuos, coordenados e confiáveis.
Uma equipe Scrum bem equilibrada inclui:
- um Proprietário de produto que promove a visão do produto e prioriza o backlog dele para maximizar sua funcionalidade e valor para o cliente;
- um Scrum Master que treina efetivamente a equipe de desenvolvimento, facilita eventos e elimina distrações que interferem no progresso da equipe;
- e os membros da equipe de desenvolvimento que permanecem focados em concluir os entregáveis em incrementos (funcionalidade concluída do produto no final de cada sprint) e produzir um produto final superior.
Sutherland e Schwaber enfatizam que existem funções específicas no Scrum por uma razão, e que a combinação dessas funções muitas vezes causará uma diminuição da produtividade. Os empregadores também devem reconhecer que as equipes são muito mais produtivas e estáveis quando seus membros estão focados apenas em um produto por Sprint e não são obrigados a trabalhar em vários produtos ou com outras equipes.
Nas seções a seguir, revisamos as responsabilidades e características preferenciais associadas a cada função para facilitar a avaliação dos candidatos pelos gerentes de contratação adequadamente.
Função do proprietário do produto
O Scrum Guide descreve a função Proprietário do produto como sendo responsável por "maximizar o valor do produto e o trabalho da equipe de desenvolvimento". Em outras palavras, o proprietário do produto é responsável por entregar um produto de alta qualidade que maximiza o retorno do investimento (ROI) da organização. As outras responsabilidades principais estão relacionadas à compreensão e explicação das expectativas do cliente para um produto, bem como ao gerenciamento do backlog, uma lista priorizada de recursos do produto.
Schnase diz que o proprietário do produto deve ter o tipo de personalidade que pode "oferecer à equipe requisitos e objetivos de alto nível para o produto, mas permitindo que a equipe determine como alcançar esses objetivos".
Os proprietários de produtos geralmente têm experiência em gerenciamento de produtos ou projetos, marketing ou experiência do usuário (UX). Eles geralmente têm um histórico envolvendo análises das expectativas dos clientes, produtos competitivos, demandas de mercado e tendências futuras para o tipo de produto em desenvolvimento. As credenciais acadêmicas variam de acordo com o tipo de produto, negócios e indústria. Mais importante, o proprietário do produto precisa ter uma visão forte e conexão com o produto.
A lista a seguir representa as responsabilidades que a descrição de trabalho do proprietário do produto deve cobrir para alcançar o sucesso dentro desta função.
- Desenvolve a visão do produto e enfatiza as expectativas do cliente — O proprietário do produto deve ser alguém que pode avaliar informações de várias fontes, desenvolver uma visão do produto e promover essa visão. O proprietário do produto deve poder apresentar mensagens importantes sobre o produto que ressoará com a equipe Scrum, as partes interessadas e outras pessoas em toda a organização. É especialmente importante que o proprietário do produto represente o ponto de vista do cliente ao explicar o produto e como seus recursos novos ou aprimorados vão exceder as expectativas.
- Considera o lado comercial do desenvolvimento de produtos – Os proprietários de produtos devem ser experientes em negócios, entender as necessidades corporativas que englobam o desenvolvimento de produtos e reconhecer a importância do tempo, das condições positivas do mercado, e das decisões baseadas em preocupações orçamentárias e no ROI. Os proprietários de produtos também devem ser estratégicos ao desenvolver planos de lançamento e promover o produto em vários níveis, seja para o mercado, para a alta gestão ou para a equipe Scrum.
- Motiva a equipe com objetivos claros e inspiradores – O proprietário de um produto precisa discutir os requisitos e objetivos de alto nível de cada projeto com a equipe de desenvolvimento, responder a todas as perguntas e deixar a equipe decidir como atender a essas expectativas. O proprietário do produto é responsável por priorizar o backlog, mas os membros da equipe de desenvolvimento são os que decidem quanto trabalho podem concluir durante cada Sprint e quantos Sprints serão necessários. Portanto, o proprietário do produto deve ter o tipo de personalidade que motiva os membros da equipe sem tentar controlá-los.
- Maximiza o valor do produto e o progresso da equipe de desenvolvimento — Essa responsabilidade completa enfatiza como é essencial para o proprietário do produto identificar de forma correta quais recursos do produto são atualmente os mais importantes e pertencem ao topo da lista priorizada para o próximo Sprint. Para fazer isso bem durante todo o processo de desenvolvimento, o proprietário do produto precisa refinar e repriorizar continuamente os itens de backlog. Itens de backlog, ou mais especificamente, recursos e histórias de usuários devem ser priorizados de acordo com o valor que cada um traz para o produto. Alguns especialistas dão um passo adiante e dizem que o valor é determinado pela troca de maior valor comercial pelos itens de menor custo; no entanto, às vezes é necessário satisfazer clientes-chave e analisar outros fatores de estratégia de negócios.
- Prioriza e gerencia o backlog do produto — Como o único responsável pelo backlog do produto, os proprietários de produtos experientes reconhecem dependências que precisam ser consideradas e avaliadas adequadamente. Os proprietários de produtos mais eficazes entendem a necessidade de ser seletivos quando alguém se aproxima deles para solicitar uma mudança ou outro novo recurso. Eles sabem que não podem dar sua aprovação a tudo e ainda manter os outros aspectos do desenvolvimento do produto alinhados com o valor do negócio e as expectativas realistas. Saber quando dizer "não" é uma parte importante do trabalho.
- Refina o backlog do produto regularmente – Para garantir que toda a equipe entenda cada recurso listado no backlog do produto, o proprietário do produto esclarece as descrições, explica seu nível de importância e pergunta à equipe se eles têm alguma pergunta sem resposta. Esses detalhes também ajudam a garantir o compromisso da equipe com um produto de alta qualidade que corresponda às expectativas do cliente. Alguns proprietários de produtos pedem aos membros da equipe de desenvolvimento que adicionem especificações técnicas e outros detalhes semelhantes ao backlog do produto, mas o tempo que os desenvolvedores gastam com essas tarefas deve ser mantido ao mínimo.
- Apresenta histórias de usuários que se concentram na funcionalidade do produto — A equipe de desenvolvimento é responsável pelo backlog de sprint determinado durante a reunião de planejamento de sprint, mas o proprietário do produto é responsável pelas histórias do usuário, que são descrições de recursos contadas na perspectiva do usuário. Alguns proprietários de produtos criam a maioria das histórias de usuários, outros envolvem toda a equipe no processo.
- Permanece engajado com a equipe e continuamente disponível — Mostrar o compromisso de entregar o melhor produto possível envolve estar ativamente engajado com sua equipe. Os proprietários de produtos enfatizam sua disponibilidade para a equipe e usam suas habilidades de comunicação para desenvolver relacionamentos fortes.
- Aumenta o conhecimento por meio da rede — Os proprietários de produtos devem saber por que é necessário fazer networking com outras pessoas do setor participando periodicamente de conferências e workshops. Essa é uma ótima maneira de adquirir conhecimento ouvindo o que os outros têm a dizer sobre técnicas de modelagem de negócios, lições aprendidas, histórias de sucesso de produtos e muito mais.
Função do Scrum Master
O Scrum Master é o principal responsável por garantir que a equipe Scrum entenda e siga as práticas e regras do Scrum. Junto com essa responsabilidade, o Scrum Master garante que outras pessoas dentro da organização respeitem a teoria Scrum o suficiente para limitar a quantidade de distrações que colocam sobre a equipe Scrum e aceita feedback sobre quaisquer interações que interfiram no progresso da equipe.
Como treinador de equipe e facilitador de projetos complexos, o Scrum Master fornece valor eliminando o maior número possível de obstáculos para manter a equipe de desenvolvimento focada em seus objetivos. Schnase disse que Scrum Masters devem ajudar a equipe removendo obstáculos e impedimentos quando necessário. "Se alguém não consegue entrar em uma pasta de rede de que precisa ou o ambiente de teste está inativo, os Scrum Masters podem ajudar a escalar e resolver esses problemas", diz Schnase. "Os Scrum Masters precisam ser capazes de se comunicarem com qualquer parte interessada, além de serem assertivos e entusiasmados."
Um Scrum Master vem de várias origens e disciplinas acadêmicas, incluindo design, engenharia, TI, marketing, gerenciamento de produtos ou projetos, garantia de qualidade e testes. Eles têm qualidades como humildade, perseverança e lealdade, juntamente com uma ampla base de conhecimento e fortes habilidades de liderança que lhes permitem ser excelentes facilitadores e negociadores que sabem como resolver conflitos. Scrum Masters também devem permanecer comprometidos com o Scrum, independentemente da pressão que recebem de outras fontes.
Para ter um desempenho contínuo em alto nível, os Scrum Masters devem enfrentar múltiplas responsabilidades e possuir vários traços pessoais, como demonstrado pela lista detalhada abaixo.
- Cumpre o papel de ser um empregado/líder — Um verdadeiro empregado/líder sabe que o foco deve ser garantir que a equipe tenha o que precisa para entregar resultados ao cliente de uma maneira que atenda aos objetivos comerciais da empresa. A este respeito, o Scrum Master atende várias entidades simultaneamente: os membros da equipe, o cliente e a empresa. De acordo com o Scrum Guide, a função do Scrum Master envolve responsabilidades específicas no serviço ao Proprietário do produto, à equipe de desenvolvimento e à organização. O Scrum Master lidera pelo exemplo e é o tipo de pessoa que outros membros da equipe querem seguir. Um Scrum Master inspirador incentiva outros a acreditar em suas habilidades e trabalhar em seu potencial, mesmo quando as coisas não saem como planejado.
- Aceita a responsabilidade sem se sentir com direito a autoridade — Em seu post no blog intitulado, "Líder da Banda", Cohn explica a expectativa de responsabilidade sem poder: "Mesmo que um Scrum Master não assuma a responsabilidade pelo sucesso do projeto, que permanece com a equipe, ele assume a responsabilidade pela equipe ter adotado o Scrum e pela prática dele. Um Scrum Master assume essa responsabilidade sem assumir qualquer poder que possa ser útil para alcançá-la".
Em outro post, "Conselho para entrevistar Scrum Masters", Cohn esclareceu a expectativa afirmando: "Um maestro de orquestra uma vez explicou que não tem poder real sobre como os músicos individuais tocam. No entanto, ele sente uma tremenda responsabilidade em ajudá-los a serem os melhores músicos que podem ser".
- Resolve impedimentos e, se possível, os impede – o Scrum Master protege o trabalho da equipe de desenvolvimento resolvendo ou removendo impedimentos sempre que possível. Muitas vezes, os membros da equipe contam ao Scrum Master sobre um impedimento durante o Scrum diário e explicam por que o impedimento pode interferir em sua capacidade de concluir o trabalho durante um Sprint.
Em anúncios de empregos recentes, os gerentes de contratação mostraram uma preferência por Scrum Masters que têm amplo conhecimento técnico e/ou entendem completamente os detalhes de um determinado setor. Scrum Masters com esse tipo de conhecimento têm a vantagem de poder ajudar suas equipes a lidar com impedimentos que envolvem problemas técnicos mais rapidamente.
Alguns impedimentos escondidos sob a superfície são ameaças à eficácia geral da equipe, e é por isso que empregar um Scrum Master observador e engajado que pode eliminar tais ameaças é altamente desejável. Quanto mais experiente for um Scrum Master, mais fácil será para ele reconhecer uma dificuldade em potencial e resolvê-la antes que se torne um problema.
- Treina a equipe sobre como melhorar — um Scrum Master treina suas equipes fornecendo exemplos baseados em seus conhecimentos e experiências e orientando-os a aproveitar ao máximo seu potencial. Ao fazer isso, ele ajuda os membros da equipe a se entenderem melhor e implementar práticas envolvendo auto-organização e multifunção. Quando um Scrum Master incentiva o poder da auto-organização, as equipes aumentam a responsabilidade sobre seu trabalho, acham mais fácil tomar decisões e dar estimativas de trabalho e têm um senso mais forte de alcançar um propósito comum em conjunto.
Cohn compara treinar um Scrum Master com o tipo de ajuda que os personal trainers oferecem. "Pense na ajuda de um Scrum Master como semelhante a um personal trainer que o ajuda a manter uma rotina de exercícios e realizar todos eles da forma correta. Um bom treinador vai fornecer motivação e, ao mesmo tempo, garantir que você não trapaceie pulando um exercício difícil. A autoridade do treinador, no entanto, é limitada. O treinador não pode fazer um exercício que você não quer fazer. Em vez disso, o treinador lembra seus objetivos e como você escolheu enfrentá-los."
- Reconhece e resolve conflitos o mais rápido possível — Todos em uma equipe Scrum têm a liberdade de abordar atitudes improdutivas e comportamentos disfuncionais, mas às vezes o conflito surge de mal-entendidos ou necessidade de compromisso. Nesses casos, um Scrum Master deve reconhecer o conflito de equipe cedo o suficiente para resolvê-lo antes que seja necessário muito controle de danos. Scrum Masters também sabem que nem todos os conflitos são inevitáveis e nem sempre são uma coisa ruim. A capacidade de superar conflitos vai tornar a equipe mais forte.
Em seu post no blog intitulado "Conselho para entrevistar Scrum Masters", Cohn discute como a mentalidade colaborativa que um Scrum Master traz para o trabalho ajuda a resolver conflitos. "Um bom Scrum Master trabalha para garantir que uma cultura colaborativa exista dentro da equipe. O Scrum Master precisa garantir que os membros da equipe se sintam capazes de fazer perguntas para uma discussão aberta. Quando surgem conflitos, um Scrum Master colaborativo incentiva as equipes a pensar em soluções que beneficiam todos os envolvidos em vez de achar culpados".
- Facilita eventos Scrum – Os melhores Scrum Masters parecem saber instintivamente como facilitar eventos e orientar as pessoas. Na realidade, a maioria dos Scrum Masters recebe esse tipo de treinamento por meio de cursos de liderança e/ou anos de experiência. As pessoas presentes em eventos Scrum apreciam a preparação e capacidade de definir expectativas claras.
- Ouça e observe — Mais uma vez, o equilíbrio é crucial. Scrum Masters eficazes têm habilidades de comunicação excepcionais, mas também sabem quando simplesmente ouvir e observar. Com ouvir, queremos dizer escuta focada e ativa. Com observar, estamos nos referindo a observar o que não está sendo comunicado em voz alta, mas ainda é aparente ao observar de perto a linguagem corporal, expressões faciais e outras sugestões.
- Atua como educador e promotor do Scrum — Scrum Masters não apenas garantem que os membros da equipe Scrum entendam e sigam o Scrum, mas também garantem que outros funcionários conectados a suas equipes entendam o Scrum. Se as organizações estão adotando o Scrum pela primeira vez, Scrum Masters são os únicos que lideram esse esforço planejando a implementação do Scrum, sugerindo mudanças para aumentar a produtividade da equipe Scrum e prestando assistência durante um período de ajuste. Em grandes empresas, esse esforço às vezes envolve trabalhar com outros Scrum Masters para aumentar a eficácia do Scrum.
Ao ensinar os outros sobre o Scrum, pode se tornar necessário que o Scrum Master supere o ceticismo de algumas pessoas promovendo o valor do Scrum e como sua estrutura e princípios orientadores já geraram resultados significativos para outras empresas.
- Usa habilidades políticas corporativas para influenciar pessoas em toda a organização — Scrum Masters experientes sabem que podem ser capazes de mudar o comportamento das pessoas, dando-lhes uma razão para mudar suas ações ou influenciar as pessoas mudando a cultura e as condições em que devem operar, mas eles não podem mudar as pessoas de verdade. Esses Scrum Masters também sabem como usar a persuasão e a motivação para influenciar outros em vários níveis em uma organização porque eles entendem quem toma as grandes decisões, como eles podem capitalizar as alianças existentes e como fazer desvios em torno das pessoas mais propensas a jogar obstáculos em seu caminho.
Funções da equipe de desenvolvimento
As pessoas que criam o produto são conhecidas coletivamente como a equipe de desenvolvimento. Este grupo normalmente inclui profissionais que têm experiência e treinamento como desenvolvedores de software, designers de interface de usuário, especialistas em banco de dados, engenheiros de operações, engenheiros de garantia de qualidade, testadores, analistas de sistemas e escritores técnicos (especialistas em documentação). De acordo com o Scrum Guide, "o Scrum não reconhece nenhum título para membros da equipe de desenvolvimento além de Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; não há exceções a esta regra."
A principal função da equipe de desenvolvimento é executar o trabalho necessário para uma série bem-sucedida de Sprints e incrementos de produtos, seguido pela entrega de um produto final de alta qualidade. Se você está planejando contratar alguém para sua equipe de desenvolvimento Scrum, Schnase sugere procurar um profissional que esteja disposto a fornecer assistência de teste e executar outras funções como automação. "Todos os membros da equipe devem estar dispostos a treinar e ajudar uns aos outros."
"The Basics of Scrum", publicado pela Scrum Inc., também aborda a importância de ter uma equipe de desenvolvimento multifuncional. "Além disso, deve haver pelo menos duas pessoas na equipe que podem concluir qualquer item no backlog do produto. Isso ajuda a eliminar as dependências das habilidades de um membro específico da equipe no caso de o colega de trabalho adoecer, sair de férias ou mudar de emprego."
A lista a seguir inclui responsabilidades compartilhadas pela equipe de desenvolvimento, juntamente com as características desejáveis dos melhores executores da equipe.
- Oferece a funcionalidade e o nível de qualidade prometidos — Os funcionários mais adequados para o trabalho em equipe do Scrum são colaboradores e comunicadores que melhoram consistentemente em relação ao tempo que permanecem com uma equipe, são capazes de implementar recursos conforme planejado e entregar trabalho de alta qualidade. Por meio de suas ações, eles demonstram um forte compromisso com as metas e a capacidade de prosperar em um ambiente Scrum.
- Realmente se preocupa em lançar um produto final que os clientes apreciarão — Os membros da equipe mais valorizados são os que conhecem bem seus clientes e ficariam decepcionados consigo mesmos se não se esforçassem para exceder as expectativas do cliente. Esses funcionários têm orgulho de seu trabalho e ficam entusiasmados quando recebem feedback positivo dos clientes.
- Ajuda a equipe a se manter focada na conclusão — As equipes de desenvolvimento são responsáveis por todas as tarefas no backlog de sprint. Equipes de alto desempenho copiam essas tarefas em um quadro Scrum e frequentemente fazem atualizações para garantir que todos tenham uma referência visual de onde todas as tarefas estão em tempo real. As colunas do quadro Scrum devem indicar claramente quais tarefas estão concluídas e quanto progresso foi feito nos itens restantes. Os membros da equipe que seguem essas diretrizes vão eliminar a confusão e manter a equipe focada para seguir em frente.
- Usa Scrum diário e outras reuniões como ferramentas de comunicação — os membros da equipe conscientes sabem que seu tempo é precioso e limitado, e tratam o tempo de seus colegas de trabalho com o mesmo respeito. Eles usam diariamente o Scrum e outras reuniões conforme indicado e vêm preparados para se comunicar dentro do tempo permitido. Eles também mantêm suas outras comunicações com colegas de trabalho concisas e diretas.
- Faz compromissos realistas — Os gerentes de tempo eficazes percebem que uma certa quantidade de tempo de inatividade deve fazer parte do dia de todos. Todos nós precisamos de tempo para relaxar e recarregar, especialmente se quisermos promover a criatividade. Uma certa folga em nossos cronogramas é necessária para esses fins e para planejar adequadamente situações e emergências inesperadas. Desenvolvedores experientes sabem disso e estimam os prazos dos compromissos de acordo.
- Fornece ideias para sprints futuros — Todos apreciam um membro da equipe que toma a iniciativa de fornecer opções funcionais para itens não abordados que eles notam no backlog do produto. Embora o backlog faça parte da lista de responsabilidades do proprietário do produto, oferecer ideias sobre como refinar seu conteúdo é algo que toda a equipe pode fazer. Melhorar os itens de backlog inevitavelmente melhora os incrementos do produto e o produto final.
- Abraça oportunidades de treinamento cruzado e aprendizagem contínua — Os membros da equipe orientada ao crescimento são entusiasmados com oportunidades avançadas de aprendizagem porque entendem a importância da inovação e se adaptam continuamente a um ambiente técnico em rápida evolução. Eles estão abertos a mudanças e dispostos a treinar e se envolver em situações colaborativas. Eles também estão dispostos a compartilhar suas experiências com outros funcionários e servir como mentores para novos membros da equipe.
- Combina experiência técnica com conhecimento de negócios – Membros da equipe de desenvolvimento que entendem os conceitos de negócios quase tanto quanto entendem que a tecnologia é valiosa em várias frentes. Eles não só podem explicar a tecnologia ao pessoal da empresa, como também podem informá-los sobre as consequências do lançamento de um produto que se concentra muito no marketing e não nos fatores técnicos subjacentes.
Por exemplo, adicionar muitos recursos pesa sobre o desempenho geral do produto. Esses desenvolvedores informarão o proprietário do produto sobre suas preocupações o mais rápido possível. Esses desenvolvedores são ativos valorizados porque podem explicar suas preocupações em termos comerciais que o Proprietário do produto vai entender, indicará que estão dispostos a trabalhar em possíveis soluções e mostrarão que entendem como aspectos técnicos como o desempenho podem afetar o valor de mercado de um produto.
- Impõe uma política de não interferência para a equipe — Outras pessoas em uma empresa podem ser tentadas a empurrar suas próprias demandas para uma equipe de desenvolvimento, e é provavelmente por isso que o Scrum Guide achou necessário incluir uma declaração para abordar essa tendência: "Ninguém pode dizer à equipe de desenvolvimento para trabalhar com um conjunto diferente de requisitos, e a equipe de desenvolvimento não tem permissão para agir com base no que qualquer outra pessoa diz."
Dicas gerais de contratação para todas as funções da equipe Scrum
Agora que cobrimos as especificidades, vamos rever uma lista geral de qualidades que os especialistas em Scrum dizem que procurariam em outros membros da equipe.
- Admite erros e aprende com eles — Embora todos cometam erros, é importante que os funcionários aprendam com esses erros e melhorem como resultado. Antes de contratar ou convidar alguém para se juntar à sua equipe Scrum, aprenda a reconhecer quais candidatos não admitirão que cometem erros — isso pode ser um indicador de traços mais preocupantes, como não ser responsável. As equipes trabalham juntas em inúmeros detalhes, por isso é vital que você adicione um candidato que pode fazer uma transição suave para uma função da equipe sem mostrar uma tendência de encontrar culpados.
- Feedback de valores – Os membros de equipe conscientes sabem como dar e receber feedback de forma clara, direta e respeitosa. Eles também sabem que o feedback deve ser útil e edificante. Sempre que possível, esses membros da equipe procuram maneiras de fornecer seu feedback em particular. A confiança também é uma parte importante da equação. Colegas de equipe que confiam uns nos outros trabalham melhor juntos. Avaliar adequadamente como os candidatos se sentem sobre feedback e confiança revela muito sobre seu caráter.
- Traz humor, energia e diversão para o trabalho — Tornar-se parte de uma equipe e sentir-se conectado aos outros requer um investimento pessoal de todos. Funcionários que mostram sua personalidade pelo humor, energia e atividades divertidas geralmente se conectam com as outras pessoas mais rapidamente. Nem sempre é fácil avaliar essas qualidades durante entrevistas de trabalho, mas fazer perguntas gerais sobre seus interesses e hobbies favoritos, viagens e atividades de fim de semana pode revelar algumas pistas sobre o quão bem o candidato se encaixaria em uma equipe Scrum específica.
Ferramentas Scrum comerciais
A responsabilidade coletiva é uma parte importante do Scrum. Para melhorar como uma equipe, há valor no acompanhamento do desempenho e do progresso usando uma variedade de ferramentas.
- Quadro Scrum – Existem vários tipos de quadros de tarefas, mas o modelo mais comum usado no Scrum é o quadro Scrum mencionado anteriormente neste artigo. Como descrevemos, o quadro Scrum inclui colunas geralmente rotuladas como Tarefa pendente, Trabalho em andamento e Concluído. Cada uma das tarefas do backlog de sprint são escritas em notas autoadesivas e colocadas dentro de uma dessas colunas para ajudar a equipe Scrum a determinar quanto trabalho ainda deve ser concluído antes do final do Sprint.
Os quadros Scrum também podem ser usados para acompanhar o resultado da equipe com uma métrica conhecida como velocidade. Para medir a velocidade, a equipe atribui um valor de ponto relativo a cada tarefa a partir do backlog de sprint. Quando o Sprint terminar, a equipe pode adicionar pontos na coluna Concluído e calcular a velocidade total da equipe para aquele Sprint em particular. Usar este método ajuda as equipes a criar uma linha de base para o desempenho da equipe e prever com quanto trabalho ela pode lidar em Sprints futuros.
As equipes também podem usar painéis Scrum e velocidade para prever a data de conclusão de um projeto ou analisar se um ajuste no fluxo de trabalho realmente ajudou a equipe a melhorar sua taxa de desempenho. Para obter mais informações, consulte o curso de Scrum Board na Scrum Inc.
- Gráfico de Burndown — No curso da conclusão de um Sprint, as equipes podem querer usar um gráfico de burndown de sprint diário para mostrar a quantidade restante de trabalho restante no backlog de sprint. O trabalho restante é monitorado no eixo vertical e o tempo (de acordo com os dias dentro de um Sprint) é monitorado no eixo horizontal. Esse tipo de representação visual pode ajudar as equipes a medir o progresso e garantir que elas estejam no caminho certo para a data de conclusão esperada. Gráficos burndown também podem ser úteis para acompanhar tendências e trabalho durante o cronograma de lançamento de um produto. Para obter mais informações sobre como criar um gráfico de burndown, consulte o curso Sprint Burndown Chart na Scrum Inc.
- Matriz RACI — Como toda equipe sabe, há momentos em que a prestação de contas individual é necessária. Nesses casos, ajuda ter uma ferramenta como a matriz RACI (responsável, autoridade, consultado, informado) disponível para dividir tarefas e produtos em um gráfico de funções e responsabilidades organizado. Para obter mais detalhes sobre esta ferramenta, consulte "A Comprehensive Project Management Guide for Everything RACI".
Use o Smartsheet para gerenciar facilmente projetos Scrum
Do gerenciamento de tarefas simples e planejamento de projetos à gestão de portfólio e recursos complexos, o Smartsheet ajuda a melhorar a colaboração e acelerar a velocidade do trabalho — aumentando sua produtividade. Com a plataforma Smartsheet fica fácil planejar, coletar informações, gerenciar e criar relatórios sobre o trabalho de qualquer lugar, ajudando sua equipe a ser mais eficiente e mostrar resultados. Crie relatórios sobre as principais métricas e obtenha visibilidade do trabalho em tempo real, à medida que ele acontece, através de relatórios, painéis e fluxos de trabalho automatizados criados para manter sua equipe conectada e informada. Quando as equipes têm clareza sobre o trabalho que está sendo realizado, elas podem ser muito mais produtivas durante o mesmo período. Experimente o Smartsheet gratuitamente hoje mesmo.