Categorias
Sem categoria

Dicas para a PSPO I

Afinal, como se preparar para a PSPO I?

Ela é parecida com a PSM I?

Eu preciso fazer a PSM I primeiro?

Existem muitas dúvidas nessa hora, principalmente, quando se trata de certificação. Mas, irei contar para vocês como foi essa experiência para mim.

Comecei pela PSM e uns meses depois decidi arriscar a PSPO. As duas certificações são bem parecidas, inclusive, uma pergunta ou outra se repete nas duas. Porém, fazer a PSM primeiro me deu uma boa base para a PSPO, tendo em vista que ela tem umas perguntas bem mais especificas e complexas.

Se você tem condição de fazer as duas, eu aconselharia a PSM e depois a PSPO, mas senão, encarar a PSPO de cara não é um bicho de 7 cabeças também. Deixo abaixo dicas do que estudar para ela.

Ler o Scrum Guide, vejo como primeiro passo. Afinal, neste guia está descrito detalhadamente o que é o SCRUM e são apenas 20 páginas. Comece por ele, entenda este Framework e como ele funciona, tendo em vista que a maioria das perguntas são escritas da mesma forma que está escrito nele. Estude ele, pelo menos, umas três vezes antes da prova.

Resuma-o em tópicos, e lembre-se, não existe tópicos que são importantes ou não, tudo é de grande importância e entender cada processo é fundamental para ter êxito. Mas, ler somente ele não é o suficiente para agregar todos os conhecimentos necessários para a certificação. Então, você deve estar se perguntando, o que mais estudar?

Nexus Guide, é outro guia de suma importância, que explica o Scrum Escalado, outro Framework que se baseia no Scrum. 

No Nexus você compreende detalhes que são cobrados na prova e aprende a trabalhar de outra forma com o Scrum, por exemplo, ter apenas um Backlog de produto, independente de quantos times de desenvolvimento você tenha. Então, saber como esse Framework trabalha, é fundamental.

Outra forma de estudar e treinar seus conhecimentos adquiridos até aqui, são os simulados da Scrum.org, eles são ricos de informações explicativas sobre o tema de cada pergunta. Auxiliam a compreender muitos detalhes que, muitas vezes, passam batido na leitura do Scrum Guide. Recomendo faze-lo até atingir no mínimo 95% de acerto, pois eles são uma ótima base do que esperar da prova. 

E também como apoio, deixo abaixo alguns tópicos que são bastante questionados nas perguntas.

Cerimônias / Eventos Scrum

  • Planning – Ter em mente que a planning é uma reunião de planejamento para a Sprint que começa a seguir, composta por duas partes, o que fazer e como fazer, seu time-boxed é de até 8 horas para Sprint de 1 mês (máximo permitido) e todos do time scrum participam.
  • Reunião diária – Reunião realizada todos os dias no mesmo lugar e hora para evitar complexidade pela a equipe de desenvolvimento, sua duração é de até 15 minutos. O PO não participa e o SM não há necessidade de estar. Nesta reunião é sugerido pelo Guide responder a 3 perguntas: 
    • O que eu fiz ontem para atingir a meta da Sprint?
    • O que eu farei hoje para atingir a meta da Sprint?
    • O que está me impedindo de atingir a meta da Sprint?
  • Review – Reunião para colher feedback das partes interessadas, a qual o incremento potencialmente liberável é mostrado pelo time de desenvolvimento ao PO para ser aceito ou não, sua duração é de até 4 horas para Sprint de 1 mês. Todos do time Scrum participam e os stakeholders podem ser convidados.
  • Retrospectiva – Reunião realizada pelo time Scrum para analisar o que foi bom, o que foi ruim na Sprint e o que deve ser melhorado para a próxima. Tendo sua duração de até 3 horas para Sprint de 1 mês. Todos do time Scrum participam, inclusive o PO como parte do time.
  • Refinamento – Normalmente é realizado em Sprints anteriores com o PO, Scrum Master e não pode consumir mais de 10% do tempo do Time.

Artefatos

  • Product Backlog – Lista de histórias de usuário feita pelo PO com todas as exigências dos Stakeholders. Vale ressaltar que existe apenas um Product Backlog por produto.
  • Backlog da Sprint – Itens do Product Backlog priorizados e refinados, de responsabilidade da equipe de desenvolvimento, com as tarefas a serem realizadas na Sprint.
  • Incremento potencialmente entregável – Resultado de uma execução de sprint.

Papéis

  • Product Owner – Responsável por tratar os interesses dos Stakeholders, montar e priorizar o Product Backlog e garantir que o produto tenha um maior valor em sua entrega. Ele é o único que pode cancelar uma Sprint. Vale relembrar que ele não é um comitê, mas pode representar as vontades de um. 
  • Scrum Master – Garante que o processo aconteça de forma correta dentro de seus time-boxed, retira os impedimentos do time de desenvolvimento, e apoia o PO caso seja necessário. É um líder-servidor que aplica práticas de liderança coach.
  • Time de desenvolvimento – Time auto organizável, ninguém os diz como trabalhar, nem mesmo o Scrum Master. Responsável pelo Backlog da Sprint e execução das tarefas. São eles que estimam os itens do backlog do produto e é composto por 3 a 9 pessoas.

Outros

  • Definição de Concluído – Definição de quando os itens do product backlog selecionados para a sprint estão concluídos; é determinado pelo time Scrum e gera transparência para todos.
  • Pilares – Transparência, adaptação e inspeção.
  • Valores Scrum – Coragem, foco, abertura, comprometimento e respeito.

Obrigada por terem ficado com a gente até aqui.

Amanna Monteiro – Família Sunsetti.

Categorias
Sem categoria

Seja Ágil!

Os processos ágeis estão cada vez mais ganhando o mercado por estimular a inovação, a colaboração e a capacidade de adaptação, isso é um fato!

Ok, mas a minha empresa ou a organização em que eu trabalho ainda não utiliza essas práticas, o que posso fazer?

Neste artigo falarei de alguns comportamentos e práticas da agilidade que você pode desenvolver para ser ágil no seu dia a dia e influenciar de maneira colaborativa.

Como dizia Michel Jordan: Colabore mais, compita menos, o que isso quer dizer? Que você só terá sucesso se conseguir auxiliar o restante do time a alcançar o objetivo, não se compare com os colegas e demonstre disponibilidade para ajudar quando puder, perguntando como poderia ser útil para o trabalho do outro.

Diminua o desperdício, elimine hábitos que minimizam a sua produtividade e esse é um dos pilares ágeis, como por exemplo, burocracias sem sentido, multitarefas e excesso de trabalho, causados por falta de planejamento, foco e metas surreais estabelecidas pela alta gestão, evite atos heroicos para obter reconhecimento. 

Foco no que interessa, o ideal é que você se concentre em uma tarefa por vez, criar metas e objetivos alcançáveis, organize-se para cumprir as suas metas sem necessitar de horas extras. Esforços exacerbados são vistos como falhos e demonstração de desorganização.

Seja mais flexível, é preciso ter humildade para reconhecer que todos nós podemos errar, não temos por obrigação ter as melhores respostas e saber tudo. Raramente tudo o que planejamos se transforma em realidade. Ser ágil é desenhar uma ideia, um esboço de onde você quer chegar, mas tem abertura e flexibilidade para se adaptar quando uma ideia nova ou problema surgirem. Tente se observar ao reproduzir um comportamento semelhante e reduza-o aos poucos.

Defina o que fazer primeiro, você pode começar se perguntando: quais projetos ou atividades podem gerar mais dinheiro e são mais fáceis de realizar? O diagrama de pareto é uma importante ferramenta da gestão da qualidade, utilizada amplamente no mundo, no qual pode ajudar a estabelecer prioridades, pois 80% do valor de um serviço ou produto, está apenas em 20% de suas funcionalidades, ou seja, apenas um quinto do que foi desenvolvido pelas empresas realmente tem valor.

Reavalie o seu trabalho com frequência (e de seus colegas), times ágeis organizam projetos em ciclos curtos, pois precisam ao final de cada cerimônia, analisar o que foi feito. O intuito não é avaliar, apenas como o processo foi conduzido, mas também o desempenho da equipe e o resultado em si, ou seja, o que deu errado, o que deu certo e como pode ser melhorado. 

Pratique o feedback propositivo, a ideia é que se propicie a cultura do feedback propositivo, onde não é focado e procurar culpados por erros. E para que funcione é preciso que todos se responsabilizem de forma coletiva, tenha inteligência emocional madura suficiente para abordar questões incômodas com outros colegas sem ofender e ouvir críticas sem ficar na defensiva.

Para se adaptar a esse novo modelo é preciso repensar a sua forma de trabalhar e de se comportar de maneira mais colaborativa, é necessário desapegar para deixar as coisas fluírem mais rapidamente, seja mais tolerante ao erro, organize-se de forma mais racional.

Acredite mais, as coisas vão acontecer e você vai se surpreender!

Um grande abraço, até breve!

Brenda Nogueira – Família Sunsetti

Categorias
Sem categoria

Barômetro do Time – Como está o clima do seu time?

Procurando alguma outra forma para fazer a retrospectiva com o time Scrum?

Uma forma de diversificar e até mesmo trazer outras soluções para melhoria contínua?

Aqui está uma sugestão que usamos para diversificarmos esses eventos com os times que implantamos o ágil com Scrum e acompanhamos.

O Barômetro é um instrumento científico utilizado para medir a pressão atmosférica, também conhecido como barômetro de Torricelli, mas o que isso tem a ver com o nosso time? Precisamos medir a temperatura para saber como está o andamento do time.

O nome Team Barometer no português Barômetro do Time foi utilizado pelo Lean & Agile Coach de Jimmy Janlén da Suécia, autor do livro Toolbox for the Agile Coach – Visualization Examples com tradução em 6 idiomas e falaremos neste artigo a respeito dessa dinâmica abordada neste livro.

Frequentemente as retrospectivas se resumem em resolver problemas ou como melhorar o trabalho, ou seja, com foco somente no processo e ferramentas. E por vezes, a reunião toma outros caminhos devido a questões comportamentais não trabalhadas, como por exemplo: levar questões de impedimento e qualidade para o lado pessoal; até mesmo a forma como se dá um feedback pra um membro do time pode causar constrangimentos e desentendimentos com o time. Assim, outros membros do time acabam se sentindo intimidados em expor suas opiniões e optam por não falar nada na ocasião.

É essencial investirmos tempo para falar sobre o clima do time, entender como a confiança está sendo construída, trabalhar a liberdade de expressão sem ferir e também aceitar críticas de uma perspectiva mais positiva e construtiva a fim de tornar o time unido e mais engajado de verdade.

A dinâmica do Team Barometer (Barômetro do Time) proposta pelo Jimmy Janlén é para que haja interação do time, por meio da facilitação visual e tudo isso é feito de forma muito simples. São apresentadas diversas questões ou temas para que o time faça uma votação sobre cada assunto abordado.

Os temas dos cartões são baseados no livro “As cinco disfunções de um time” de Patrick Lencioni e outros autores. O link de algumas sugestões traduzidas em português dos cartõesestará disponível ao final deste artigo.

Como funciona:

– O facilitador da dinâmica, no caso o Scrum Master ou Agile Coach, antes de iniciar a mesma deve selecionar alguns cartões para a dinâmica (recomenda-se de 10 a 12 itens) para que a votação não fique maçante e haja tempo hábil para discutir todos os itens e propor ações de melhorias. O time amadurecendo nos temas propostos, novos assuntos podem ser escolhidos, criados e substituídos.

– O facilitador apresenta a dinâmica e o significado dos cartões ao time antes de inicia-la.

– Cada cartão possui um título que descreve uma característica do time e duas frases explicando aspectos positivos e negativos do assunto, representados respectivamente pelas cores verde e vermelha como apresentado na figura abaixo.

– O facilitador distribui para os membros do time cartões nas cores vermelho, amarelo e vermelho e começa a ler o cartão antes de cada votação.

– Este terceiro passo é muito importante e deve ser enfatizado durante a dinâmica que cada membro do time vota, segundo a sua percepção sobre o comportamento do time mais parecido em relação ao aspecto positivo ou negativo. A votação não deve refletir o comportamento da pessoa que vota, mas sim sobre como a equipe se comporta.

– Todos votam simultaneamente, levantando o cartão verde quem concorda com o aspecto positivo e vermelho com o negativo. O verde e vermelho representam os extremos no comportamento de um time (raramente um time inteiro se encontra em um único extremo), mas busque escolher os extremos mais condizente com a realidade do time, senão, escolha o amarelo.

– Os cartões selecionados e votados devem estar no board (quadro) do time para que, de forma objetiva e visual, esteja ao alcance do time, conforme o exemplo abaixo:

* Se o time estiver remoto existem ferramentas eletrônicas como a miro.com ou até mesmo planilhas online, pode auxiliar neste sentido.

– Após realizar a votação de todos os cartões, o time deve discutir cada item e principalmente os vermelhos, onde cada integrante de forma espontânea e transparente exponha sua percepção do aspecto negativo do time, o facilitador deve instigar o time a propor ações de melhoria e monitorar os resultados.

O Barômetro do Time é uma forma eficaz de medir e monitorar a temperatura do time, mantém o anonimato e a privacidade, motivo pelo qual os membros dos times naturalmente aderem essa dinâmica. Auxilia o time a se apropriar de uma mentalidade mais colaborativa, a perder o medo do conflito, além de aumentar o comprometimento e a confiança do time para entregar melhores resultados.

Clique aqui para download dos cartões do barômetro do time.

Obrigada por terem ficado com a gente até aqui.

Um abraço,

Brenda Nogueira – Família Sunsetti

Categorias
Sem categoria

Daily Scrum: O que é e qual a sua importância?

Daily Scrum! 

O time de desenvolvimento chega atrasado na daily (reunião diária)?

Nunca ou raramente têm impedimentos?

A reunião extrapola com frequência o time-boxed de 15 min?

Você não tem ideia se o seu time vai alcançar a meta da sprint? 

Hummmmm, alguns desvios no processo do framework Scrum ou até mesmo falta de entendimento da importância desse evento podem estar ocorrendo com o time.

A reunião diária traduzido do inglês Daily Scrum é um evento, também conhecida como cerimônia do framework Scrum, que deve ser realizada todos os dias da Sprint, e nos dias de planning (planejamento), review (revisão) e retrospective (retrospectiva) não há necessidade. Neste evento participa o time de desenvolvimento e nela o time planeja o trabalho para as próximas 24 horas. O local e hora é mantido sempre os mesmo para reduzir complexidade.

A daily não é uma reunião de status report para informar se o projeto está em atraso ou em andamento com relatório de velocímetro e tão pouco ler post-it. Ela tem como principal objetivo disseminar o conhecimento sobre as ações e atividades a serem realizadas pelo time de desenvolvimento, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia, assim como também identificar se o time vai alcançar a meta da sprint.

Durante a reunião diária é sugerido pelo ken schwaber e jeff sutherland no Scrum Guide, que cada membro da equipe responda a três perguntas que ajudam o time a focar no que realmente é necessário e evita aquelas reuniões sem foco que ficam intermináveis… são essas:

“O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir a meta da Sprint?

O que eu farei hoje para ajudar o Time de Desenvolvimento a atingir a meta da Sprint?

Eu vejo algum obstáculo que impeça a mim ou o Time de desenvolvimento no atingimento da meta da Sprint?”

Mas, isso é sugestão, pois cada time pode adotar sua própria técnica, desde que consigam mapear os impedimentos para o Scrum Master e verificar se estão no caminho para alcançar a meta da Sprint.

O time de desenvolvimento, ao responder estas perguntas, coloca em prática os três pilares do Scrum que são: inspeção, adaptação e transparência. 

“Inspeciona” o progresso em direção ao objetivo da Sprint e se está na direção de completar o trabalho do Backlog da Sprint (conceito de concluído que traz na prática o pilar “transparência”). Essa reunião aumenta a probabilidade do time de desenvolvimento alcançar o objetivo da Sprint. Com frequência o Time de desenvolvimento se encontra imediatamente após a reunião diária para discussões mais detalhadas e assim tem a oportunidade de poder “adaptar” ou até mesmo replanejar o restante do trabalho da Sprint.

O Product Owner não deve participar da cerimônia e o Scrum Master deve facilitar, garantir que o evento aconteça e ensinar o time de desenvolvimento a importância e os benefícios que os eventos Scrum podem trazer a todos, além de garantir que ninguém externo ao time atrapalhe. 

Alinhe essas questões dentro do time Scrum e aproveite para extrair o melhor em prol do alcance do objetivo criando ambiente propício para um maior engajamento de todos.

Esperamos que tenha gostado de ficar até aqui com a gente e que realmente isso faça sentido para você e sua equipe.

Grande abraço e até mais,

Brenda Nogueira – Família Sunsetti

Categorias
Sem categoria

Boas práticas para uma Review Meeting

Sprint Review, momento onde o time revisa o que foi desenvolvido durante o sprint e recebe o feedback sobre o incremento do produto potencialmente liberável.

Ok, mas como funciona? Quem participa? O que é esperado como resultado deste evento?

A sprint review é um momento de adaptação e inspeção e é tão importante quanto os demais eventos (planejamento do sprint, sprint, reunião diária e retrospectiva). Tem um tempo máximo para realização (conhecido como time-boxed) de até 4 horas para sprints de 30 dias (4 semanas), até 3 horas para sprints de 20 dias (3 semanas) e até 2 horas para sprints de 10 dias (2 semanas).

Neste evento participa o scrum master (SM), o time de desenvolvimento, o product owner (PO) e convidados (stakeholders do projeto).

É o momento em que o time de desenvolvimento demonstra o que foi desenvolvido durante o sprint ao PO e às partes interessadas (se convidados). O PO avalia se a meta do sprint foi atingida, faz anotações que poderão se transformar em novos itens para o product backlog, atualiza o mesmo colocando como “itens concluídos” os que já foram entregues e reprioriza caso necessário.

O resultado deste evento é que o PO pode aceitar; aceitar com ressalvas ou até mesmo rejeitar o resultado caso não esteja de acordo com o esperado. Acontece que podem sobrar algumas tarefas não realizadas e com isso, alguns itens (ou histórias de usuários – técnica de mercado muito utilizada para dar maior clareza do porquê temos que executar, para quem e o que) do product backlog não serem entregues como planejado. Neste caso, o PO pode optar em continuar no próximo sprint (que inicia imediatamente após o término da anterior) ou ele pode repriorizar de acordo com as necessidades do negócio.

E como o time Scrum tem como direção a meta do sprint e a definição de concluído definidos durante o planejamento do mesmo é esperado que todos os itens do backlog de produto sejam entregues com a qualidade esperada pelo cliente (representado no time com o papel de PO) e isso evita aquela famosa frase:

– E aí tá pronto? Tá pronto, só falta testar… rsssss.. Brincadeiras à parte, é esperado que o time tenha todas as habilidades e capacidades necessárias para fazer entregas com excelência e assim evitar retrabalhos.

Esperamos que tenha gostado de ficar até aqui com a gente e que realmente isso faça sentido para você e sua equipe.

Grande abraço e até mais,

Amanna Monteiro e Adriane Colossetti – Família Sunsetti

Categorias
Sem categoria

Como fazer uma Planning do Scrum?

Projeto começando e precisamos planejar, mas por onde começar?

  • Como é feito uma Planning do Scrum?
  • Quem participa desse evento (cerimônia) e quanto tempo ela dura?
  • É necessário ir com algo pronto para ela?

Muitas perguntas surgem nessa hora, é normal… Mas vamos contar um pouquinho como fazemos por aqui.

Quando iniciamos um projeto e vamos para a primeira Planning, precisamos de algumas primícias.

O Product Owner constrói o Product Backlog com as histórias de usuários (técnica de mercado usada para levantar os requisitos necessários de um produto) devidamente priorizadas de modo que agregue valor ao cliente. Geralmente, essa priorização é feita com um conceito de MVP (mínimo produto viável) e existem N técnicas que podem ser usadas para fazer essa priorização, por exemplo, Moscow, GUT, comparação, matriz de importância e conhecimento técnico, entre outros.

Após ter o Product Backlog (confira nosso artigo de como montamos um Product Backlog) montado e priorizado pelo Product Owner, ele juntamente com o Scrum Master e o time de desenvolvimento, fazem o refinamento (usa-se até 10% do tempo do time Scrum) de algumas histórias que entrarão na Sprint a seguir.

Esse refinamento pode ser feito de várias formas, afinal o Scrum não dita nem técnicas e nem ferramentas, mas por prática costumamos usar as 7 dimensões do produto (ator, ação, interface, dados / informações, regras de negócio, qualidade (critério de aceite) e ambiente que o produto vai executar (se analisarmos as histórias o “ator” e a “ações” nós já temos nas histórias, o que facilita esse processo).

Na Planning participa o Product Owner, o Scrum Master e o time de desenvolvimento, e ela é dividida em duas partes, O que fazer e o Como fazer.

O que fazer é decidido pelo Product Owner de acordo com o que ele priorizou no Product Backlog, e ele participa para que todas as dúvidas do time sejam sanadas.

O Como fazer é decidido pelo time de desenvolvimento e ninguém, nem mesmo o Scrum Master diz ao time como transformar o Product Backlog em incrementos de funcionalidades potencialmente liberável. Eles estimam as histórias que o Product Owner priorizou. Uma das formas para estimar é o Planning poker que é uma técnica que usa a sequência de Fibonacci e o time determina em pontos (1, 2, 3, 5, 8, 13, entre outros até mesmo uma carta (símbolo de infinito) que mostra que a história está impossível de mensurar, tem outra com a figura de uma xícara de café que é usada quando o time fica cansado e precisa de uma pausa e outra de interrogação, quando ainda restam dúvidas sobre o assunto abordado na história) que significa a complexidade para realizar cada história.

O Scrum Master faz um cálculo de velocidade (outra técnica de mercado) se baseando no tamanho da Sprint para saber quantos pontos a equipe é capaz de realizar naquela Sprint. Após isso, o time pega as histórias priorizadas até a capacidade que eles podem realizar e chegam em nível de tarefas, as quais normalmente são organizadas em um quadro para gestão a vista e o mais usado pelos times é o proto Kanban com as colunas que representam o processo que precisa ser seguido para entrega das tarefas feitas (geralmente encontramos quadros com as seguintes colunas: “A fazer”, “Fazendo”, “A testar”, “Testando”, “A homologar”, “Homologando”, “Impedimentos”, “Feito”).

Esse conjunto de tarefas determinadas pelo time é chamado de Sprint Backlog, e quem controla ao longo da Sprint é o próprio time de desenvolvimento, somente eles adicionam ou retiram tarefas, além de ninguém, nem mesmo o Product Owner e o Scrum Master dizer à eles como devem trabalhar.

Com base no Scrum Guide, uma Planning para uma Sprint de 30 dias tem duração de até 8 horas. Mas, você pode se perguntar, e para sprints menores?

O mercado adaptou e, provavelmente, você já deve ter visto por aí que as sprints são de 2 a 4 semanas, mas tudo isso surgiu porque na engenharia de software tem um estudo que diz que não é possível entregar nenhum incremento de valor com menos de 2 semanas. Logo, essa adaptação ficou da seguinte forma:

  • Sprint de 4 semanas a Planning tem duração de 8 horas;
  • Sprint de 3 semanas Planning de 6 horas;
  • Sprint de 2 semanas Planning de 4 h.

Até mesmo as outras cerimonias ficaram proporcionais.

Ainda na planning, o time scrum determina qual é a Definição de Concluído (conhecida também como “Definition of Done”) para aquela Sprint e todos precisam chegar em um acordo para que no final não tenham problema onde o Product Owner pergunta: “E aí tá pronto?” e o time responde: “Tá pronto, só faltar testar”. Afinal, tá pronto ou falta testar? Essa definição é de suma importância para deixar todos alinhados.

Para finalizarmos este artigo, é importante saber que no final deste evento (cerimônia) é esperado dois resultados: o Sprint Backlog e a Meta do Sprint.

Obrigada por terem ficado com a gente até aqui.

Um abraço,

Amanna Monteiro

Categorias
Sem categoria

Como fazer uma Retrospectiva do Scrum?

Chegou o evento retrospectiva do Scrum e com isso algumas dúvidas…

Como nós podemos fazer para não tornar esse evento uma lavação de roupas sujas?

Como fazer para não deixar ninguém do time constrangido?

E para evitar discórdias e formação de “panelinhas”? Entre outras inúmeras perguntas.

Tudo depende de como é feito e se está bem claro a todos que esse evento é uma bela oportunidade para que o time cresça, amadureça, se engaje, se entendam cada vez mais, pois acaba conhecendo mais uns aos outros… é um momento de adaptação e inspeção do Scrum (lembra dos três pilares? Transparência, adaptação e inspeção).

Existem várias formas de facilitar esse evento e vou dizer a você o que aplicamos em nossos clientes e funciona bem (fizemos de várias formas já e esse foi o que mais está funcionando até o momento. Sabemos que não existem receita de bolo para lidar com pessoas, então fique atento de considerar o estilo e perfil de cada um, ok?) –Tenho uma dica de leitura que eu considero fantástica: “Como fazer amigos e influenciar pessoas de Dale Carnegie” – se você já leu, sugiro ler novamente com outra visão e se ainda não leu, coloque em sua lista de leitura, pois vale muito a pena.

Então, a final, qual técnica que usamos? Vou detalhar pra você…

Dividimos a parede ou quadro branco em dois e colocamos um sinal de positivo (+) do lado esquerdo e negativo (-) do lado direito. Pedimos para que o time se concentre por 5 minutos nos positivos e sem conversar um com outro, vão anotando em post-its e colando do lado correspondente, depois, por mais 5 minutos é a vez dos negativos e repetem a mesma coisa. Ao terminar o tempo, nós perguntamos quem quer moderar esse evento (mas, Dri, isso não é papel do Scrum Master (SM)? Sim, porém pode revezar e assim o mesmo treina o time em autogerenciamento e muitas outras coisas que ficam atreladas – vale até artigos falando somente de soft skills necessários em times). Então, alguém vai até o local onde os post-its estão colados e organiza – elimina os que estão repetidos, agrupam os que tem semelhança; lê em voz alta a todos e nos positivos, depois que todos estão lidos e entendidos por todos, aplaudem – sim, é motivo de comemorar!! Depois, lê os negativos (e não fica perguntando quem escreveu ou até mesmo tentando descobrir, lembre-se que não é o intuito expor ninguém – por isso, sempre alertamos para que seja escrito com muita clareza para que possamos entender, caso contrário, deixaremos para próxima “retrô”). Para cada item negativo o time sugere plano de ação que será implantado na próxima sprint (tem que ir para o próximo sprint com pelo menos um para melhoria e assim, vamos promovendo a melhoria continua – o famoso Kaizen na prática do Lean manufacturing do setor automobilístico), acrescenta então no próximo Sprint Backlog e assim as coisas seguem.

Espero que tenha gostado de ficar até aqui comigo e que realmente isso faça sentido para você e sua equipe.

Grande abraço e até mais!

Adriane Colossetti – Família Sunsetti