Um dos principais componentes de uma Scrum Team produtiva é o equilíbrio: equilíbrio de habilidades, equilíbrio de personalidades, equilíbrio de responsabilidades, equilíbrio de cargas de trabalho e equilíbrio de poder. Dezenas de fatores vão para a implementação do Scrum dentro de uma empresa e a construção de uma Scrum Team de alto desempenho a partir do zero, mas o equilíbrio é a qualidade que permeia tudo.
Uma abordagem equilibrada é crucial para muitas áreas de negócios, mas especialmente para o desenvolvimento de produtos de sucesso. Onde quer que o Scrum seja aplicado, no entanto, ter um coletivo equilibrado de pontos fortes e características pessoais entre os membros da equipe é um modelo de equipe comprovado. Reconhecer os principais traços e saber como construir e manter uma equipe equilibrada é especialmente importante quando você está encarregado de contratar candidatos para uma Scrum Team. Este artigo tem os detalhes que você precisa para tomar decisões informadas ao construir uma Scrum Team. Ofereceremos conselhos sobre desenvolvimento de equipe, forneceremos sugestões para atividades de formação de equipe e explicaremos que tipos de candidatos são mais adequados para funções e responsabilidades específicas.
Trabalho Scrum Team condenado
A base para o Scrum, o framework de gerenciamento ágil mais popular, começou com um artigo de 1986 da Harvard Business Review escrito por Hirotaka Takeuchi e Ikujiro Nonaka. No artigo, Takeuchi e Nonaka apresentaram o termo “Scrum”, destacando as estratégias de trabalho em equipe que as equipes 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 quando as equipes receberam objetivos, mas permitiram determinar como atingir esses objetivos por conta própria.
Ken Schwaber e Jeff Sutherland desenvolveram a estrutura do Scrum e formalizaram os papéis dos membros da Scrum Team nos anos 90. Em 1995, eles publicaram um artigo intitulado “SCRUM Software Development Process”. Depois de gradualmente fazer outros aprimoramentos no Scrum e publicar artigos adicionais, Schwaber e Sutherland completaram a primeira publicação do Guia do Scrum em 2010.
O Scrum Guide se refere ao Scrum e sua equipe os papéis como uma “estrutura dentro da qual as pessoas podem lidar com problemas adaptativos complexos, enquanto produzem de forma produtiva e criativa produtos do mais alto valor possível. O framework Scrum consiste em Scrum Teams e suas funções associadas, eventos, artefatos e regras. ”
Descrições no Guia do Scrum sobre os papéis da equipe afirmam que “o Time Scrum consiste de um Dono do Produto, a equipe de desenvolvimento e um Scrum Master. As equipes do Scrum são auto-organizadas e interfuncionais. Equipes auto-organizadas escolhem a melhor forma 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 outros que não fazem parte da equipe. O modelo Scrum Team foi desenvolvido para otimizar a flexibilidade, a criatividade e a produtividade. As Scrum Team oferecem produtos de forma iterativa e incremental, maximizando as oportunidades de feedback. ”
Recomendações de tamanho Scrum Team
Para alcançar a Scrum Team mais coesa e maximizar o nível de trabalho em equipe dentro do grupo, os especialistas geralmente oferecem conselhos sobre o tamanho da equipe. Schwaber, que fornece treinamento Scrum através de sua organização Scrum.org, dá recomendações de tamanho de equipe em seu livro de 2007, The Enterprise and Scrum. Schwaber explica que as Scrum Teams devem ser “limitadas em tamanho para maximizar a velocidade, o conteúdo, a precisão e a 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 de sete possíveis. Sete mentes parecem capazes de alcançar e manter um modelo mental compartilhado de um sistema e sua representação no design e no código sem recursos artificiais, como documentação. Desentendimentos e tempo de gravação são minimizados. ”
Mindi Schnase, gerente de projeto da Renown Health, tem 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), a empregadora anterior da Schnase, ela trabalhou como engenheira líder de garantia de qualidade antes de fazer a transição para o cargo de Scrum Master. A experiência da Schnase envolveu o trabalho em Scrum Teams de tamanhos variados.
A Schnase informa que de sete a nove pessoas por equipe é um tamanho bom e administrável, mas ela também explica que o tamanho da equipe é influenciado pelas especificidades do projeto. “Isso realmente depende do escopo do projeto. Eu era um Scrum Master para várias equipes; um deles tinha três membros, outros sete a 10. ”
Sutherland, que continua a ministrar cursos Scrum através de sua organização Scrum Inc, incluiu muitas informações sobre a dinâmica de equipe no site de sua organização, incluindo a análise do tamanho das equipes e produtividade. :
“Lawrence Putnam, uma figura lendária no desenvolvimento de software, fez do trabalho de sua vida estudar quanto tempo as coisas demoram a fazer e por quê. Seu trabalho mostrava que projetos com vinte ou mais pessoas usavam mais esforço do que aqueles com cinco ou menos. Não só um pouquinho, mas muito. Então ele olhou para 491 projetos de tamanho médio em centenas de empresas diferentes. Todos esses projetos exigiam a criação de novos produtos ou recursos, e não o reaproveitamento de versões antigas. Ele dividiu os projetos pelo tamanho da equipe e percebeu algo imediatamente. Quando as equipes cresceram acima de oito, demoraram dramaticamente para fazer as coisas. Grupos compostos por três a sete pessoas precisaram de cerca de 25% do esforço de grupos de nove a vinte para conseguir a mesma quantidade de trabalho".
Parece dos especialistas que sete membros da 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 Scrum Teams mais eficazes
Equipes de todas as formas e tamanhos participam de um fluxo de trabalho específico quando tomam a decisão de seguir o Scrum como parte do gerenciamento de projetos Agile. Os eventos Scrum têm um propósito valioso: eles encorajam 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 os eventos Scrum em suas agendas, 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 Scrum Team usam para o desenvolvimento de produtos.
Visão do produto - O Product Owner resume a visão do produto em uma declaração depois de 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 de negócios sobre as metas do produto e como o produto se encaixa nas estratégias da empresa.
Backlog e refinamento de produtos - Os itens do backlog de produtos representam tudo que pode ser entregue para um projeto de forma independente. A maioria desses itens se concentra na entrega de valor aos clientes, assim como os recursos de produtos e as histórias de usuários. (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 pedidos pendentes de produtos também podem incluir requisitos de mercado, especificações, casos de uso e outros itens.
O Product Owner prioriza os itens de backlog do produto de acordo com o valor de negócio que cada item representa. Em geral, 80% do valor de um produto está em 20% de seus recursos. Atribuir um valor comercial para priorizar os itens de backlog do produto garante que os recursos mais valiosos sejam criados primeiro. Os itens no topo 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 de backlog de produto.
Alguns proprietários de produtos e equipes de desenvolvimento mantêm uma reunião de refinamento de backlog de produto perto do meio ou no final do Sprint atual para refinar ainda mais os itens de lista de pendências de produtos para futuros Sprints. Outras Scrum Teams tratam o refinamento como um processo contínuo.
Correndo Sprints Eficazes: As duas etapas a seguir serão concluídas para ajudar as equipes a executarem Sprints eficazes. Uma Sprint (às vezes chamada de uma iteração de tamanho fixo) é o período de tempo em que as equipes completam uma única iteração de trabalho antes de se reconectar e se preparar para a próxima.
- Planejamento de sprint - O Product Owner, o Scrum Master e a equipe de desenvolvimento se encontram durante uma sessão de planejamento de sprint para escolher itens de backlog do produto para o próximo Sprint e se comprometer com um objetivo. Os membros da equipe de desenvolvimento selecionam itens na parte superior do backlog do produto até que tenham trabalho suficiente para preencher o prazo da Sprint. Os itens selecionados são movidos para um backlog de sprint.
- Backlog da sprint e quadro Scrum - Todos os itens no backlog da sprint devem 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 To Do, Work In Progress (WIP) e Done - em um quadro Scrum físico ou digital (quadro de tarefas). O Scrum Board deve estar visível para toda a equipe, e os itens associados (geralmente escritos em notas como tarefas ou histórias de usuários) devem refletir o status da Sprint em tempo real. Seguir esta diretriz permite que a equipe faça ajustes se um item em particular 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 Shippable) ou no produto acabado. As equipes nem sempre conseguem concluir um incremento de produto que é permitido, especialmente no começo, no entanto, isso é algo que a equipe deve se esforçar ao melhorar ao longo do tempo.
Daily Scrum - Durante cada Sprint, os membros da equipe de desenvolvimento participam de reuniões diárias, conhecidas como Daily Scrum. A duração máxima da reunião é de 15 minutos, porque os participantes só compartilham 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 uma oportunidade de coordenar esforços, sincronizar o trabalho e relatar impedimentos (problemas técnicos, bloqueios de departamentos, etc.). Esse não é o tipo de reunião em que os funcionários fornecem ao gerente um relatório de progresso. O Scrum Master pode participar para descobrir quais obstáculos ele ou ela precisa resolver, mas o Product Owner geralmente não comparece.
Reunião do Scrum of Scrums - Uma declaração do instrutor do Scrum Mike Cohn. O site Scrum Alliance descreve o encontro do Scrum of Scrums como “uma importante técnica para escalar o Scrum para grandes equipes de projeto. Essas reuniões permitem que grupos de equipes discutam seu trabalho, concentrando-se especialmente em áreas de sobreposição e integração. Imagine um projeto perfeitamente equilibrado, composto por sete equipes, cada uma com sete membros da equipe. Cada uma das sete equipes conduziria (simultaneamente ou sequencialmente) sua própria reunião diária de scrum. Cada equipe designaria uma pessoa para participar de uma reunião do Scrum de Scrums. ”
Nas reuniões do Scrum of Scrums facilitadas pela Schnase, os participantes incluíram Scrum Masters, Product Owners, líderes técnicos, bem como alguns gerentes de QA, patrocinadores de programas 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 of Scrum para discutir conquistas, marcos, progresso, dependências e bloqueios de estradas”, 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 criada durante o Sprint para as partes interessadas, os indivíduos diretamente afetados pelo resultado do produto. Revisões de Sprint, ou demonstrações de sprint, também são uma oportunidade valiosa para demonstrar o produto para pessoas que usam o software e podem fornecer feedback imediato.
Sprint retrospectiva - Após a revisão do sprint, a Scrum Team participa de uma reunião retrospectiva para discutir os sucessos e falhas da Sprint e fazer planos para melhorias. Outro objetivo da retrospectiva é desenvolver ainda mais o processo e as práticas que o time Scrum usa e torná-lo mais efetivo 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” no Scrum Inc. define a definição de concluído: “Um item no backlog está pronto se for independente, acionável, tiver sido atribuído um valor de ponto e tiver uma definição clara dos critérios que significa que é feito. Isso, por sua vez, é referido como a definição de feito, que garante que todos saibam exatamente o que é esperado de um item quando ele é entregue ”.
Modelo de desenvolvimento de Scrum Team
Para construir uma Scrum Team 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 de 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, “Sequência de desenvolvimento em pequenos grupos”, publicado no Psychological Bulletin em 1965, afirma que as novas equipes precisam passar por vários estágios antes de alcançar um nível de alto desempenho e entregar resultados ótimos. Tuckman rotulou esses estágios como: Formando, Storming, Norming e Performing.
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 este estágio como um foco em orientação, teste e dependência. Os membros da equipe ainda não se familiarizaram e ainda pensam em seu trabalho como tarefas individuais, em vez de um esforço colaborativo de toda a equipe como um todo. Sessões de formação de equipe e almoços de grupo geralmente ajudam a equipe a se sentir 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, e é por isso que os conflitos intragrupos costumam ocorrer. A fase de Storming é quando os membros da equipe são incentivados 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 ter confiança sobre suas exigências de trabalho e demandas de tarefas. À medida que a confiança e a estabilidade são estabelecidas, será mais fácil resolver conflitos.
Norming - No momento em que a equipe atinge a etapa Norming, os membros estabeleceram áreas de acordo e chegaram a um consenso. Diretrizes claras foram estabelecidas sobre papéis individuais, resultando em uma nova abertura e coesão entre os membros. O objetivo nesse estágio é 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 um senso de propósito. A equipe aprendeu a ter um bom desempenho em conjunto e a resolver problemas de maneira positiva e diplomática. De acordo com Tuckman, os papéis se tornaram flexíveis e funcionais, e a estrutura da equipe pode suportar um nível mais alto de desempenho.
Schnase recomendou levar em consideração o modelo de Tuckman quando as pessoas são adicionadas a uma Scrum Team porque um novo membro muda a dinâmica da equipe. Cada vez que a equipe muda, ela diz que vai passar pelas fases de formação, storming, Norming e Performing. "A velocidade diminuirá quando você adicionar um novo membro da equipe, então você deve explicar isso."
Schnase também apontou outra razão pela qual é efetivo realizar retrospectivas da Sprint. “Retrospectivas são importantes porque a equipe precisa refletir sobre aspectos positivos e quais itens poderiam melhorar. Isso ajuda a equipe a avançar para o estágio Performing. ”
Primeiro Scrum Team Building
Como a maioria dos modelos de desenvolvimento, leva tempo para alcançar resultados; o mesmo acontece com as Scrum Teams. Uma nova equipe não gerará resultados superiores imediatamente. O tempo que leva para que uma equipe atinja o estágio de desempenho depende dos indivíduos e de outros fatores, incluindo a união da equipe, e é por isso que a formação de equipes é imperativa.
“A formação inicial de equipes é benéfica para estabelecer confiança e para que todos da equipe reconheçam os pontos fortes de outros membros da equipe”, diz Schnase. "Leva tempo para crescer como um time."
A chave para a formação de equipes é encontrar algo que seja interessante e divertido para todos, e abandonar os desajeitados exercícios de construção de equipe dos quais ninguém gosta de participar. Prepare uma lista das possíveis atividades da equipe e pergunte aos membros da equipe quais deles eles gostariam, e peça sugestões adicionais. Você pode considerar uma excursão para unir-se fora do escritório, como uma visita 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 de equipe forte. Além disso, participar de um workshop de treinamento em Scrum em conjunto - especialmente um que inclua sessões de breakout - ajudará você a analisar os pontos fortes individuais que beneficiarão a equipe como um todo.
