Retropg: Uma retrospectiva Scrum utilizando RPG

Um app antigo em sua quarta versão, com um time extremamente focado (e cansado haha) a retro final do projeto precisava ser algo divertido e que criasse um ambiente seguro para que todos pudessem falar livremente e fechar esse ciclo.

Um grande desafio surgiu: qual estrutura usar na retro? nós, facilitadores, temos dinâmicas para os mais variados contextos mas, para essa em especifico, parecia tudo muito mais do mesmo. Tinha que ser algo diferente que realmente engajasse o time (que fez um trabalho excepcional ❤).

Comecei a pensar no perfil de cada um, o que ouviam, o que liam, o que faziam no tempo livre e essa atividade foi uma grande descoberta pra mim. Lembrei que os meninos sempre almoçavam rápido para jogar RPG e.. wtfff o que é RPG? hahaha

Role-playing game, também conhecido como RPG, é um tipo de jogo em que os jogadores assumem papéis de personagens e criam narrativas colaborativamente. O progresso de um jogo se dá de acordo com um sistema de regras predeterminado, dentro das quais os jogadores podem improvisar livremente.

Depois de ler essa breve descrição fiquei extremamente entusiasmada: achei a estrutura perfeita para fazer a retro final do projeto. Sabia que o desafio seria grande então convidei o tester do projeto para me ajudar a estruturar. Se você nunca contou com um membro do time para te ajudar a planejar a retro, experimente o/ é uma experiência muito enriquecedora!

O app é uma agtech que facilita o dia-a-dia do produtor rural através de ferramentas para o manejo, gestão e proteção da lavoura. Partindo deste contexto a história começou a ganhar forma..

Era uma vez em uma terra muito, muito distante em uma vila de camponeses que plantavam soja e não tinham um agrônomo pra ajudar. Surgiu um grande mago que concedeu um artefato mágico (o app) para ajudar os camponeses

Os camponeses eram muito felizes usando o artefato mágico e isso gerou muita inveja da vizinhança que enviou um demogorgon para atacar a vila

Então, 7 bravos guerreiros deveriam lutar para salvar as terras e proteger o artefato mágico:

Cada membro do time era um personagem de RPG e tinha um poder (dano ou cura):

Conforme a história se desenrolava e o dado girava, o time deveria fazer uma das 8 ações:

Para o texto não ficar muito extenso, vocês podem conferir os slides aqui 😉

O resultado? a retro mais divertida que já facilitei hahah todos, sem exceção, falaram de forma transparente e conseguimos várias feedbacks para o crescimento do time e de cada um.

O recado que quero deixar é: passamos a maior parte do tempo no trabalho e, muitas vezes, não nos conhecemos o suficiente para extrair o melhor de cada um. Antes de organizar uma retro, reflitam profundamente sobre o time e como o melhor ambiente pode ser criado, ousem e não tenham medo de arriscar algo novo.

Texto por: Maria Fernanda Marcotti

Times Scrum – Como facilitar as fases de formação?

Texto por Bianca Pereira

No texto anterior, entendemos um pouco mais a analogia entre o time de scrum e o de futebol (clique para ler). Vimos brevemente como as equipes são compostas e entendemos melhor os papéis que cada um desempenha.

Hoje conversaremos melhor sobre as fases de formação de times e como arbitrá-las até a equipe se estabilizar na partida.

Em 1965, o psicólogo Bruce Tuckman publicou um estudo apresentando as quatro etapas de construção de um grupo e o comportamento das pessoas em cada momento.

Formação e conflito

O primeiro estágio, chamado de “formação”, envolve a apresentação, o entrosamento inicial dos membros, entendimento do “jogo” e reconhecimento das outras posições.

O facilitador ou Scrum Master, analogamente ao juiz da partida, exerce um papel diretivo para equipe, trazendo pontos de atenção relacionados ao objetivo do projeto. É o momento de mostrar as regras do jogo que precisam ser seguidas: prazos, cerimônias do Scrum, objetivos de entregas.

No segundo momento, a equipe tende a entrar na fase de “conflito”.  É quando os ânimos ficam exaltados e a pressão da vitória atinge todos os membros do time. Surgem, então, os carrinhos, os puxões de camisa, as defesas irregulares e o juiz precisa ser mais incisivo em relação às regras.

Alguns times podem tentar evitar essa fase, camuflá-la ou negá-la. Porém, é importante que scrum master ou facilitador do projeto ajude a trazer esses problemas à tona.  Só assim o grupo poderá reconhecer o conflito e chegar a uma solução em conjunto.

Estabilização e desempenho

Depois da tempestade, vem sempre a calmaria e é por isso que após muitas faltas marcadas e cartões distribuídos, os times entram na fase de “normatização”, seguida pela etapa de “desempenho”.

Esse período de estabilidade ocorre porque os membros resolveram os conflitos e passam a reconhecer os pontos fortes uns dos outros, trabalhando com sinergia para suprir as lacunas em direção ao mesmo objetivo.

O juiz continua a exercer um papel de apoio, mas sua interferência torna-se cada vez menos necessária. O time começa a adquirir independência e alta performance.

Uma partida de futebol e projetos de scrum não são eventos lineares. Alguns acontecimentos podem levar times já estabilizados novamente ao conflito. Isso acontece por exemplo, com a entrada e saída de membros, mudança na priorização de entregas, trocas de papéis, discordância de técnicas, entre outras inúmeras situações. Nesse caso, cabe ao juiz ser imparcial e diretivo fazendo valer as regras do jogo visando ao resultado esperado.

Para além da teoria, cada jogo e cada time tem sua particularidade. Imagine-se sendo árbitro de uma disputa entre Flamengo x Macaé ou São Paulo x Portuguesa, parece algo dentro do “roteiro”, certo? Agora, coloque-se como juiz em um jogo entre, por exemplo,  Flamengo x Fluminense, Grêmio x Internacional ou ainda, Palmeiras x Corinthians e algumas outras variáveis entram em questão. Mas isso é papo para outra hora, por hoje, fim de jogo.

Times Scrum – Quem não sonhou em ser um jogador de futebol?

Texto por Bianca Pereira


Todo amante de futebol sabe a importância que faz um time bem estruturado em uma partida. As posições precisam ser estrategicamente definidas e preenchidas com os jogadores responsáveis, é preciso treinar diariamente para evoluir a técnica e, principalmente, o time precisa estar entrosado.

Muitas vezes temos jogadores com muita habilidade em campo, mas se não houver o tal do entrosamento do grupo, nada feito! Então acontecem passes perdidos, bola na trave, bola na área sem ninguém pra cabecear, e daí, o choro é livre.

Quem já trabalhou utilizando o Scrum, sabe que funciona da mesma maneira. Para entregar um projeto baseado nesse framework, a construção de um time colaborativo é essencial. Isso vai além do domínio de técnicas avançadas de desenvolvimento e abrange a capacidade de adaptação, inspeção e transparência da equipe para com o jogo em si.

Para chegar nesse patamar é preciso, claro, muitos treinos, muitos jogos, adversários “fáceis”, aqueles mais complicados, muita falta apitada e alguns cartões pelo caminho.

Papéis do time scrum x time de futebol

Para contar essa história direito, vamos explicar os papéis do Scrum dentro de campo e veremos como os times são formados. 

time2-1

 

Product Owner (Goleiro/Capitão do Time)

A principal função do PO é traduzir os interesses do cliente em valor, priorizar isso de forma assertiva e comunicar o que será ou não feito para o restante da equipe. Como capitão, é ele quem vai motivar as pessoas em relação ao negócio e mostrar o porquê de aquilo estar sendo feito. Além disso, ele também precisa defender o time dos itens que fogem do objetivo a ser entregue.

Na formação de times colaborativos, tanto de futebol quanto de Scrum, essa é uma atribuição fundamental. “Falem um com outro, cobrem um do outro, ajudem um ao outro, queiram ganhar um com o outro” é parte de uma famosa preleção de Rogério Ceni que poderia ser facilmente usada em uma Daily Scrum.

Gosto de fazer a analogia do PO com o goleiro, pois ele é um indivíduo um pouco distinto, joga com os pés, mas sobretudo joga com as mãos e posicionamento. Não tem como jogar sem ele, e dificilmente conseguimos substituí-lo por um jogador de linha.

Time de desenvolvimento (Jogadores de linha)

Colocando um objetivo em comum a ser alcançado em cada caso, desenvolver sistemas pode ser comparado a vestir a camisa e chutar a bola no gol. Veja que nessa situação não há diferenças entre quem desenvolve, quem testa, quem valida requisitos ou quem desenha fluxos, todos buscam o mesmo foco e contribuem de acordo com sua posição em campo.

Scrum Master ou Facilitadores (Juízes)

Os juízes são responsáveis para que a partida aconteça de acordo com as regras do futebol, enquanto o Scrum Master ou Facilitador garante que os princípios do Scrum sejam desenvolvidos no decorrer do jogo. Cabe a ele comunicar esses preceitos da melhor forma e fazer com que a equipe consiga avançar os estágios de formação durante o projeto.

A regra é clara e quando a situação sai do roteiro, ele precisa se posicionar, direcionar a disputa e conduzir os times. Muitas vezes alguns podem achar que árbitros são desnecessários e o melhor seria que sua função não fosse percebida. De certa forma, isso é verdade, porém, são nos jogos complicados que essa figura torna-se fundamental para o desenvolvimento do time e jogo.

Como nem tudo são flores, as equipes podem estar desfalcadas em algumas situações e o time precisa se adaptar para suprir esses hiatos. Defesas são feitas por laterais, gols são marcados por zagueiros. Mas por mais que a equipe passe por uma etapa de conflito, com muito treino, ela consegue se desenvolver e caminhar para melhores resultados.

Formação de times

time1-1

Tanto no futebol quanto no Scrum, a formação de times colaborativos e auto gerenciáveis não é algo simples. Você escolhe os jogadores responsáveis por cada posição, apresenta os outros membros e tudo vai bem, até colocá-los para trabalharem em equipe. 

Em 1995, após ter sido eleito o melhor jogador do mundo, Romário desembarcava na Gávea. Pouco tempo depois era a vez do campeão brasileiro Edmundo e o “melhor ataque do mundo” estava formado. Parecia que o puro talento dos seus jogadores renderia incontáveis títulos ao Flamengo, mas um elenco vitorioso precisa ser um time antes de tudo.

O grupo durou apenas 6 meses apresentando problemas de gestão, estrutura, organização e estilo de jogo. Próprios ex membros da equipe a classificavam como “uma bagunça”. O que deu errado?

Equipes de scrum passam por processos semelhantes, o grande desafio é auxiliar que elas se desenvolvam e atravessem as fases de formação e conflito. Chegar à estabilidade e alto desempenho em um projeto é um desafio diário que requer muito treino. Será que sua equipe está preparada? Falaremos mais disso no nosso próximo post, por hoje, fim de jogo. 

 

Nossas Retrospectivas

Todo mês fazemos as famosas Retrospectivas na Jera. Quando falamos de SCRUM, as retrospectivas acontecem ao término de cada Sprint, fazemos essa também, mas limitada ao time que está trabalhando no projeto. Esse post se trata das retrospectivas envolvendo toda a equipe.

Sempre que penso nesse assunto, me lembro de um artigo do Manuel Pimentel que trata de forma bem prática, se você não está familiarizado com o termo, recomendo a leitura antes de prosseguir.

Mas, na verdade, o conceito de retrospectiva só nos remete a um assunto que é velho conhecido do pessoal de administração, que é o famoso PDCA. O objetivo de ambos é promover melhoria contínua!

Legal, apesar de ser um assunto aparentemente simples, melhoria contínua trata-se de um dos maiores desafios para qualquer empresa ou pessoa. Para melhorar é preciso saber o que não está bom, e para isso é preciso de humildade para entender e aceitar nossos erros.

As retrospectivas da equipe aqui na Jera sempre causam espanto aos que acabaram de começar conosco. A gente sempre segue o princípio da honestidade, sendo que o todos são encorajados a dizer o que estão sentindo, o que está incomodando e claro, o que deu certo.

Só consideramos que isso seja possível graças a ausência de hierarquias e cobranças “comuns” como pontualidade ou qualquer tipo de formalidade no tratamento. Sentir-se à vontade no trabalho para nós é obrigatório e se algo está te impedindo de conseguir isso, a retrospectiva é o momento certo para discutir o ponto.

Foto: Pizza por Haseo

Agile Coaching

Recentemente terminei um trabalho em um cliente* onde ministrei um treinamento sobre gerenciamento ágil de projetos e agora estou fazendo um trabalho de coaching ajudando-os na utilização das técnicas nos projetos. Eles têm uma equipe de cerca de 10 pessoas entre analistas de negócio, DBAs e desenvolvedores. Trabalham também um uma fábrica de software que atende a maioria das solicitações de desenvolvimento.

Inicialmente, para melhorar a visibilidade do processo e conseguir gerar e coletar alguns indicadores, montamos um Kanban contemplando todos os projetos e analistas de negócio responsáveis e organizando as atividades pendentes com os desenvolvedores.

A partir desse trabalho, participo semanalmente da retrospectiva da equipe onde avaliamos os pontos positivos e implementamos novas melhorias. Vou fazer esse trabalho com eles por mais umas cinco semanas com o objetivo de identificar os pontos que precisam ser melhorados em uma nova fase da consultoria.

Disponibilizei todo o material usado no treinamento no meu slideshare organizado por aulas:

  1. Abordagens Ágeis (Parte 1)
  2. Abordagens Ágeis (Parte 2)
  3. Casos de Uso
  4. Histórias do Usuário
  5. Planejamento do Projeto
  6. SCRUM e Kanban

* Infelizmente ainda não posso mencionar o nome do cliente, mas em breve pretendo escrever mais sobre o trabalho.