AGILE: DO MANIFESTO À APLICAÇÃO DO SCRUM

O objetivo deste conteúdo é apresentar o imperativo ágil e facilitar sua aplicação para diferentes áreas de negócio. No contexto corporativo de transformação digital, os métodos Agile e o Lean vêm sendo utilizados como intercambiáveis, mas na prática são métodos diferentes e complementares. Lean traz o método científico para a gestão de organizações, com testes de hipótese pequenos e baratos, validação e gestão de risco. Já o Agile traz o design organizacional, ferramentas e rituais para tornar possível essa abordagem. Ambos são essenciais para a implementação de uma cultura com foco no cliente, na inovação e na produtividade.

 

Se você acompanha notícias sobre inovação e tendências certamente já deve ter ouvido sobre as metodologias ágeis. O agile, quando bem implementado, transforma sistemas hierárquicos, possibilita maior autonomia organizada, reduz o custo de consenso a partir dos rituais de alinhamento e amplifica a inteligência coletiva da sua organização. Não à toa um dos principais frameworks ágeis - o Scrum -  se vende como “a arte de fazer o dobro do trabalho na metade do tempo”.

 

Desenvolvidas para facilitar atividades relativas ao desenvolvimento de código computacional, as metodologias ágeis hoje são aplicadas em muitas outras áreas de negócios. Conforme as organizações sofrem mais pressão para se tornarem  mais centradas no cliente e trabalharem de forma mais colaborativa, maior se torna a necessidade de encontrar metodologias para facilitar essa transformação. Talvez por isso o agile tenha sido o princípio escolhido por praticamente todas as organizações da nova economia. 

 

Mas o que é o imperativo ágil? Resumidamente, trata-se de uma abordagem para gestão de projetos e organização de times (dedicados, multidisciplinares, autônomos e autocontidos) que usa ciclos curtos de trabalho (iterativos e incrementais) para focar na melhoria contínua durante o desenvolvimento de um produto ou serviço.

 

A recomendação do TEMPLO.cc vai sempre na direção de absorver o melhor de cada metodologia para criar a sua proprietária, com adaptações à realidade de cada operação. As metodologias ágeis podem ser, por exemplo mescladas com sistemas matriciais (Spotify) ou aliadas a modelos FlatLand (Valve).

Nas próximas seções, vamos compartilhar uma visão pragmática sobre o agile que vai te ajudar a entender os conceitos e as práticas do Scrum.

1

MANIFESTO

1.1

BENEFÍCIOS

2.1 

PAPEIS

2  

SCRUM

2.2  

ARTEFATOS

2.3  

CERIMÔNIAS

 

MANIFESTO ÁGIL: ONDE TUDO COMEÇOU

Em fevereiro de 2001, uma reunião nas montanhas nevadas do estado norte-americano de Utah no resort de inverno e verão Snowbird marcava o surgimento e propagação do paradigma dos métodos ágeis. Essa reunião desencadeou o que conhecemos hoje como manifesto ágil, que se tornou praticamente um grito de guerra para a indústria de desenvolvimento de software.

O manifesto ágil possui doze princípios e quatro valores. Hoje, existem dezenas de frameworks ágeis, criados ao longo de 20 anos (os mais famosos são SCRUM e KANBAN). Cada método carrega consigo os valores e princípios arraigados no manifesto.

Valores ágeis*:
*Com adaptações.

• Indivíduos (e a interação entre eles) mais que processos e ferramentas;
• Produtos em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.


Princípios ágeis*:
*Com adaptações.

1.  Garantir a satisfação do cliente pela entrega rápida e contínua de projetos de valor;

2.  Abraçar modificações nos requisitos, mesmo nas etapas finais de desenvolvimento;

3.  Entregar projetos funcionais com frequência, em semanas ao invés de meses;

4.  Oportunizar cooperação estreita e cotidiana entre equipes de negócios e desenvolvedores;

5.  Construir projetos em torno de indivíduos motivados, em quem se deve confiar;

6.  Conversar cara a cara é a melhor forma de comunicação;

7.  Compreender que projetos funcionais são a principal medida de progresso;

8.  Priorizar o desenvolvimento sustentável, capaz de manter um ritmo constante;

9.  Atender continuamente à excelência técnica e ao bom design;

10.  Simplificar, a arte de maximizar a quantidade de trabalho não realizado, é essencial;

11.  Permitir que equipes se auto-organizem para garantir melhores arquiteturas, requisitos e processos;

12.  Refletir regularmente, em equipe, sobre como se tornar mais eficaz – e se ajustar de acordo.
 

BENEFÍCIOS DO AGILE

Flexibilidade e Ajustes de Rota
Uma das principais vantagens do uso de metodologias ágeis é a rapidez de resposta e alterações de escopo tático. Na abordagem ágil são aceitas mudanças durante o desenvolvimento e até mesmo se espera que elas aconteçam, flexibilizando o desenvolvimento sem gerar ruídos ou sobrecarga. 

Entregas menores e mais frequentes, com valor distribuído pela jornada
O Agile possibilita ciclos curtos de desenvolvimento, com foco em entregas menores e frequentes ao longo do tempo, o que minimiza erros e maximiza a geração de valor para o cliente durante o processo. Fora da área de tecnologia, os sprints podem variar de acordo com o ciclo operacional do segmento. No varejo ou no mercado bancário, sprints de uma ou duas semanas podem ser ótimos. Já em uma empresa de óleo e gás, distribuidoras elétricas ou seguradoras, talvez seja necessário pensar em períodos de até 04 semanas.

Redução de riscos
As atualizações diárias, comunicação constante, feedback colaborativo e testes regulares impedem que os erros persistam e minimizam prejuízos à implementação, a partir de ajustes constantes de rota.

Transparência Radical
É preciso que todos os membros da equipe tenham visibilidade sobre o que está acontecendo durante qualquer momento do projeto. A abordagem ágil garante que todos os principais interessados tenham a oportunidade de visualizar as atividades e progressos do projeto por meio de atualizações diárias em softwares de gestão (como Trello, Asana, Mondays, etc) ou painel físico de Scrum (Kanban).

Gestão da Qualidade
As metodologias ágeis são fundamentadas em qualidade. Seu principal objetivo não é apenas acelerar o processo de desenvolvimento, mas fazer entregas com a maior geração de valor para o cliente. Com o uso de alguns artefatos do Agile, como “user stories” e “criteria of done”, a métrica de sucesso passa a ser resolver a dor e a necessidade que os clientes apresentam, ao invés de preencher requisitos imaginados.

Motivação Intrínseca
Equipes que podem se autogerenciar têm mais segurança sobre as suas decisões e ganham um aumento de moral e confiança, se mantendo atualizadas acerca de todo o andamento do projeto. Para atingir estes resultados, trabalhamos com o conceito de motivação intrínseca como a soma entre maestria, autonomia e propósito. Segundo estudos de economia comportamental dos últimos 50 anos, são estes os fatores que mais impactam na performance de colaboradores.
 

 

SCRUM

Scrum é um framework que ajuda as equipes a adotarem os princípios do manifesto Ágil no seu dia a dia. O Scrum incentiva o time a aprender com experiências, a se auto-organizar e a refletir sobre suas vitórias e desafios para melhorar continuamente.

Embora existam dezenas de metodologias ágeis com variações entre elas, recomendamos o uso do Scrum como base para aplicação da agilidade fora do contexto técnico. Isso porque, além de ser o método adotado em 80% das grandes organizações que aplicam a agilidade em escala, sua caixa de ferramentas é simples e didática, permitindo uma curva de adoção rápida e pouco custosa.

"Ferramenta boa é aquela

que as pessoas usam"

Geralmente considerado como uma estrutura ágil de gerenciamento de projetos, o Scrum comporta um conjunto de papéis, artefatos e rotinas que servem para ajudar as equipes a estruturar e gerenciar seu processo de trabalho. Nas próximas seções, você entenderá cada uma dessas categorias.

PAPÉIS

 

O Framework Scrum prevê três funções essenciais para garantir o processo otimizado e a comunicação ideal entre membros da equipe. Apesar de muitas organizações apresentarem outros papéis envolvidos na definição e entrega do produto, o framework original define apenas esses três:

1_ Proprietário do produto (Product Owner)

Responsabilidade:
Garantir o sucesso do projeto, alinhando os objetivos dos diferentes stakeholders. Ele é o gestor do backlog do produto e é o responsável por maximizar o valor que a equipe entrega. O P.O. não é o "chefe', mas um facilitador, norteador e gestor de qualidade.

Lugar no time: 
Idealmente, cada time scrum deve ter apenas um product owner, embora um product owner possa dar suporte a mais de um time. A possibilidade de POs que supervisionam até 3 squads (e nunca mais que isso) deve ser reservada para P.Os experientes e que não estejam acumulando a função de scrum master (o que ocorre recorrentemente em grandes organizações).

Atividades gerais:
A principal preocupação do product owner deve ser a comunicação clara entre o time e os diferentes stakeholders do projeto. A capacidade de transmitir prioridades e ter empatia com os membros da equipe e partes interessadas é vital para orientar o desenvolvimento do produto na direção correta.

O product owner não deve ditar como a equipe chega a uma solução técnica, mas sim buscar o acordo entre os membros da equipe. Esta função é crucial e requer um conhecimento profundo de ambos os lados, tanto dos negócios quanto do desenvolvimento na equipe Scrum. 

Portanto, um bom product owner deve ser capaz de comunicar o que o negócio precisa, perguntar por que ele precisa e transmitir a mensagem a todas as partes interessadas, incluindo a equipe de desenvolvimento.

Atividades específicas:
Definir e anunciar releases;
Comunicar entregas e status do time;
Apresentar resultados para executivos em checkpoints regulares;
Compartilhar o progresso durante reuniões de governança;
Compartilhar RIDS significativos (riscos, impedimentos, dependências e suposições);
Negociar prioridades, escopo, financiamento e cronograma;
Facilitar e moderar a gestão do backlog e do sprint;
Certificar-se de que a lista de pendências do produto seja visível, transparente e clara; 

 


2_Mestre Scrum (Scrum Master)

Responsabilidade:
Garantir que o framework Scrum esteja sendo bem aplicado e respeitado na organização. É o evangelizador da cultura ágil na organização como um todo, garantindo canais de diálogo transversais e a constante evolução das metodologias adotadas garantindo que as melhores práticas testadas sejam replicadas em outros times.

Lugar no time:
O Scrum Master deve dominar o processo do Scrum, a cultura ágil e os princípios de design organizacional como ninguém. Enquanto o product owner se dedica à construção do produto e a equipe de desenvolvimento à produção, o Scrum Master garante a compreensão dos valores, princípios e práticas da metodologia em toda a organização.

Atividades gerais:
O Scrum Master é responsável por remover impedimentos à habilidade do time de entregar os objetivos de cada sprint. O Scrum Master não é um líder de equipe tradicional ou gerente de projeto, mas atua como um amortecedor entre a equipe e qualquer influxo de distração.  Ele é uma interface entre os squads, outros times e a liderança da organização.

O Scrum Master deve assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Também protege a equipe para quenão se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.

Atividades específicas:
Ajudar o Product Owner a manter o backlog do produto de maneira que garanta que o trabalho necessário seja bem compreendido;


Treinar o time constantemente para assegurar processos com foco em entregas de alta qualidade;
Promover a auto-organização de times;


Resolver impedimentos para o progresso interno ou externo do seu time;
Facilitar cerimônias para garantir progresso regular;


Educar stakeholders sobre os princípios Ágil e Scrum;
    

3_ Equipe de desenvolvimento


Responsabilidade:
Realizar as atividades necessárias para que as entregas acordadas na planning sejam garantidas a cada sprint.

Lugar no time: 
A equipe de desenvolvimento é multidisciplinar, e tem de três a nove membros. Enquanto os membros da equipe são referidos como desenvolvedores em parte literatura, o termo pode se referir a qualquer pessoa que desempenhe um papel no desenvolvimento e suporte do projeto, e incluir pesquisadores, arquitetos, designers, especialistas em dados, estatísticos, analistas, engenheiros, programadores e testadores, dentre outros.

Atividades gerais:
A equipe deve se auto-organizar para realizar as atividades do escopo previsto de cada Sprint. Embora demandas sejam de responsabilidade exclusiva do product owner,  a equipe deve ser incentivada a interagir diretamente com clientes e/ou interessados ​​para obter o máximo de compreensão e imediatismo de feedback, incrementando as discussões de briefing e priorização.

 
 

ARTEFATOS

Artefatos funcionam como ferramentas visuais projetadas para maximizar a transparência das informações-chave do projeto, de modo que todos tenham o mesmo entendimento das tarefas e iniciativas necessárias para a conclusão de um sprint ou projeto. No Scrum, existem 3 artefatos: o backlog do produto, o backlog do sprint e o incremento com sua definição de feito.


Quadro Scrum
O Quadro Scrum é uma ferramenta de gestão visual que tem como objetivo tornar o backlog e as atividades do sprint visíveis. É utilizado para compartilhar informações, comunicar resultados, realizar reuniões, gerenciar métricas e integrar o time. Se mostra efetiva para o gerenciamento das tarefas e do trabalho como um todo.

A sua estrutura é simples: uma coluna de “to-do” (a fazer), uma de “doing” (fazendo) e outra de “done” (feito). Essas colunas devem estar disponíveis ou em uma ferramenta digital de gestão de projetos, como Trello, Asana, Monday, ou fisicamente na sala onde a equipe trabalha regularmente. Em cada coluna deverão estar dispostas as tarefas da equipe representadas cada uma por um post-it, alocadas em uma das três colunas, de acordo com o status da tarefa. No início de um sprint, todo o backlog deve estar na coluna de to-do. Na medida em que as tarefas começam a ser realizadas, seu responsável deve mover a o card da tarefa para doing e, ao concluí-la, done, de modo que todo o time possa acompanhar o status do desenvolvimento. É comum usar post-its de cores diferentes para tarefas de naturezas distintas, graus de complexidade, urgência ou qualquer aspecto que possa ser relevante para a equipe e que possa ser traduzido visualmente. Importante ressaltar aqui que, para serem movidas, as tarefas devem ser equivalentes em seus esforços. Isto significa que cada post-it ou card deve conter apenas uma tarefa, referente ao mínimo esforço possível para chegar ao resultado desejado.

No Templo.cc, usamos as seguintes colunas: BACKLOG (tudo que há pra se fazer de forma geral e priorizada), BREAKDOWN (backlog traduzido em tarefas que tenham tamanhos similares), TO-DO (o que será feito no sprint), DOING (o que está de fato em andamento), STUCK (o que já deveria ter saído do doing mas não pode ser finalizado por algum motivo), DONE (feito neste sprint) e ARCHIVE (feito em sprints anteriores).

 

Backlog de Produto
Lista principal de tarefas e iniciativas que precisam ser realizadas para a conclusão do projeto. Esta é uma lista dinâmica de requisitos, aprimoramentos e correções, que serve como entrada para o backlog do sprint.

O backlog do produto é constantemente revisitado, priorizado e mantido pelo Product Owner. À medida em que realizamos testes e aprendemos mais, ou conforme o mercado muda, alguns itens podem não ser mais relevantes ou os problemas podem ser resolvidos de outras maneiras.

Backlog do Sprint

O Backlog do Sprint é a lista de aprimoramento, correções de erros e requisitos selecionados pela equipe para implementação no atual ciclo de sprint. Na reunião de planejamento, antes de cada sprint, a equipe escolhe os itens do backlog de produto nos quais vai trabalhar. Esse backlog pode ser flexível e evoluir durante um sprint. No entanto, o objetivo fundamental - o que a equipe deseja alcançar com o sprint atual - não pode ser comprometido.
 

Incremento
Incremento (ou objetivo do sprint) é o acumulado de entregas que se deseja alcançar ao final de um sprint.

Criteria of done 

Para garantir que as tarefas sejam realizadas sem deixar dependências, todos os membros do time devem entender o que significa 'concluído'. Por isso, equipes ágeis precisam definir quais são os critérios para tal consideração e documentá-los no card de cada tarefa.
 

User stories 
É uma explicação geral informal de um recurso de produto ou serviço escrita a partir da perspectiva do cliente. Seu objetivo é articular como um recurso fornecerá valor ao cliente.

Componente-chave do desenvolvimento ágil, as user stories nos ajudam a colocar as pessoas em primeiro lugar, no centro da conversa. Essas histórias usam uma linguagem não técnica para fornecer contexto para a equipe de desenvolvimento e seus esforços. Depois de ler uma história de usuário, a equipe sabe por que está construindo, o que está construindo e que valor isso cria.
 

 

SPRINT E CERIMÔNIAS

SPRINT

O que é?
Um sprint é um período curto de tempo em que uma equipe ágil trabalha para concluir uma quantidade definida de trabalho, com o objetivo de entregar algum incremento ao produto ou serviço de responsabilidade do time.


Por quê?
Sprints possibilitam que projetos grandes e complexos sejam divididos em pequenos pedaços realizáveis em curtos períodos. Trabalhar em ciclos curtos com objetivo focado em realizações de testes e entregas de incrementos permite ao time maior flexibilidade e adaptação. Os sprints facilitam a gestão de projetos, permitindo que as equipes realizem trabalhos de alta qualidade mais rapidamente e entreguem melhora contínua ao produto ou serviço.

Quando?
Duração de no mínimo 1 semana e no máximo 4 semanas. Quanto maior a complexidade e a incerteza do produto ou serviço, menor deve ser o sprint. Quanto menor a complexidade e a incerteza, maior pode ser o sprint.

PLANNING

Perguntas-chave:
Qual o incremento no meu produto ou serviço que, caso implementado, irá gerar o maior valor para o meu cliente? 
Qual a quantidade ótima de tarefas que meu time consegue realizar no ciclo de um sprint? 

O que é?
A planning é o ritual de times ágeis que dá início ao sprint. O objetivo da planning é definir o que pode ser entregue no sprint e como esse trabalho será alcançado. A planning é realizada em colaboração com todo o time. Se for feita corretamente, também cria um ambiente em que a equipe é motivada, desafiada e aumenta suas chances de sucesso. Plannings ruins podem atrapalhar a equipe, estabelecendo expectativas irreais.

Quando?
Dia: Início da semana
Duração: 1 hora

Quem deve participar?
Toda a equipe

Como?
As atividades do backlog do produto devem ser priorizadas em uma matriz com os eixos urgência X importância. As atividades consideradas mais urgentes e importantes são aquelas que deverão ser executadas primeiro no sprint. É acordado qual o objetivo do próximo sprint. O objetivo é o “porquê” do trabalho que deverá ser desenvolvido ao longo do sprint.

Uma vez determinado o objetivo do sprint e as atividades priorizadas, cada atividade deverá ser desdobrada em tarefas que demandam por volta de uma hora para serem executadas. Com a visualização temporal da duração de cada atividade a equipe é capaz de determinar quantas atividades poderão ser finalizadas durante o período do sprint. Uma vez determinada as atividades e tarefas, cada uma delas deve ser delegada a um integrante do time. Depois que todas as atividades forem divididas pelo time, é importante que seja feita uma passagem geral sobre as missões de cada integrante do time para garantir que todos entenderam suas funções e evitar retrabalho.

Dicas
Garanta que sua equipe compreenda o objetivo do sprint e como o sucesso da meta será mensurado. Essa é a chave para manter todos alinhados e avançar em direção a um destino comum.

Não se comprometa com tarefas que não serão possíveis de serem realizadas em paralelo ao sprint, como trabalho em outra equipe, burocracias etc.

Depois que um plano for criado para realização do sprint, certifique-se de que alguém reúna essas informações em sua ferramenta de gerenciamento ou colaboração de projetos (Asana, Trello, etc.). Dessa forma, o plano fica disponível para todos verem mais tarde.

Não selecione muitas atividades, superestime a velocidade do time ou selecione tarefas que não podem ser concluídas no sprint. Você não vai querer configurar a sua equipe para o fracasso.

 

Não programe para o mesmo sprint uma grande quantidade de trabalho incerto ou de alto risco. Quebre tarefas complexas ou com alta incerteza em tarefas mais simples e não tenha medo de deixar parte do trabalho para o próximo sprint.

DAILY

Perguntas-chave:
No que eu trabalhei ontem?
No que estou trabalhando hoje?
Quais problemas estão me impedindo de completar minhas tarefas?

O que é?
Daily é uma reunião curta e diária que envolve todo o time com o objetivo de destacar o progresso da equipe e sinalizar bloqueadores do andamento das tarefas.

Por quê?
Permite ajustar rota e resolver bloqueadores de maneira ágil 
Impede retrabalhos e garante que todos estão na mesma rota
Aumenta a capacidade de mensuração da velocidade do time na finalização de tarefas

O reforço diário do compartilhamento de sucessos e planos individuais mantém o time motivado com a contribuição geral da equipe à organização.

Quando?
Dia: seg-sexta
Duração: 15 minutos
Preferencialmente no início do dia

Quem deve participar?
Todo o time

 

Como?
Escolha alguém para cronometrar o tempo da daily e garantir que ela está acontecendo de maneira eficiente. Faça um rotacionamento da função de guardião do tempo. Garanta que todos da equipe passaram seus status e cobre objetividade nas falas.

Se houver algum bloqueio em tarefas que dizem respeito a um problema externo ao time, é responsabilidade do P.O. resolver a questão e trazer a solução de volta para o time após a daily.

Se o bloqueio for interno ao time, aconselha-se que o time pare logo após a daily para encontrar uma solução em conjunto para a questão, técnica conhecida como swarming.

 

 


SPRINT REVIEW

O que é?

Sprint review é uma reunião na qual o time demonstra informalmente os avanços conquistados no último sprint e descreve o trabalho que cada integrante fez para essa iteração. É hora de fazer perguntas, experimentar novos recursos, fazer comentários e verificar se o critério de feito das tarefas está claro para todos os integrantes. Nesse momento o time identifica as tarefas do backlog que não foram concluídas e relatam o porquê. Por fim, mas não menos importante, é a hora de celebrar sucessos. Compartilhar o sucesso é uma parte importante da construção de uma equipe ágil.

Quando?
Ao final de cada sprint
Duração: 1 hora - 3 horas (dependendo da duração do Sprint)

 

Quem deve participar?
Todo o time. 

Como?
Listar as atividades que foram classificadas como DONE;
Comentar sobre problemas que impediram ou dificultaram que alguns itens fossem classificados como feito;
Revisar o conceito de feito caso haja desentendimento;
Exibir o funcionamento do incremento e as tarefas realizadas durante o sprint e abrir para dúvidas;
Discutir sobre o objetivo do próximo sprint;
Rever prazos, datas e recursos.

 

Dicas
Para um Sprint Review de qualidade é muito importante que o time desenvolva uma cultura clara de como entregar o trabalho que tem que ser realizado, bem como o que significa estar pronto.

Sprints Reviews não são retros. Uma sprint review é sobre apresentar o trabalho duro de toda a equipe e avaliar e comentar sua qualidade.

Os Sprint Review são sobre teambuilding. Não é uma prova, mas um evento colaborativo no qual as pessoas demonstram seu trabalho, perguntas e recebem feedbacks construtivos.

Se um Sprint Review não se tornar uma atividade positiva em toda a equipe, isso pode ser indicativo de que o time está assumindo muito trabalho e não consegue concluir durante uma iteração ou que as condições para a realização do trabalho não são ideais.

 

 


RETRO
Perguntas-chave:
O que fizemos de melhor e o que poderia ser melhorado?
Como podemos criar táticas para melhorar nosso trabalho?

O que é?
A Retro é uma rotina de times ágeis que visa refletir sobre o passado para melhorar o futuro. As Retros são uma excelente oportunidade para sua equipe ágil avaliar a si mesma e criar um plano para abordar áreas de melhoria para o futuro. A retrospectiva abraça o ideal de melhoria contínua - e protege contra as armadilhas do conformismo - usando os aprendizados e erros do passado para aperfeiçoar as relações de trabalho do futuro.

Quando?
Após o final de um sprint e antes de uma planning.
Duração: 1 hora - 3 horas (dependendo da duração do Sprint)

Quem deve participar?
Todo o time. O scrum master é responsável por facilitar essa dinâmica.

Como?
Existem diversas dinâmicas que podem ser aplicadas em uma retro. O ideal é que essas dinâmicas variem a cada Retro. A escolha de uma dinâmica e a aplicação conjunta em sua equipe é o primeiro passo da retro. 

Abaixo, algumas dinâmicas sugeridas:

Iniciar / Parar / Continuar: O que a equipe deve começar a fazer, parar de fazer e continuar fazendo. Concentre-se em maneiras de descontinuar itens na coluna "Parar".

Mais / menos: o que a equipe precisa fazer cada vez menos. Crie um plano sobre como lidar com os principais itens da lista "faça menos".

Feliz / Triste / Louco: O que deixou a equipe feliz, triste e enlouquecida. Concentre-se nas listas tristes e loucas e em como melhorar para que haja apenas itens na coluna feliz na próxima vez.

1. Escolha uma das dinâmicas acima e convide seu time a criar uma lista seguindo as instruções da dinâmica.

2. Agrupe itens da lista que dialogam e podem se tornar um só item e converse sobre temas comuns que surgiram. Priorize os itens da lista por importância.

3. Discuta maneiras e táticas para melhorar os dois principais itens que foram priorizados nas sessões de melhoras.

4. Crie um plano de ação. No final da retro a equipe deverá ter produzido algumas ideias de acionáveis, com responsáveis claros e prazos, para abordar os itens que necessitam de melhoria.

 

Dicas
Nada é mais frustrante do que repetir os mesmos obstáculos em todas as retros. Evite estagnação (e frustração!), certificando-se de que todos saiam com os próximos passos claros. Durante a Retro, Concentre-se em resultados, não em ações ou pessoas. 

A Retro precisa de um ambiente seguro para todos se concentrem em como melhorar e se adaptar aos desafios de seus projetos. Portanto, para que as Retro sejam bem-sucedidas é necessário que haja uma atmosfera de apoio que incentiva (mas não força) todos os membros da equipe a contribuir.

 

GOSTOU DESSE CONTEÚDO?

_mais CONTEÚDOS

Conheça nossas newsletters, índices e cartilhas

ito-templo.webp

_ÍNDICE DE TRANSFORMAÇÃO ORGANIZACIONAL (ITO)

Preencha o assessment para receber os resultados atualizados e recomendações gratuitas da nossa equipe para facilitar a transformação da sua organização.

seed.png

_SEED NEWSLETTER

Todo domingo, enviamos uma lista dos melhores conteúdos sobre gestão ágil e transformação digital direto para o seu e-mail. Uma curadoria que vai fazer você realizar mais, de maneira mais equilibrada.

iphone.jpeg

_[ON]TEM NEWSLETTER

Todo dia, separamos um tempo para ler fatos sobre tecnologias digitais. À noite, reunimos os que consideramos mais importantes em um e-mail simples. Depois, enviamos para você ler quando acordar.

_REMIX

Insights semanais dos nossos colaboradores para o blog do TEMPLO.cc

UM NOVO MUNDO É POSSÍVEL

  • Branca Ícone LinkedIn
  • Branca ícone do YouTube
  • Branca Ícone Spotify
  • Branca Ícone Instagram

FERRAMENTAS

Imprensa

Monges

SOMOS CRIADORES

Malha.cc

Journey.cc

RJ Criativo

NEWSLETTER