No artigo I, aprendemos sobre os pilares do Scrum: transparência, inspeção e adaptação que ajudam-nos a entender algumas de suas características. Além do exposto, podemos dizer que o Scrum é composto por:

Regras: claras e fáceis de entender, as regras do Scrum são apresentadas no Guia do Scrum - https://www.scrumguides.org/

Artefatos:  eles suportam os eventos e papéis

Papéis:  Cada membro da equipe tem um papel, uma função específica e responsabilidades definidas

Eventos: Eles também são conhecidos como cerimônias ou rituais que abordam reuniões com objetivos específicos e dicas sobre como executá-las da melhor maneira possível.

A equipa do framework Scrum é baseada na prática de criatividade, produtividade e flexibilidade:

Criatividade: é uma característica da equipa auto-organizada, a fim de aplicar novas soluções para resolver um problema e auxiliar os clientes em sua realidade.

Produtividade: a equipa de desenvolvimento trabalha para medir seu desempenho e melhorar suas ferramentas e processos, permitindo que cada período de trabalho seja mais produtivo.

Flexibilidade: está relacionada à adaptação à mudança, como a equipa de desenvolvimento reage às adversidades: resolvendo-as, solicitando ajuda e priorizando as tarefas, caso necessário.

Scrum e o Manifesto Ágil

O Scrum foi co-criado por Jeff Sutherland e Ken Schwaber e apresentado oficialmente em 1995.

A maioria das práticas ágeis originou-se do sistema de produção da Toyota em um ambiente baseado na competição de produção em massa de carros, fabricação just-in-time, redução do trabalho em andamento, foco no cliente, eliminação de resíduos e melhoria contínua.

O nome Scrum foi inspirado por um método do hugby, no qual os jogadores tentam ganhar a posse da bola ao trabalhar juntos. Nesse método esportivo, podemos identificar características como equipa auto-organizada, aprendizado e mútuo para um objetivo.

Após o Scrum, foi criado o Manifesto Ágil em 2001. Ele diz respeito a um grupo de valores e princípios que surgiram de uma reunião de 17 especialistas em "metodologias leves" em um resort em Utah. O objetivo da reunião era (além de se divertir) concordar sobre uma alternativa aos processos "pesados" de desenvolvimento de software orientados a documentação, conforme Jim Highsmith.

Vale a pena conferir todo o manifesto e seus 12 princípios: https://agilemanifesto.org/principles

Perceberás que eles estão relacionados a práticas ágeis e seu ponto de partida é uma mudança de mentalidade.

Manifesto Ágil: Valores

1. Indivíduos e interação mais do que processos e ferramentas

2. Software de trabalho (ou entrega) mais do que documentação abrangente

3. Colaboração do cliente mais do que negociação de contrato

4. Responder às mudanças mais do que seguir um plano

Por fim, o manifesto ágil propõe que devemos priorizar os indivíduos e a interação mais do que uma extensa documentação que a equipa não consegue atualizar, por exemplo. Dessa forma, valoriza-se os indivíduos e a interação primeiro e cria-se uma documentação para o que é necessário documentar e a mantém atualizada para ser acessada e consumida.

Agora que já sabes o que é o Scrum, aprenderemos sobre os papéis e eventos do Scrum no próximo artigo.

Envie um e-mail e comente quais outras práticas gostavas de aprender mais.

Partilhe esse artigo com um amigo que possa ter interesse.

No último artigo, aprendemos mais sobre as características do Scrum e o Manifesto Ágil.

Como já sabes, o Scrum é composto de papéis. Vamos entender do que se trata ...

Inicialmente, para adaptar a aplicabilidade do Scrum à realidade da sua empresa, é importante dizer que nem sempre pessoas são contratadas para executar apenas uma função, mas é necessário adequar as responsabilidades de cada membro da equipa para tais papéis.

Product Owner - PO

Ele / ela é literalmente o especialista e proprietário do produto / serviço a ser desenvolvido. O Product Owner (PO) conhece as tendências do mercado e também os sentimentos do cliente. Na organização, ele geralmente vem da área de negócios responsável por esse produto / serviço.

O Products Owner gerencia o Product Backlog (PB). O PB é o primeiro artefato sobre o qual aprenderemos. Trata-se de uma lista sobre tudo o que constitui o produto / serviço. Enquanto o produto / serviço existir, também haverá o backlog do produto.

O Product Owner é o único que pode fazer qualquer alteração ou atualizar o Product Backlog. No ambiente corporativo, sabemos bem que muitas vezes há situações em que um CIO ou CEO apresenta novas ideias e prioridades diferentes do planeamento da equipa. Eles geralmente solicitam novas prioridades ou o cancelamento de uma entrega que não faz mais parte da estratégia da empresa.

Caso alguém de fora da equipa solicite alguma alteração, é um dever da equipe informar a PO. Dessa forma, ele / ela poderá fornecer os alinhamentos necessários à organização, considerando a priorização de acordo com as entregas que trarão mais resultados ao cliente.

Ao considerar uma transformação ágil em uma empresa comum, por exemplo, o PO pode ser alguém contratado no mercado e que conhece um produto / serviço específico ou alguém que trabalha em uma área de negócios e que comece a trabalhar com a equipa de desenvolvimento de TI. Em uma organização ou departamento de suporte que não esteja relacionado a uma software house ou equipa de tecnologia, o PO pode ser um gerente ou um especialista com mais conhecimento sobre as prioridades do trabalho a ser realizado.

Para facilitar, podemos dizer que os POs podem se inspirar em Dragon Shiryu, de Os Cavaleiros do Zodíaco - Knights of the Zodiac.

Shiryu é considerado o mais maduro dos heróis e também o mais sábio.

Isso se reflete em sua capacidade de vencer inúmeras batalhas sem o seu Dragon Cloth.

Ele aprendeu a sabedoria fundamental e melhorou os sentidos através do cosmos.

Scrum Master - SM

Ele / ela não é gerente, nem chefe ou gerente de projeto. O Scrum Master é um facilitador de equipa, responsável por ajudar o grupo a resolver os impedimentos. A SM ajuda as outras equipes da empresa a entender como a equipa Scrum funciona. Ele / ela também ensina o time de desenvolvimento como praticar Scrum e manter os eventos dentro do prazo. O SM não precisa estar presente em todos os eventos, mas deve garantir que a equipa os execute.

O Scrum Master ajuda o PO com as ferramentas para gerenciar o backlog do produto e auxilia a equipa de desenvolvimento com métricas para acompanhar seu desempenho e velocidade.

Em um cenário em que não temos alguém contratado para essa função específica, é importante que alguém o faça. Na minha experiência anterior, trabalhei como Scrum Master ao mesmo tempo em que trabalhei em minhas "tarefas de desenvolvimento". Não é a situação ideal, mas pode acontecer.

Assim como Pegasus Seiya, o Scrum Master nunca desiste de lutar, mesmo que uma situação pareça impossível ou muito difícil de lidar. Da mesma forma, os dois se preocupam com os membros da equipa durante todas as batalhas. Além do mencionado no Guia Scrum, entendemos que um Scrum Master reconhece o trabalho da equipa, é leal, autoconfiante, pró-ativo e tem força de vontade.

Development Team - Dev Team

De acordo com o Guia Scrum, ele diz respeito à equipa que realiza o trabalho de fornecer um incremento potencialmente entregável de produto ou serviço concluído no final de um período de trabalho. A equipa de desenvolvimento é composta por diferentes conhecimentos e habilidades. Em uma equipa de desenvolvimento de software, por exemplo, precisamos de pelo menos um analista, um desenvolvedor e um testador. À medida que o tempo passa, caso um dos membros esteja disponível, é possível prepará-lo para diferentes responsabilidades, a fim de ajudar em outras tarefas, caso alguém esteja ausente. O Dev Team é auto-organizado e conhece seu desempenho e a quantidade de trabalho a ser realizado para fornecer um produto / serviço em um período de trabalho específico.

Em alguns setores, essa equipa executa atividades diárias que ocorrem com frequência, como envio de relatórios em uma data específica, fechamento financeiro, assistência a equipes de diferentes departamentos etc. Considerando a prática do Scrum, embora essa equipa não desenvolva um produto ou serviço, é responsável para outras atividades principais da organização e também é importante permitir a melhoria contínua de tais processos.

As práticas do Scrum permitem a visibilidade de todos os processos pelos quais a equipa é responsável. É possível identificar quais processos exigem mais tempo para serem executados e quais podem ser refinados. Por último, mas não menos importante, permite entregas de inovação para cada período de trabalho, a fim de trabalhar com melhoria contínua.

Dessa forma, a equipa agrega mais valor, com maturidade em suas atividades, possibilitando a qualidade no progresso da operação da organização.

Scrum Team

Por fim, o Scrum Team é composto pelo PO, SM e Dev Team.

De acordo com o Guia Scrum, o Scrum Team foi projetado para otimizar flexibilidade, criatividade e produtividade - características do Scrum.

Comente nessa publicação para que saiba que gostaste!

Partilhe com um amigo que possa ter interesse!

Eventos

Os eventos ou cerimônias do Scrum são de tempo determinado, com uma duração máxima. Isso significa que, se houver algum tempo restante, não é obrigatório consumi-lo. A equipa deve estar livre para voltar ao trabalho nas tarefas planejadas. Da mesma forma, os eventos não devem demorar mais do que a duração máxima recomendada, pois dessa forma, o tempo da Sprint seria consumido. O período informado no Guia Scrum é baseado no Sprint de um mês. Para sprints mais curtos, cada evento deve ser mais curto.

Sprint

É o primeiro evento Scrum. O Sprint é o período de trabalho que não excede um mês e é quando um incremento potencialmente liberável de produto ou serviço pronto e utilizável é criado. Como tendência do mercado, um Sprint geralmente leva 7 ou 15 dias de duração. No final de cada Sprint, há uma entrega de valor para o cliente final ou um departamento interno da organização. Todo Sprint tem um objetivo, o Sprint Goal.

O Sprint é composto de planeamento, reuniões diárias, trabalho de desenvolvimento, revisão e retrospectiva.

O incremento (o segundo artefato) está relacionado ao Sprint. Ele diz respeito à soma de todos os itens do backlog da Sprint no final da Sprint atual, além dos incrementos das Sprints anteriores.

Um Sprint só pode ser cancelado em caso de obsolescência do objetivo do Sprint. O PO é o único que pode cancelá-lo. Caso uma Sprint seja cancelada, todos os itens concluídos durante a Sprint serão revisados.

Sprint Planning

Ela diz respeito à Reunião de Planeamento sobre o trabalho a ser desenvolvido durante o Sprint. O PO geralmente realiza um refinamento antes da reunião de planeamento, quando os itens da lista de pendências do produto são detalhados para uma melhor compreensão pela equipa de desenvolvimento.

Durante o planeamento, a equipa seleciona os itens de backlog do produto a serem executados - com base no Objetivo da Sprint e no tempo estimado para entregar cada um deles x período da Sprint.

Existem algumas técnicas aplicadas pelas equipas durante o planeamento, como o Planning Poker. Consiste em facilitar o processo de estimativa de tarefas. Cada membro da equipa recebe cartões com uma numeração 3,5,7,9 e cada atividade é analisada.

Os membros da equipa levantam uma carta com um dos números acima, considerando o tempo que entendem que seria necessário para concluir a tarefa. A estimativa termina quando toda a equipe concorda com o tempo definido. Os membros que escolherem valores muito discrepantes dos outros devem explicar os motivos das estimativas mínimas ou máximas.

Caso tal discussão demore muito para ser concluída, o item deve ser enviado de volta ao backlog do produto / serviço para ser revisado e liberado pela PO.

Existem também outras ferramentas para fazer a estimativa. Algumas equipas também trabalham com pontos de função, é mais comum entre as equipes de TI.

Durante o planeamento, o Scrum Team está presente. Considerando a complexidade das atividades, um especialista também pode ser convidado.

A Sprint Planning não deve ser superior a oito horas para um Sprint de um mês.

Daily Sprint

A Sprint começa com a Sprint Planning e segue com a famosa Daily Sprint. De acordo com as práticas Scrum, esta reunião é realizada no mesmo local e horário, considerando que a consistência reduz a complexidade.

Este evento tem a duração máxima de quinze minutos. A seguir, algumas perguntas frequentes sobre a reunião diária: 

Caso não haja problemas / impedimentos ou caso alguém da equipe não venha ao trabalho, podemos cancelar esta reunião? Não, qualquer divergência pode estar a acontecer e é importante que todos estejam cientes do progresso da lista de pendências da Sprint para ajudar na identificação de inconsistências.

A presença do Scrum Master é obrigatória na Reunião Diária? Não, ele / ela deve garantir que o evento aconteça.

O PO é obrigatório na Daily Sprint? A Daily Sprint é o momento em que a equipa de desenvolvimento acompanha o progresso da Sprint, considerando que é uma equipe auto-organizada.

Também é uma boa prática realizar este evento como uma reunião de pé. Ajuda a equipe a mantê-lo dentro do prazo.

Sprint Review

Este evento permite que a equipe mostre às partes interessadas entregas de valor produzidas durante o Sprint e também informe caso o objetivo do Sprint não tenha sido alcançado. Este é um evento de no máximo quatro horas de duração para uma Sprint de um mês.

Algumas empresas realizam um evento de “demonstração” para mostrar o produto ou serviço funcionando “ao vivo” para toda a organização. Dessa forma, as partes interessadas são atualizadas e todas as equipas têm a oportunidade de conhecer as entregas em vigor. É também um momento de integração, evitando os “silos” tradicionais em que as informações são mantidas em apenas um grupo.

Sprint Retrospective

Reunião retrospectiva ou "Retro" é o momento em que a equipe do Scrum lista o que correu bem e as melhorias em potencial que identificam como lições aprendidas. Trata-se de uma oportunidade de inspecionar e se adaptar. Os assuntos podem estar relacionados ao relacionamento da equipe, parceria com outras equipes da empresa e ao próprio processo, o que pode ser melhorado nos eventos, se houver uma ferramenta melhor para métricas e estimativas, etc. Dessa forma, a equipe inspeciona como foi a última Sprint em relação a pessoas, relacionamentos, processos e ferramentas, de acordo com o Guia Scrum.

É um evento de no máximo três horas para um Sprint de um mês. Existem várias maneiras divertidas de realizar esta reunião para permitir que todos os membros da equipa participem. O ponto principal é: reconhecer a equipa pelas realizações e, como resultado, o grupo deve identificar melhorias a serem implementadas durante a próxima Sprint, conforme as instruções do Guia Scrum.

Comente para que eu saiba que gostastes dessa publicação!

Partilhe com um amigo que possa ter interesse!

O título acima é um pouco confuso e vou tentar explicar :)

Primeiramente, sou uma Scrum Master que não é de TI, pois me formei em comércio internacional. Depois de cursar um MBA em Gerenciamento de Projetos, acabei no departamento de TI de uma empresa.

Eu estava lá para me tornar um gerente de projetos. No início, trabalhei acompanhando o andamento dos KPIs do projeto, fornecendo treinamentos para meus colegas de trabalho e trabalhando com documentação e melhorias de processo. Quando surgiu a oportunidade de transformação ágil, não havia mais gerentes de projeto na empresa, mas enfrentamos uma nova realidade: Scrum Masters, comunidades, tribos, esquadras, POs, Team Leaders etc.

Então, a equipa foi fundida com outra. Era uma equipa nova, mas ainda estávamos agindo como dois grupos diferentes. Para deixar claro, continuamos a trabalhar com documentos, processos e KPI's, mas a partir desse momento era para todo o departamento de TI, além dos projetos. Resumindo, éramos o departamento administrativo de TI. No entanto, não houve interação entre todos, mal sabíamos no que cada um estava a trabalhar.

Todas as novas equipas (Tribes e Squads) estavam se organizando e aprendendo a praticar o Scrum. Então, começaram a entregar os primeiros incrementos para produtos utilizáveis ​​enquanto ainda estávamos enviando relatórios, gerenciando contratos de fornecedores e criando todas as diretrizes para a "nova TI".

Então, identifiquei um alerta: fazemos parte de uma estrutura ágil, não desenvolvemos nenhuma aplicação, mas temos nossos clientes internos (equipas de TI), nossa missão é acompanhar o desempenho da TI e facilitar a vida das equipas de desenvolvimento. Dessa forma, “nós”, representando o departamento de TI, solicitamos às equipas de desenvolvimento que sejam ágeis, ansiosas por produtividade, criatividade, mas nós, como grupo administrativo, estamos trabalhando da mesma maneira como no passado?

Desde o início do discurso sobre “Agile Transformation”, estudei novamente as práticas do Scrum, li o Guia do Scrum inteiro, procurei alguns materiais sobre Kanban, SAFe, Nexus etc.

Entendo que sentiste dessa forma: quero ajudar minha equipa a trabalhar com práticas ágeis, mas não sei por onde começar.

Nesse caso, leia o guia principal de melhores práticas para a estrutura que escolheste. Para o Scrum, leia o Guia do Scrum, faça perguntas aos seus colegas de trabalho, caso haja alguém que já tenha trabalhado com isso para compartilhar experiências. Não há resposta certa ou errada, deves descobrir o que melhor se adapta à sua realidade.

Como segundo passo, tentei identificar as funções do Scrum na minha equipa. Percebemos que quem poderia nos orientar na priorização era nosso gerente, ele sabia o que a empresa esperava de nossa equipa para ajudar todo o departamento de TI e foi aberto a sugestões de como fazer isso. Nesse caso, ele era nosso PO..

Os outros colegas de trabalho em nosso grupo representaram a equipa de desenvolvimento. Mesmo se trabalhávamos sozinhos em algumas entregas, como cada um era responsável por um assunto diferente (fornecedores, KPIs, treinamentos e comunicação etc.), nós “desenvolvíamos” um serviço para a empresa consumir internamente. Por fim, trabalhei como Scrum Master ao auxiliar a equipa no prática do Scrum, ao mesmo tempo em que trabalhava nas entregas. Não é o cenário perfeito, mas temos que jogar o jogo e trabalhar com o que temos.

Em seguida, organizei  backlog do produto com a ajuda da equipa (sei que não era a PO, mas alguém deve fazer alguma coisa). Havia muitas tarefas rotineiras e isso foi evidenciado quando começamos a analisar o backlog em todas as reuniões de planeamento. Assim, adicionamos tarefas de melhoria contínua para agregar valor às entregas da empresa, como melhorias nos processos, comunicação com as outras equipas, eventos para explicar novas ferramentas e por que pedimos tantas informações ao departamento de TI como um todo para envolver as outras equipas.

No nosso caso, o PO não realizada o refinamento do product backlog. Então, eu costumava revisá-lo com a equipa e refinar os itens que foram priorizados pelo PO para estar tudo pronto para o planeamento.

Alinhei a agenda dos eventos do Scrum para garantir uma sala sem interrupções durante o planeamento, a revisão e o retrospetiva.

A reunião diária foi realizada em nosso local de trabalho, próximo ao nosso quadro Kanban. Realizamos uma reunião de pé, usando uma caneta ou uma pequena bola como um símbolo para evidenciar quem tinha o direito de falar e facilitar a atenção de todos. Nesta reunião, acompanhávamos o progresso da Sprint e tentávamos identificar impedimentos para ajudar a equipa.

Conclusão

O Scrum se encaixa em equipas de diferentes setores e não é algo que praticarás com facilidade de um dia para o outro. Ele é baseado no processo empírico e, quanto mais madura for a sua equipa, mais fácil será praticá-la e identificar as melhorias a serem implementadas.

Podes fazê-lo, só é necessário começar. Da mesma forma, durante uma transformação ágil, não haverá passo a passo ou receita a seguir. No entanto, deixei algumas dicas sobre o que entendi que funcionou para mim, pelo menos como um primeiro passo:

· Leia o guia de melhores práticas para a estrutura que escolheste;

· Caso sua empresa não esteja enfrentando nenhuma transformação ágil, verifique com sua equipa se concordam em praticar o Scrum ou a outra prática que escolheste. Verifique e garanta que sua equipa perceba que isso a ajudará a gerar resultados e valor para os negócios;

· Identifique qual é o produto ou serviço que sua equipa oferece e para quem;

· Identifique quais são as funções da sua equipa e como lidar com a abordagem de outras equipes, caso elas não trabalhem com práticas ágeis;

· Defina com sua equipa sobre a programação dos eventos do Scrum e quais são as ferramentas com as quais trabalharão para gerenciar o backlog do produto e o backlog da Sprint no início deste processo.

Comente para que eu saiba que gostaste dessa publicação!

Partilhe com um amigo que possa ter interesse!

No dia 08/03 comemoramos o dia internacional da mulher em que lembramos da luta de nossas antepassadas pelos direitos e liberdade que hoje temos. A realidade que nossas avós vivenciaram foi muito diferente da nossa e felizmente tudo mudou.

Preconceitos ainda ocorrem, mas entendo que nosso papel atualmente é tratarmos a nós mesmas com respeito e como os demais, sem diferenciação. Quanto silos criamos, maior o preconceito. Somos profissionais, humanas, mães, irmãs, cidadãs. Assim como os homens são profissionais, humanos, pais, irmãos e cidadãos.

Recentemente em um evento que participei ouvi um comentário de uma mulher 10 anos mais velha que eu a dizer-me: és tão confiante ao apresentar-se e ao falar sobre seu trabalho e sua experiência profissional apesar de ser tão jovem. A mesma perguntou-me se alguma vez senti-me prejudicada ou enfrentei alguma situação de preconceito por ser jovem e mulher a trabalhar em equipas com homens e muitas vezes mais experientes do que eu.

Ao refletir para formular a resposta percebi que não havia enfrentado nenhuma situação parecida. Ao menos, não interpretei nenhuma das minhas dificuldades atreladas a ser mulher, mas sim por ser jovem em áreas nas quais não tinha experiência.

Claro, já ocorreram episódios em que percebi a falta de confiança das pessoas em mim ou no meu trabalho, mas apenas inicialmente porque ainda não tinha experiência. Ao passar dos dias, demonstrava que estava disposta a aprender e que sabia cooperar. Por fim, através do meu trabalho passaram a confiar em mim.

Mas o mais importante é que eu passei a confiar em mim mesma, dificuldade essa que confesso que enfrentava. Houve momentos em que culpava o mundo por ser tão injusto, as pessoas por não se importarem com as demais, às empresas por não dar mais oportunidades.

Porém, felizmente reaprendi que somos nós os responsáveis pelo nosso destino. Quanto mais confio em mim, no meu potencial, no meu trabalho e na minha capacidade de aprender, mais as pessoas confiam em mim.

Fico muito feliz por ainda estar a aprender “o que quero ser quando crescer”, assim aprendo coisas novas todos os dias e tenho mais possibilidades de aumentar meu leque de atuações. Sou um ser em evolução e assim espero prosseguir.

Não apenas nessa data especial, mas todos os dias devemos buscar o respeito mútuo, não porque somos mulheres, porque somos humanas.

Qual o impacto no seu trabalho dessa nova rotina que o mundo está a enfrentar? Há quem já estava a trabalhar no futuro e não percebeu muita diferença. Da mesma forma, lembre que antes mesmo de passares a iniciar reuniões online, talvez já tinhas aquele colega de trabalho de outra cidade ou país que era o únicio que participava das reuniões via video chamada. Agora também estás no lugar de tal pessoa, entendes as dificuldades em se conectar, ao tentar falar sem interromper o outro etc. 

Sendo assim, que esse momento também seja uma inspiração para reuniões mais produtivas independentemente se online ou posteriormente presenciais, e que sejam inclusivas aos que estão a trabalhar remotamente.

Tomei a liberdade de informar abaixo boas práticas que partilhamos em um meet up do grupo que participo sobre Liberating Structures de Lisboa. Foi realizada nessa ano uma sessão em que discutimos como ter reuniões mais produtivas. Algumas das dicas abaixo eu já praticava e outras aprendi com a equipa Liberating Structures. Segue tais dicas:

• Definir previamente as perguntas que devem ser respondidas ao longo da reunião para que um problema seja solucionado, uma decisão seja tomada e enviar a todos juntamente com o convite;

• Deixar claro o local, horário e qual a ferramenta utilizarão para conectar-se. Se há alguém em fuso horário diferente, informar sobre o horário do encontro em todos os fusos relevantes para a equipa;

• Solicitar que os participantes entrem na reunião com no máximo 5 minutos de antecedência para que possam conectar-se, testar o áudio e o vídeo sem atrasar o início do encontro;

• No início ou previamente à reunião, realizar um acordo com as regras com a equipa. Entendo que duas regras são importantes a seguir e acordar em equipa: lembrar do período em que ainda não utilizávamos os telemóveis e não distrair-se com os mesmos ao longo da conversa e utilizar do recurso de vídeo em reuniões online.Essa segunda regra auxilia que todos prestem atenção no que estão a falar, sem distrair-se com tarefas a realizar e também pode-se perceber as expressões e reações dos demais participantes o que facilita a conversa e gera empatia;

• Definição de papéis: ao iniciar uma reunião realizar a definição prévia de papéis: quem será o facilitador, quem realizará as anotações, se haverá alguém que represente a visão do cliente etc.

• Importante que o responsável por ser o facilitador compartilhe sua tela relembrando o objetivo da reunião. Quando voltarmos à antiga realidade e caso ainda existam reuniões presenciais, tal objetivo pode ser escrito num quadro ou na parede.

• Realizar um breve check-in ao iniciar a reunião ao perguntar para que cada um expresse o que espera da reunião ou também partilhar quem está a trabalhar com os filhos em casa, como estão a divertir-se ou ainda qual música estavam a ouvir antes da reunião.

• Delimitar o tempo disponível em que cada um estará a falarou trazer soluções para um problema. Da mesma forma, delimitar o tempo por pessoa ao realizar o check-in e check-out. Dessa forma, todos participam e aprendem a expressar-se de forma mais objetiva.

• Para reuniões presenciais, ter um talking stick ajuda. Trata-se de eleger um objetivo que indique a vez de quem está a falar para que os demais pratiquem a escuta ativa. Em reuniões online, pode-se definir uma sequência  sobre quem falará, por exemplo.

• Realizar o check-out  ao fim da reunião para analisar se o objetivo da reunião foi atingido, se as perguntas foram respondidas e qual o plano de ação definido com prazo e responsáveis por cada ação.

O uso de jogos nas reuniões também pode ser uma maneira divertida e também de orientação para reuniões. Um exemplo é o jogo Go Minimal que utiliza cartas com perguntas estratégicas para planeamento. Elas podem ser usadas no check-in e check-out e também caso o objetivo da reunião seja planear, definir tarefas ou atuar na solução de um problema. Além do jogo impresso há também como partilhar tais cartas para que sejam utilizadas durante a reunião online.

Comente sobre essa publicação para que eu saiba que gostaste!

Conhece alguém que poderia aprender mais sobre reuniões produtivas? Partilhe essa publicação!

Gostava de saber mais sobre o uso de jogos em reuniões? Entre em contacto através dos meus canais gabioliveira.pt, telefone ou e-mail.

Estou à disposição!