Logo Agile SchoolLogo Agile School
Logo Agile SchoolLogo Agile School
0
R$0.00 0 item

Nenhum produto no carrinho.

Uma das disfunções mais comuns encontradas em Times Scrum é a transformação da Daily Scrum em um relatório de status, onde cada Desenvolvedor fornece o status do item de trabalho que está desenvolvendo e, no final, ninguém realmente sabe como estão se saindo em relação à Meta da Sprint. Todos nós que já passamos por Times Scrum percebemos que esse não é o melhor caminho… Com o tempo, os Desenvolvedores se tornam cada vez menos dispostos a colaborar, cada um fechado em seu próprio mundo, até que um dia nos perguntamos se realmente temos um Time Scrum ou apenas um grupo de pessoas que por acaso trabalham juntas no mesmo espaço.

Mas como podemos nos prevenir contra isso? Ou, se isso já está acontecendo hoje, como podemos começar a remediar?

É importante lembrarmos aqui do propósito da Daily Scrum. Esse é um evento de planejamento e tomada de decisão rápida, que acontece todos os dias da Sprint e conta com a participação de todos os Desenvolvedores do Time Scrum. O propósito é inspecionar o progresso do trabalho em direção à Meta da Sprint e adaptar o Sprint Backlog conforme necessário para otimizar as chances de alcançar a meta.

Aqui estão algumas sugestões para promover maior foco e colaboração na sua Daily Scrum:

1- Foco na Meta da Sprint: Lembre-se de que a Meta da Sprint é o compromisso do Sprint Backlog. Sendo assim, é a melhor bússola que os Desenvolvedores podem usar para guiar suas interações durante a Daily Scrum. Perguntem-se: “Vemos algum obstáculo para alcançar nossa Meta da Sprint?” e, se a resposta for positiva, “Como podemos removê-lo hoje?”

2- Foco no fluxo: Para promover uma entrega contínua de valor, devemos gerenciar ativamente o fluxo de trabalho em nosso sistema. Temos algum gargalo em alguma parte do nosso processo? Itens bloqueados? Esquecidos, despriorizados ou simplesmente esperando por algo para poderem avançar? Perguntem-se também: Qual item está há mais tempo em nosso fluxo (incluindo possíveis itens bloqueados)? O que podemos fazer para fazer esses itens avançarem hoje?

3- Foco na entrega de valor: Em vez de se concentrarem nas tarefas sendo desenvolvidas por cada Desenvolvedor, perguntem-se coletivamente: “Quais itens do nosso Sprint Backlog estão mais próximos de serem finalizados?” e “O que podemos fazer para concluí-los hoje mesmo?”. Lembre-se de que a ideia de valor é uma suposição até que algo esteja efetivamente nas mãos do usuário. O que podemos fazer para que isso ocorra o mais cedo possível?

4- Foco na melhoria contínua: Outro ponto de potencial alavancagem das Daily Scrums é serem um checkpoint para ações de melhoria identificadas na Sprint Retrospective, que também podem ter sido incluídas como parte do Sprint Backlog para a Sprint. Desenvolvedores podem se perguntar: “O que estamos fazendo em relação aos itens de melhoria que identificamos?” e “Há algo mais que podemos melhorar hoje?”5- Foco em conversas relevantes: Por último, mas não menos importante, certifique-se de que as conversas durante a Daily Scrum sejam focadas na inspeção do trabalho e que o evento não se transforme em uma sessão de resolução de problemas. O timebox aqui é seu melhor aliado. Independentemente do tamanho do seu time, esforcem-se para manter o evento dentro dos 15 minutos de duração do timebox. Sessões posteriores podem e muitas vezes são usadas para exploração e resolução de problemas.

E aqui vai um parabéns para aqueles que lembraram que Foco é um dos 5 Valores do Scrum! TODOS os Valores do Scrum podem ser usados para melhorar a qualidade da Daily Scrum (e todos os outros eventos) em geral. 🙂

E então, como vocês usariam os outros 4 valores para melhorar ainda mais a sua Daily Scrum? Que outras ideias já experimentaram em seus times? Qual foi o resultado?

O Minicurso de Introdução ao Scrum, oferecido pela Agile School, é um treinamento rápido e direto que proporciona uma compreensão clara do que é o Scrum, onde ele é implementado e quais são seus elementos base.

Neste curso, você terá a oportunidade de adquirir conhecimentos essenciais sobre o Scrum de forma concisa e eficiente. Os módulos abordam os princípios fundamentais da ferramenta, seus benefícios e aplicações práticas.

Ao final do minicurso, você estará apto a compreender a metodologia Scrum, suas características e pronto para dar os próximos passos na sua carreira. Se você está em busca de um aprendizado ágil e introdutório sobre o Scrum, o Minicurso de Introdução da Agile School é uma excelente opção.

O que você aprenderá:

Clique aqui e acesse agora mesmo!

Assumir novos papéis nem sempre é uma tarefa fácil, ainda mais quando chegamos em um ambiente desconhecido e que não estamos habituados. Por isso, trouxemos neste artigo cinco dicas essenciais que você, Product Owner, deve saber ao adentrar em um novo time.

Já falamos aqui sobre a função desse papel e também sobre a diferença dele para o Product Manager. Mas apenas para relembrar: o Product Owner é a pessoa responsável pelo refinamento do produto, ou seja, é alguém sempre atento às tendências de mercado e às necessidades do cliente. 

Sua função é muito relacionada ao Scrum e ao backlog de produtos, para que os desenvolvedores realizem seu trabalho e entreguem resultados de valor. Portanto, é essencial que esse papel seja bem executado, e para isso, é necessário atentar-se a certos pontos:

Mapeie seus Stakeholders

Os Stakeholders representam o conjunto de indivíduos a quem o seu produto ou projeto interessa de alguma forma, podendo ser externos ou internos à organização. Nesse contexto, falamos principalmente sobre os colaboradores, clientes, e outras pessoas que irão ser responsáveis em apoiar e desenvolver esse produto.

Portanto, mapeá-los de forma ágil é essencial! Entenda a organização da empresa em que você está inserido e a hierarquia vigente, o que pode ser feito através de um organograma dos processos, onde você é capaz de visualizar as áreas conectadas e definir quem deve ser priorizado no momento de resolver impasses do seu produto em questão.]

Compreenda o mercado do seu produto

O mercado de cada produto possui um comportamento singular, por isso, é essencial compreender em qual deles o seu projeto está inserido. Busque compreender o modelo de negócio da sua empresa, e com isso, defina o mercado-alvo (aquele que busca atingir com o lançamento do produto) e o posicionamento que diferencia seu produto dos outros que já atuam no mercado.

Além disso, faça uma lista das fontes de receitas e despesas e estabeleça uma visão compatível ao seu objetivo.

Defina as metas a serem alcançadas com o produto

Para quem não sabe pra onde vai, qualquer caminho serve. Logo,dê preferência às metas objetivas, quantitativas e com prazo. Caso a empresa já possua alguma estrutura (OKR por exemplo), faça uso das metas ou objetivos estratégicos já existentes. 

É crucial que exista esse parâmetro, pois você irá utilizá-lo como medidor de sucesso e progresso.

Crie um bom Product Backlog

Baseado nas metas estabelecidas pelo tópico anterior, inicie a criação do Product Backlog com itens mais genéricos, em alto nível (podem ser épicos). Ordene os itens de forma a constituir uma versão inicial de Roadmap de Produto e se for adequado, pode ser feito um plano de lançamento das versão inicial do produto (Release Plan). 

Na sequência, inicie o refinamento dos itens mais prioritários do Product Backlog (que estão no topo da lista), quebrando-os em itens menores e detalhando suas funcionalidades e características do escopo desejado.

Tenha um bom relacionamento com o time

O Product Owner também deve investir seu tempo em estabelecer um relacionamento com sua equipe. É fundamental que, uma vez que os desenvolvedores irão construir o produto, a dinâmica de comunicação, negociação, troca de opiniões e feedback seja muito fluida. 

O Product Owner também é um membro do time e não pode se ausentar ou ser visto como inimigo da equipe. Uma atenção especial pode ser dada a BA, Designer, QA e o Scrum Master, pois terão uma proximidade maior do POs nas atividades do dia-a-dia.

Invista em treinamentos que irão alavancar sua atuação

A nossa última dica (mas não menos importante) para você que é um Product Owner recém chegado em um time, é investir em treinamentos e cursos que irão te auxiliar a assumir esse papel com êxito e, ainda, ter uma certificação internacional!

Estamos com vagas abertas para nosso treinamento Professional Scrum Product Owner, que irá acontecer de forma online e ao vivo. Ele é voltado para todos aqueles que buscam como trabalhar melhor com os Stakeholders, como gerenciar um backlog de sucesso e entre outras funções essenciais do PO.

Aproveite essa oportunidade e garanta sua participação! 

Se você está começando a trabalhar com Kanban agora, é muito importante explorar e dominar os elementos indispensáveis para um quadro Kanban. É importante testá-los e compreendê-los, assim entendendo quais deles fazem mais sentido e em quais situações são essenciais a sua implementação e quais não fazem sentido para o seu contexto de trabalho.

Por isso, separamos os oito elementos indispensáveis para um quadro Kanban gerar realmente valor para todo o time, para as entregas e para a organização. Confira:

1. Itens de trabalho

Antes de abordar o quadro Kanban em si ou as etapas do fluxo, é importante falar sobre os itens de trabalho, isto é, quais itens serão trabalhados dentro do fluxo e o que são estes itens. De maneira resumida, os itens de trabalho são as unidades de valor dentro do fluxo de trabalho, mas o que elas são de fato vai variar de acordo com cada time. Existem equipes que determinam o item de trabalho como “construir tela X” e outro item sendo “testar a tela X”.

Porém, esta não é a forma mais adequada de se definir o item de trabalho. Isso se deve ao fato de que a equipe tem que pensar no que é solicitado e não exatamente em quais serão as ações para que aquela solicitação aconteça. Por exemplo, quando você vai a um restaurante, você pede um prato e não os processos que levam para que o prato seja feito, certo?!

Para uma melhor compreensão, o item de trabalho é aquilo que é solicitado à equipe e aquilo que é entregue pela equipe, isto é o item de trabalho no Kanban. Dentro deste raciocínio, podem haver vários tipos de itens, como itens de melhorias, itens de correção e outros, isto deve ser compreendido antes mesmo de começar a montar o quadro.

Assista mais sobre esse assunto neste vídeo aqui.

2. Pontos de entrada e saída

Falando no fluxo de trabalho, existe o momento em que uma demanda entra no fluxo de trabalho e passa a ser processado pela equipe, este momento é o Ponto de Entrada. E existe também o momento em que este item de trabalho sai do fluxo, ou seja, quando ele termina de ser executado pelo time… Este momento é o Ponto de Saída.

É preciso que o time possa determinar quais são essas situações, pois isto representa um conceito chave do Kanban: o Trabalho em Progresso ou o Work In Progress – o famoso WIP, como é conhecido em inglês. Ou seja, esses são itens que estão em progresso, que passaram pelo ponto de entrada, porém ainda não passaram pelo ponto de saída e estão no campo de trabalho que está acontecendo.

3. Etapas do Fluxo de Trabalho

Quando um item de trabalho entra no escopo do time e começa a ser trabalhado, ele irá passar por alguns processos que vão variar de acordo com a equipe e suas demandas. Portanto, quando este item passa pelo ponto de entrada, o time deve especificar com o maior detalhamento possível as etapas pelas quais os itens irão passar, por exemplo: etapa de análise; etapa de teste; etapa de revisão; entre outras.

Isso fará com que o time mapeie e execute melhor o fluxo de trabalho. Se um item receber um status apenas de “em processo”, isto faz com que a leitura do quadro Kanban se torne um tanto simplória… Afinal, o que de fato significa este “em processo”? Por isso, determinar as etapas do fluxo de trabalho é uma parte indispensável de um quadro Kanban.

4. Políticas Explícitas

Seguindo este raciocínio citado acima, se os itens de trabalho devem ser separados por etapas, então como definir quando um item irá passar de uma etapa para a outra? É agora que entram as Políticas Explícitas.

São elas que definem quais as regras para que um item se mova de uma etapa para a outra dentro do quadro Kanban. Entretanto, não existe regra na hora de criar as Políticas Explícitas. Quais serão essas políticas ficará sempre a cargo do time, pois isso varia muito de acordo com cada contexto.

5. Limite WIP (Work In Progress)

Um dos principais elementos do Kanban – fundamental para que a ferramenta gere valor de fato, é o limite de WIP, ou seja, o limite do trabalho em progresso. Ou seja, o time deve ter uma capacidade máxima de quantos itens ele pode trabalhar simultaneamente, assim como cada membro desta equipe deve também ter o seu próprio limite de itens de trabalho em progresso.

Dessa forma, o time poderá estabilizar o fluxo e estabelecer uma dinâmica de sistema puxado. Lembrando que, geralmente, esse limite é estabelecido por colunas, assim cada etapa do item de trabalho terá uma quantidade máxima de itens simultâneos. E, vale ressaltar que, no Kanban, o limite de itens de trabalho em progresso também é algo que deve ser criado e alinhado pelo time, tornando-se também uma política explícita.

6. Raias horizontais

As raias horizontais são linhas traçadas ao longo do quadro Kanban e servem para estabelecer um contexto. Elas podem servir como um elemento visual, para que separe os itens de trabalho ao longo das etapas. Por exemplo, uma raia pode ser referente a um determinado projeto, enquanto que a raia debaixo se referir a um outro projeto, assim estabelecendo contextos diferentes. Dessa forma, o quadro se torna mais visualmente compreensível, além de poderem servir até para métricas e/ou políticas explícitas futuras do time.

7. Decoradores

São elementos visuais que comunicam algo, servindo quase como uma legenda dentro de um quadro Kanban. Um exemplo de decoradores são os “avatares” que denominam quem está cuidando daquele determinado item no quadro. Outro tipo de decorador comum também é um sinal de alerta sobre um item de trabalho, podendo representar que aquele item está com um “block”, um bug, etc. Eles também variam de time para time, conforme a necessidade ou aquilo que os membros julgarem necessário.

8. SLE – Service Level Expectation

Dos elementos citados aqui, este é talvez o mais complexo e, por vezes, o mais negligenciado pelas equipes que usam Kanban há pouco tempo. Como o nome já dá a entender, o Service Level Expectation (SLE) se refere à expectativa de prazo para realizar uma determinada entrega, desde o momento em que entra no fluxo, até sair do fluxo.

Ele é feito de maneira probabilística e dá o prazo junto com a porcentagem de probabilidade de que esta data será cumprida. Para se chegar neste dado, é necessário acessar as métricas do time. Através do Cycle Time histórico, o time realiza a entrega, analisa o tempo que foi necessário para que o item seja processado e então determina qual o SLE.

Com isto, o time chegará a várias informações úteis, como eficiência, expectativas de entrega para o cliente, mensuração do tamanho dos itens de trabalho, entre outras.

E agora, como melhorar?

Claro que, destes elementos, alguns podem ser mais fundamentais do que outros – dependendo do seu contexto. O limite de WIP, por exemplo, quando utilizado da maneira adequada num quadro Kanban, traz excelentes resultados para a equipe e para a empresa. 

Entretanto, se você ainda está na dúvida de como melhorar seu sistema Kanban para ter mais fluxo, mais produtividade e organização, estamos com as últimas vagas disponíveis para a turma de Professional Scrum with Kanban da Agile School, que será nos dias 09 e 10/07/2022, totalmente online e ao vivo.

Aproveite as condições super especiais de lançamento deste curso e potencialize suas entregas de forma rápida e profissional usando Scrum e Kanban juntos! Clique aqui agora mesmo para saber mais.

Inscreva-se agora!

Com a disseminação das práticas ágeis pelo mundo, muitas mentiras ou meias verdades foram espalhadas por aí. Por isso, separamos alguns mitos mais comuns que ouvimos e vamos desvendar as principais falácias dentro da agilidade, principalmente do framework Scrum.

Todo o time Scrum deve estar no mesmo lugar

Muitas pessoas acreditam que, para realmente fazer o framework funcionar, é necessário que o time Scrum esteja presente 100% e isso, com certeza, é um mito. Existem times Scrum que trabalham 100% remotos, uns que fazem encontros semanais e outros que preferem o presencial.
 
Mas é importante entender que isso não interfere em nada nas demandas e na produção do time. O que irá fazer com o que tudo ocorra bem, serão as ferramentas, as metas e os objetivos de toda a equipe. 

Os times só podem ter de 3 à 9 pessoas

Sim, limitar o time até 9 pessoas é uma recomendação que está no Scrum Guide, pois experiências mostram que lidar com time com mais pessoas pode ser mais complicado. Porém, isso não impede que você tenha mais pessoas em seu time! 

É necessário fazer um lançamento em todo final de Sprint

Os lançamentos de produtos podem acontecer independentemente da Sprint. Muitas pessoas acreditam que é obrigatório que ao final da Sprint o time entregue algum incremento ou produto final para o cliente, porém isso não é uma regra. Você pode entregar um incremento ao final de cada sprint ou em uma única sprint fazer várias entregas de um mesmo produto.
 

Uso dos Story Points ou Planning Poker é obrigatório 

Os Story Points e o Planning Poker são ferramentas que podem fazer parte dos times, mas não são obrigatórios. Ou seja, são práticas complementares que podem te ajudar em diferentes pontos dentro do time, mas não significa que se você utilizá-las ou não, quer dizer que você está fazendo algo errado.

Uma pessoa não pode exercer mais de um papel dentro do time

No Scrum Guide, não tem nada declarado sobre uma pessoa desempenhar mais de um papel dentro do time. Pelo contrário, é muito comum você encontrar múltiplos papéis dentro do time, por exemplo, um Scrum Master também pode ser um Developer.
 

A equipe precisa ser full time sempre

Na verdade, esse mito se torna uma falha no entendimento do framework, já que os integrantes do time, podem trabalhar em outras equipes. Por exemplo, um Product Owner pode ser PO em outros times, assim como os Desenvolvedores e o Scrum Master. Mas é necessário ter cuidado quando utilizar essa dinâmica, pois terá sempre um ponto de falha entre os times. 

O Product Owner não deve estar presente na 2ª parte da Sprint Planning

Primeiro precisamos deixar claro que não existe mais essa diferenciação na Sprint Planning. Em antigas publicações do Scrum Guide ocorreu essa separação, mas atualmente isso não acontece mais. A primeira parte era onde o time discutia sobre as demandas que seriam realizadas na próxima Sprint e, na parte dois, somente o time de desenvolvimento fazia a quebra dessas demandas e etc.
 
Hoje em dia, entendemos que ainda possam existir dúvidas a serem tiradas com o Product Owner. Então, se o PO não participar dessa segunda parte, ele precisa estar disponível para caso o time queira solucionar algumas questões.

O refinamento do Product Backlog é um evento

O refinamento do Backlog acontece de maneira recorrente, ou seja, ele acontece sem as características formais das reuniões do Scrum. Por exemplo, ele pode ou não acontecer e ele não possui uma recorrência de limite de tempo como a Sprint. Seu processo pode acontecer ao longo da Sprint ou na Sprint Planning, conforme for necessário.
 

O Product Backlog é sinônimo para os requisitos do Produto 

Quando pensamos em requisitos, entendemos como uma lista detalhada ou todo o escopo que o Produto terá. Porém, o Product Backlog a visão deve ser um pouco diferente, já que ele vai sendo construído com o passar do tempo… Podemos até chamá-lo de “artefato vivo”, pois ele vai sendo reordenado, priorizado, alterado, demandas entram em saem e etc, durante o processo todo.
 

A História de Usuário é um item do Scrum 

Assim como as ferramentas complementares, a História de Usuário não foi criada junto com o framework, ela surgiu a alguns anos atrás e times Scrum passaram a utilizá-la como um meio para auxiliar no desenvolvimento de Produtos. Ou seja, ela não é especificamente um item!
 

Para finalizar

Ainda existem muitos outros mitos sobre o Scrum que são espalhados por aí, uns mais novos, outros mais antigos… Vamos até trazer uma parte dois em breve! Entretanto, é importante deixar claro que não existem regras que devem sempre ser cumpridas fielmente.
 
Como é falado no próprio Scrum Guide, o Scrum pode ser adaptado de acordo com as necessidades do time, a fim de funcionar melhor para cada realidade e proporcionar mais benefícios para as pessoas e para a organização.
 
Para você realmente entender sobre o framework e suas funcionalidades, aqui na Agile School temos o treinamento Applying Professional Scrum, uma imersão com conteúdo direto dos criadores do Scrum, ensinamento de todos os conceitos, princípios, valores e práticas para o seu dia a dia.
 
Além disso, ao realizar o treinamento Applying Professional Scrum, você além de poder se tornar um especialista em Scrum, você ganha duas tentativas para a prova de certificação Professional Scrum Master I (PSM I). Ou seja, essa é uma grande oportunidade para dar um salto em sua carreira e ter o conhecimento mais pedido pelas empresas modernas e digitais. Clique aqui e saiba mais sobre o APS!
 

Saiba tudo sobre o APS

As principais práticas do Kanban no time Scrum

Já explicamos para vocês a diferença entre o Kanban e o Scrum, e mostramos também que um pode ser complemento do outro e, não necessariamente, concorrentes. Pensando nisso, neste artigo, vamos falar sobre algumas práticas do Kanban que podem ser utilizadas no time Scrum e como elas podem melhorar ainda mais os resultados de um time. 

Lembrando que, por mais que existam empresas que se adaptam melhor ao Scrum, outras ao Kanban, não é necessário escolher por uma ou outra. Você pode usar ambas práticas em conjunto e trazer uma melhora de performance ainda maior para o seu time, colhendo o melhor de cada abordagem.

Você pode ler mais sobre as diferenças desses dois modelos de trabalho aqui.

  1. Visualizar o Workflow 

O primeiro passo é você conseguir enxergar o seu fluxo de trabalho e quais as etapas que ele irá conter para você conseguir acompanhar o seu progresso. O fluxo que você irá criar vai depender do contexto do seu produto/serviço, ok? Uma forma de você visualizar esse fluxo de maneira funcional e eficaz é através do quadro Kanban. 

Normalmente, nos quadros Kanban utilizamos a gestão visual, que nada mais é do que deixar visível para o time tudo o que for importante, sejam as demandas, as regras, políticas, entre outras informações que forem necessárias.

Você entender melhor sobre o sistema visual e puxado no Kanban aqui neste vídeo.

  1. Limitar o WIP

Essa é uma abordagem que contabiliza a quantidade de tarefas que o time está trabalhando simultaneamente. Tudo que estiver dentro dos limites do quadro, terá um WIP (“Working In Progress”, em tradução livre, significa “trabalho em progresso”), por exemplo: se o seu quadro possui 5 tarefas em andamento o seu WIP será 5, caso tenha 10, o WIP será 10 e assim por diante…

Por isso, é importante limitar o número de tarefas em execução, limitando assim a quantidade de cards que ficam parados nas etapas do quadro Kanban, a fim de priorizar melhores entregas e não mais tarefas em andamento.

Você pode ler mais sobre o WIP aqui. 

E, vale ressaltar que, quando utilizamos o limite do WIP nós reforçamos a utilização do sistema puxado, pois em cada coluna terá um limite de demanda que pode ficar nela.

  1. Gerenciar o itens em progresso 

O time Scrum deve sempre controlar o número de itens, do início ao fim, de demandas no fluxo de trabalho. Um efeito colateral do WIP é o sistema puxado, que possui esse nome pois os membros do time passam a trabalhar em um item e aí só “puxa” ou “seleciona” outro, quando há capacidade clara que mostra que é possível realizar aquela tarefa.

Para finalizar…

Conseguimos observar neste conteúdo que não temos aqui uma questão de evolução do Kanban e/ou do Scrum, muito menos uma escolha binária. É possível entender que existem diferenças óbvias entre ambos, mas que é possível (pra não dizer aconselhável) utilizá-los em conjunto, para potencializar ainda mais suas entregas de valor.

Mas, para que você se torne realmente um especialista, seja em Kanban e/ ou Scrum é necessário muito mais estudo e aprofundamentos que vão além deste blog post!

Na Agile School, temos os treinamentos formulados por grandes nomes do mercado, como o APK (Applying Professional Kanban), que é específico para quem deseja melhorar sua capacidade de agregar valor e ser mais eficaz através do sistema Kanban e o APS (Applying Professional Scrum), para quem deseja aprender de forma sólida e, ao mesmo tempo, prática e rápida a criar um produto digital do zero utilizando Scrum!

E lembrando que estamos com turmas abertas para o treinamento Professional Scrum With Kanban (PSK) totalmente online e ao vivo nos dias 24 e 25/09/2022. Clique aqui e garanta sua vaga!

Agora, se você já domina essas práticas e quer se aprofundar como Agilista, nossa recomendação é conhecer o treinamento Professional Scrum Master II. Clique aqui e saiba mais!

Lembrando que todo ex- aluno Agile School possui desconto de 5% em todos os cursos que disponibilizamos. Para resgatar o seu cupom é só clicar aqui e falar com o nosso especialista.
Caso tenha alguma dúvida sobre qualquer treinamento da Agile School, entre em contato com a gente através do Whatsapp.

Saiba como desbloquear as pessoas de forma simples e eficaz

Depois de falar sobre o elementar que todo Scrum Master deve dominar, neste artigo vou dar algumas dicas e abordagens para remover impedimentos do time. Ok, falando assim parece até simples, não é mesmo?!

Mas não é! Essa é uma das grandes habilidades que o Scrum Master de valor precisa ter e que faz muita diferença nos resultados de toda a equipe.

O que é impedimento?

Começando do começo, impedimento nada mais é do que qualquer fato que bloqueia o progresso do time.

A falta de permissão para acessar um servidor, a incapacidade de contato com um fornecedor, uma API externa fora do ar, geralmente são classificados como impedimentos. 

O que vai determinar se o fato é um impedimento ou não é a capacidade do time em resolvê-lo.

Ou seja, se a própria equipe tem a capacidade de resolver o assunto, aquilo não é um impedimento mas simplesmente um problema, talvez uma urgência.

Agora, caso o time tenha feito tudo ao seu alcance e o bloqueio permaneça, é responsabilidade do SM solucioná-lo.

 

Qual o papel do Scrum Master?

O Scrum Master é um líder servidor. O que isso quer dizer?

Esse papel é responsável pela efetividade do time, garantindo um ambiente de trabalho saudável, de crescimento profissional e eficiência na entrega de resultados.

Ele é como um coach para o Time Scrum, estando disponível para tirar dúvidas, ser um facilitador, solucionador de problemas e, claro, ajudar a remover impedimentos.

O Scrum Master deve desenvolver a autonomia da equipe, garantindo que, com o tempo, eles se tornem capazes de resolver seus problemas, deixando apenas os mais complexos e menos previsíveis.

Por isso é importante que o Scrum Master resolva os impedimentos junto à equipe, para assim, garantir que a equipe esteja sempre aprendendo e amadurecendo.

Lembramos, claro, que existem alguns impedimentos imprevisíveis que precisam de uma habilidade maior, esses são direcionados exclusivamente para os Scrum Masters.

Por mais subjetivo que seja o assunto “impedimento”, ele fica naturalmente ligado ao amadurecimento de uma equipe e, consequentemente, a capacidade de uma equipe de resolver seus próprios problemas ao longo de seu desenvolvimento podendo ser percebido como uma medida de maturidade.

A pessoa Scrum Master deve levar o time a auto organização e não a dependência. 

Responsabilidade do Scrum Master ou dos Desenvolvedores?

A primeira coisa a se fazer é entender se estamos lidando com um impedimento real. Como assim?

Quando uma pessoa chega com um problema, como um computador quebrado, por exemplo, é preciso saber se essa pessoa já tomou todas as providências que estavam ao seu alcance, como:

ligar para a área técnica, ver com o almoxarifado se existem máquinas sobressalentes e etc.

Se tudo isso já foi feito, aí sim, realmente estamos lidando com um impedimento e é dever do Scrum Master resolver. 

Caso não, está na hora do Scrum Master ajudar este membro do time a entender que, antes dele apresentar um impedimento precisa tentar resolvê-lo, esgotando suas possibilidades.

Isso ajuda no desenvolvimento de maturidade profissional e pessoal.

Abordagens matadoras para remover impedimentos

Agora que a gente já sabe o que são impedimentos e quando este deve ser resolvido pelos membros do time ou pelo Scrum Master, vamos as técnicas para resolver os impedimentos do dia a dia:

Ter um bom relacionamento com as pessoas

Você deve ser comunicativo e agradável para ter um bom relacionamento com as pessoas. Muitas vezes uma boa conversa franca e pessoal pode resolver muitos problemas e esclarecer diversas situações. 

“Meu problema, problema do time, problema de todos”

Se o problema ou impedimento está atrapalhando todo o processo, então ele não é o problema de uma pessoa, é problema de todos. Para isso, vale a pena usar das palavras para persuadir o time, por exemplo:

“Fulano, me arruma a massa de dados pra gente ajudar o time? Se você não liberar isso, não vamos conseguir entregar esse Sprint.”

Ou seja, de modo simples mostrei ao ‘fulano’ que o time depende dele para resolver aquele impedimento, além do que, se ele entende que é um problema dele também, vai fazer o máximo para resolver.

Poder da escala

O impedimento é algo super prioritário.

No caso de falarmos com uma pessoa e ela não conseguir resolver por estar muito ocupada, podemos procurar escalar o assunto com um líder.

Assim, aquela execução pode tomar prioridade ou o líder pode encontrar outra pessoa para nos desbloquear.

Impedimento resolvido, e agora?

Agora que o impedimento já foi resolvido, é preciso garantir que ele não irá acontecer de novo.

É um princípio de melhoria contínua, você erra uma vez e se aprimora naquela área.

Para que isso seja viável precisasse falar com o time e fazer uma retrospectiva para entender porque ocorreu o bloqueio e assim, antecipá-lo de uma próxima vez.

Nesse caso é papel do SM ajudar o time a não estar mais suscetível à aquele bloqueio novamente.

Esse é um princípio Lean chamado Poka Yoke, que consiste em eliminar os erros fazendo com que eles não aconteçam novamente.

Inclusive, posso falar mais sobre Lean em um outro artigo, bem completo… Em breve trago aqui!

Dica Bônus

Se você quer uma atuação avançada como Scrum Master, precisa aprender as 8 instâncias do Scrum Master. Nós temos um ebook para te ajudar: clique aqui e acesse agora!

Nós, da Agile School, estamos aqui para te ajudar a desenvolver seu conhecimento e adquirir as duas principais certificações do mercado para especialistas em Scrum, a PSM I e a PSM II.

Com nossos treinamentos você aprenderá diversas técnicas para se tornar um Scrum Master de sucesso e assim, lidar com todos os impedimentos, bloqueios e as diversas situações do dia-a-dia.

Confira mais detalhes:

Professional Scrum Master I (indicado para quem é ou quer se tornar Scrum Master)

Professional Scrum Master II (recomendado para quem já é SM a pelo menos 1 ano)

Comemorando 25 anos do Scrum, no dia 18/11/2020, foi lançada a nova versão do Scrum Guide. Para te mostrar essas novidades e tirar todas suas dúvidas, nossos especialistas fizeram uma live especial falando sobre as principais mudanças e como elas terão impacto no mercado.Mas quais foram essas mudanças entre os Guias Scrum de 2017 e de 2020?

Entenda melhor cada uma dessas atualizações e qual o impacto delas com comentários dos nossos trainers:

Clique aqui e acesse o Scrum Guide 2020!

Fundamentos do papel de Scrum Master

Saiba quais são os trabalhos elementares que um Scrum Master deve dominar

Você sabe qual é o trabalho mais elementar do papel do Scrum Master? Aquelas tarefas fundamentais que essa pessoa precisa dominar para exercer essa função? Bom, vamos falar sobre isso começando com uma história que aconteceu comigo…

Meu filho mais velho tem oito anos e está aprendendo a jogar futebol. Ele assiste aos jogos pela TV, observando atentamente grandes nomes como Messi, Cristiano Ronaldo, Neymar, fazendo aquelas “firulas”, dando suas “pedaladas”, fazendo gols de bicicleta, movimentos quase acrobáticos. Ao perceber seu interesse por reproduzir aqueles movimentos super avançados, expliquei que, naquele momento, o mais importante para ele era aprender os fundamentos. 

Em matéria de futebol, para mim, o essencial que todo jogador deve dominar é o toque de bola. Por isso expliquei que ele precisava aprender a receber a bola, tocar para o amiguinho ao lado. Isso deve ser praticado até o domínio pleno do fundamento. Pois, sem isso, não tem nada que o fará ser efetivo em jogar bem a bola, ou seja, jogar bem o futebol.

Depois desse papo com o pequeno, me peguei pensando: o que é elementar na função de Scrum Master? Quais são os fundamentos que esse papel precisa dominar? Sendo assim, selecionei três competências principais e essenciais para que o papel de SM seja realmente cumprido com propósito e sucesso.

Isso mesmo! Pode parecer algo muito básico e até meio óbvio, mas gostaria de deixar aqui como um desafio: pare e veja se consegue dar uma aula de Scrum para sua irmã mais nova, seu cachorro, sua esposa, qualquer pessoa… Segundo o físico, Richard Feynman, ganhador do prêmio Nobel de Fìsica em 1965, “para saber se você domina um assunto, você precisa saber ensinar para alguém”. Se você não conseguir fazer isso, significa que não aprendeu o suficiente sobre aquele tema. 

Então, se você não consegue ensinar o Scrum para outra pessoa, você precisa estudar mais e se aprofundar mais na teoria do que é o framework. Isso também vai te ajudar na prática, quando tiver de ensinar ao seu time os mesmos conceitos, já que faz parte do papel de Scrum Master dar esse suporte à execução do Scrum no dia a dia. 

As pessoas hoje em dia não querem mais executar uma regra apenas por executar, mas sim entender os motivadores; para quê esse framework existe; em que está fundamentado… E isso faz parte do papel de Scrum Master: ENSINAR.

Também é importante dominar o Scrum para ensinar ao cliente. Muitas vezes, o cliente não tem contato com Métodos Ágeis em geral, como você vai explicar essa nova forma de trabalhar, mostrar o real valor e os benefícios?

Ouça o Scrum Guide Audiobook em português!

Desbloquear o time é uma atividade fundamental e básica do papel de Scrum Master. Parece simples, mas na prática não é! Existem diversas formas de remover impedimentos, e o Scrum Master que encontra a maneira mais efetiva e adequada percebe toda a diferença que isso faz.

É comum ver times que ficam, um, dois, três dias, até uma semana, impedidos e o SM não consegue resolver o assunto, desbloquear o time. Isso traz um impacto grande ao Objetivo da Sprint, prejudicando a entrega de valor do time como um todo. Domine esse fundamento, se prepare, busque técnicas e aprimore suas habilidades para desimpedir o time.

Nesse tópico vou me restringir unicamente à facilitação dos eventos do Scrum. Para ser um bom facilitador, é preciso ser uma pessoa organizada, com boa comunicação, voz ativa, postura e conseguir a atenção de todos os participantes para o foco do evento, garantindo que o mesmo está cumprindo seu propósito. 

Também é fundamental que aquele que exerce o papel de SM saiba ajudar as pessoas durante as discussões e o choque de ideias. Nesse momento é importante a sensibilidade de analisar o ambiente, dar voz aos participantes e gerenciar possíveis conflitos. Ter uma boa técnica para deixar visível o “onde estamos” e “onde queremos chegar”, fazer um resumo final de cada reunião para deixar os pontos o mais alinhados possível para os envolvidos… Isso mostra que o Scrum Master está exercendo seu perfil de liderança e influência.

Se você se atentar aos fundamentos, dominar o framework Scrum, remover bem os impedimentos e ser um bom facilitador, sua carreira como Agilista vai longe! E se você exerce o papel de Product Owner ou de Time de Desenvolvimento, se atente aos nossos artigos pois essa série de elementares continua.

Ainda não conquistou sua certificação PSM I? Inscreva-se agora para a próxima turma de Professional Scrum Master e eleve o seu nível profissional.

Como o líder ágil pode facilitar sua equipe até a alta maturidade?

Neste texto,  vou compartilhar algumas experiências e apresentar uma Matriz de Maturidade que descreve a evolução de uma equipe Scrum. E como o líder ágil pode facilitar sua equipe até a alta maturidade

Esta matriz é baseado em experiências pessoais e percepções da Spiral Dynamics.

Você pode usar esta matriz como referência para liderar equipes Scrum em direção a mais maturidade.

Como acompanhamento, apresentarei 4 exemplos, cada um deles descrevendo a transição entre os níveis de maturidade descritos.

Esse conteúdo faz parte do treinamento PAL-e, oficial da Scrum.org, que ajuda líderes a serem líderes ágeis, ajudando os times a entregar mais valor.

Se Scrum for bem feito…

Se o Scrum for bem feito, uma equipe Scrum se auto-organiza, cria valor regularmente e é altamente eficiente:

Se o Scrum for bem feito, muitas responsabilidades tradicionais serão transferidas para o time Scrum. Para aqueles que são novos no Scrum, muitas vezes é difícil acreditar que essa transferência ocorrerá. E para ser sincero, não os culpo!

A maioria das organizações não foi construída sobre princípios de auto-organização. Eles prosperaram em uma época em que a gerência possuía os planos e as equipes de desenvolvimento possuíam apenas a execução.

Mas os tempos estão mudando … O mundo se tornou tão complexo que a responsabilidade precisa ser assumida por aqueles que fazem o trabalho. Só então eles podem ser rápidos, flexíveis e criativos.

E eles não podem fazer isso sem a ajuda de um líder que lhes mostra o caminho.

Se o Scrum for bem feito, você precisará de uma boa Liderança Ágil! Essa é a chave de uma boa organização.

Liderança e Scrum

Muitas pessoas entendem o Scrum hoje em dia, mas falham em extrair o melhor dele.

Isso geralmente é resultado de:

A ideia de uma equipe auto-organizada é relativamente nova no mundo da TI, mas provou ser mais bem-sucedida em esportes e situações militares. Nos militares, existe um ditado famoso que afirma “Não existem equipes ruins, apenas líderes ruins”.

E também há esperança para as organizações de TI!

O melhor elogio que um gerente fez uma vez a uma das minhas equipes Scrum: “Não preciso mais me preocupar com você. Eu só me preocupo com o meio ambiente ao seu redor, então você pode fazer o que tiver que fazer. ”

E se você pudesse aprender com o que essas equipes fizeram para conseguir isso? Qual é o padrão de crescimento que leva a essa maturidade?

E como você, como líder ágil, pode usá-lo para guiar suas equipes para o sucesso?

Uma matriz de maturidade de 5 níveis

A chave para liderar equipes Scrum de sucesso é focar no crescimento da maturidade das funções Scrum, proporcionando-lhes um ambiente onde possam florescer.

Muitos líderes focam nos processos e regras no Scrum, enquanto são as pessoas e as funções que fazem a diferença.

Uma equipe só pode ser tão grande quanto as pessoas que nela trabalham!

Nunca conheci um time Scrum maduro que reivindicasse seu sucesso por sua habilidade de seguir regras. Os créditos vão sempre para a grandeza das pessoas, a maturidade das funções e os valores que compartilham.

As equipes mais bem-sucedidas compartilham um padrão, com base em 4 funções importantes: Scrum Master, Dono do Produto, Membro da Equipe de Desenvolvimento e Líder.

Embora o Líder Ágil não seja uma Role oficial no Scrum, ele desempenha um papel crucial no sucesso das equipes na organização.

A Matriz de Maturidade:

O Líder é responsável por definir as condições de limite para um time Scrum aumentar sua maturidade.

Sobre a Matriz de Maturidade

A maturidade é evolutiva

Evolução

Os treinamentos sobre Scrum ensinamos o framework no seu nível 5 da Matriz de Maturidade.

A maioria das pessoas tem dificuldade em descobrir como fazer isso porque acabaram de chegar ao nível 1 ou 2 da maturidade. Nunca vi ninguém pular para o nível mais alto depois de terminar um treinamento. Você terá que percorrer o caminho através de todos os níveis. Requer muito trabalho, perseverança e boa liderança para atingir o nível 5!

Como Líder Ágil, é sua responsabilidade orientar os papéis do Scrum de um nível para outro.

Estruturas rígidas determinam mentalidade

Times Scrum de sucesso atuam como células autônomas dentro dos limites da organização. Essa mentalidade de nível 5 de maturidade, não pode ser alcançada quando as estruturas rígidas das organizações (comando, processos, regras, edifícios, organizações, KPI’s, etc.) ainda estão no nível 1.

A maneira como as pessoas pensam e agem é determinada por suas condições de trabalho. Como cada papel do Scrum age e pensa em cada nível é determinado pela estrutura rígida fornecida pelo Líder.

Como Líder Ágil, é sua responsabilidade moldar a estrutura rígida de sua organização de forma que as pessoas possam fazer uma mudança em seu sistema de pensamento.

Líderes Ágeis vão primeiro!

Muitos times Scrum ficam presos nos primeiros 3 níveis da Matriz de Maturidade. Todas as equipes que observei nos níveis 4 e 5 tinham uma coisa em comum: o Líder apoiava e orientava as pessoas até lá. Os líderes precisam criar um ambiente onde as pessoas possam trabalhar com comprometimento e foco, sem medo de cometer erros.

Se um líder não for capaz de guiar sua equipe para o próximo nível, haverá atrito, expectativas erradas e Scrum disfuncional.

Como Líder Ágil, é sua responsabilidade dar o exemplo e liderar o caminho.

O elo mais fraco

O sucesso de uma equipe inteira é determinado pelo elo mais fraco. Uma equipe Scrum só mostrará os resultados esperados em cada nível quando todas as funções estiverem pelo menos no mesmo nível de maturidade.

Como Líder Ágil, é sua responsabilidade facilitar o crescimento de cada função em uma equipe para fazer com que toda a equipe cresça.

Como usar a matriz de maturidade?

A matriz de maturidade fornece insights sobre como os papéis do Scrum amadurecem.

Aviso: a matriz deve ser usado como orientação para ajudar as pessoas a determinar seu caminho de crescimento pessoal. Não o use como incentivo, pois impedirá que as pessoas percorram o caminho!

Texto traduzido do blog do Ron Eringa, Professional Scrum Trainer pela Scrum.or. Clique aqui e leia o post original.

Aprimore suas características como líder ágil e aprenda técnicas que te ajudarão gerar mais sucesso na sua carreira e nos seus times, através do treinamento PAL-E da Scrum.org, o Professional Agile Leadership Essentials. Saiba mais sobre esse curso!

Entenda melhor um dos três artefatos do Scrum e como ele deve estar estruturado

O Backlog do Produto é um dos 3 artefatos do Scrum (os outros são o Sprint Backlog e o Incremento) e consiste numa lista ordenada de tudo o que é necessário para maximizar o valor do produto. Tal lista é composta por Itens do Backlog que geralmente representam melhorias, correções e débitos técnicos.

Product free icon

É importante que o Backlog do Produto esteja visível para o Time Scrum (Time) e Stakeholders a fim de promover transparência sobre o que será construído e em qual ordem será construído.

O Backlog do Produto é a única fonte de requisitos do Produto. Ou seja, tudo o que for relativo ao Produto deve estar contido apenas nele.

O único responsável pelo Backlog do Produto é o Product Owner (PO) e, embora ele possa delegar a ordenação do Backlog para alguém do Time de Desenvolvimento, ele continua sendo o responsável por ele. Portanto, a fim de evitar conflitos de interesses, todo Backlog deve mantido por apenas um Product Owner.

Como o Backlog do Produto está estruturado?

Os primeiros Itens do Backlog são aqueles que são mais importantes para o produto em dado momento. Eles devem estar mais detalhados e serem mais bem compreendidos por todos do Time. Dessa forma, são os Itens mais elegíveis a serem desenvolvidos nas próximas Sprints.

Por sua vez, os Itens mais ao fundo são aqueles que ainda não estão bem compreendidos, precisam ser refinados para melhor detalhamento e serão desenvolvidos mais tardiamente, sem previsão esperada para as próximas Sprints. Imagina-se que com mais detalhes, a estimativa seja mais assertiva e seja mais fácil atingir o Objetivo da Sprint dentro do Timebox.

O critério utilizado para ordenação do Backlog é definido pelo PO, que pode utilizar diversas técnicas conforme a necessidade, como por valor, por prazo (caso seja uma ação de marketing ou determinação legal), por risco, por dependência técnica ou de negócio…

Os critérios são muitos e cabe ao Product Owner decidir qual o melhor critério para o momento vivido pelo Produto. Já a estimativa é de responsabilidade do Time de Desenvolvimento que são os executores. Contudo, o PO ajuda na determinação e entendimento do escopo.

Uma imagem contendo uma explicação sobre o Backlog do Produto

Por seu dinamismo, o Backlog do Produto é considerado um artefato vivo uma vez que está em constante mudança a fim de garantir a adequação e maximização do valor do Produto.

Os Itens de Backlog geralmente são escritos como Histórias de Usuários, embora o Scrum não especifique um formato padrão. Qualquer que seja a forma escolhida é uma boa prática conter uma descrição, qual a estimativa de esforço, qual o valor pretende gerar ao negócio, quais são os critérios de aceite e quais testes devem ser realizados. Esses atributos contribuem para comprovar a completude do PBI quando “Pronto”.

Características de um bom Backlog do Produto

Um bom Backlog do Produto deve ser DEEP e o PO deve ser um bom FDP. Calma, não é isso que você está pensando! Te explico abaixo cada conceito.

DEEP é o acrônimo que significa que o backlog deve ser: Detalhado apropriadamente, Estimado, Emergente e Priorizado.

Quando dizemos que o PO deve ser um bom FDP estamos nos referindo a ação do PO: Fatiar, Descartar e Priorizar.

Conclusão

O Backlog do Produto é um artefato vivo e a entrada para todo o fluxo de Eventos do Scrum. Enquanto existir Produto, existirá Backlog para ele. A priorização de melhorias, correções, débitos técnicos e refinamento é de responsabilidade do PO, que deve ser uma única pessoa para evitar conflito de interesses e dificuldade na tomada de decisão quanto ao escopo do Produto e a prioridade na sua execução.

Eleve o nível de seus conhecimentos com treinamentos oficiais da Scrum.org. Clique aqui e confira a agenda completa!

É Product Owner ou pretende atuar neste papel? Baixe agora nosso e-book gratuito “8 instâncias do Product Owner” e aprenda as diferentes formas de atuaçãono trabalho de criação de produtos/serviços e na geração de valor ao cliente.

Leia também:

Entenda melhor o que é o papel de Scrum Master e como ele atua dentro de um time

Como o nome já diz, o Scrum Master (SM), é o Mestre do Scrum, ou seja, é a figura responsável por promover e suportar o Scrum dentro das organizações. Porém, como o Scrum Master faz isso?

Coach free icon

O Product Owner (PO) é responsável por construir o produto certo. O Time de Desenvolvimento (Time) é responsável por construir o produto do jeito certo. O Scrum Master ajuda todo o Time Scrum e a organização a entender a teoria, prática, regras e valores do Scrum.Por este motivo, o SM é chamado de líder-servidor, pois é um papel que busca auxiliar o entendimento do Scrum e as interações que o Time Scrum tem com o restante da organização, quais dessas interações são úteis e como os processos estabelecidos podem ser melhorados para que o Time Scrum entregue valor continuadamente e atinja a alta performance.

Dessa forma, o SM trabalha suportando o PO, o Time de Desenvolvimento e a Organização.

SM suporta o PO:

SM suporta o Time:

SM suporta a Organização:

Instâncias do Scrum Master:

Uma das instâncias do SM é a realizar o Coach do Time Scrum ajudando na redução da barreira entre eles. Não é incomum o cenário em que Time de Desenvolvimento e Product Owner se veem em lados opostos, como opositores. Obviamente que essa é uma visão completamente errada entre as contrapartes, uma vez que ambas necessitam uma da outra.Nesse cenário complexo, cabe ao SM ajudar o Time Scrum a reconhecer como todas as partes colaboram entre si, reduzir esse distanciamento e ajudá-los a seguir na jornada ágil, avançando em maturidade e resolvendo seus próprios problemas.

O SM atua também como Facilitador buscando sempre a melhoria do processo estabelecido e facilitando os eventos do Scrum: Sprint Planning, Sprint, Daily Scrum, Sprint Review e Sprint Retrospective.

Outro papel do SM é de ser Removedor de Impedimentos. Impedimento é definido como o que excede a capacidade de auto-organização do Time e que possa comprometer que o Objetivo da Sprint seja alcançado. É comum o Time demandar algumas coisas para o SM que não sejam necessariamente um impedimento e não há nada que impeça o SM de colaborar com o Time na realização dessa demanda. Contudo, é importante que o SM não vire um “secretário” do Time, causando assim uma disfunção em seu papel e tomando seu tempo com atividades que não geram valor e não contribuem para a maturidade do time.

O SM atua como um Agente de Mudanças da organização à medida que provoca mudanças que ajudem cada vez mais o Time Scrum a performar.

Para mais detalhes sobre as instâncias do SM , te convido a ler o artigo “As 8 Instâncias do Scrum Master” disponível aqui no nosso blog.

Características do Scrum Master:

O SM deve ser um profundo conhecedor do Scrum por ser a pessoa responsável por propagar os valores, pilares e regras do Scrum dentro das organizações. Ele não precisa ter domínio do conhecimento técnico e nem de negócio, mas sem dúvida, ter um bom conhecimento nessas disciplinas o torna um bom questionador, sendo um diferencial para o processo de coaching do Time.

Um bom questionador geralmente é paciente e esta é outra característica que um grande Scrum Master deve ter, pois o processo de coaching exige do SM tempo para que o time alcance a resposta esperada. Ainda que o SM acredite que saiba a resposta, levar o time a encontrá-la é o melhor caminho, pois a solução que emerge do conhecimento coletivo pode ser preferível à que o SM acreditava. Mais do que isso: quando o Time encontra suas próprias soluções gera mais engajamento e comprometimento uma vez que foi o próprio Time que chegou aquela conclusão.

Ser colaborativo é uma característica nata do Scrum Master, por ser um papel que trabalha com várias frentes (PO, Time e Organização) ele precisa ser bastante colaborativo. Como coach do processo, o SM contribui na busca de novas oportunidades de melhoria.

Conclusão

O papel do Scrum Master é incompreendido em muitas organizações por não ser um papel técnico. Um grande Scrum Master precisa desenvolver tanto soft skills quanto hard skills pois a maior parte do tempo gasto pelo SM é com o processo e com as pessoas envolvidas neste. A empatia e a escuta ativa são ingredientes fundamentais para o desenvolvimento do trabalho do SM.

Assista: Scrum master recém chegado, o que fazer?

Leia também: O que é a Sprint Planning?

 

E se você está começando ou pretende atuar como Scrum Master e quer elevar o seu nível de conhecimento – e ainda obter sua certificação pela Scrum.org, conheça nosso treinamento Professional Scrum Master.

Agora se você já atua como Scrum Master e precisa se aprofundar em técnicas mais avançadas, o treinamento Professional Scrum Master II é ideal para isso.

Aproveite, pois estamos com turmas abertas para esses e outros cursos. Clique aqui e confira nossa Agenda completa!

 

Saiba como implementar o Scrum e outros métodos ágeis para agregar mais valor ao seu trabalho atual ou iniciar em uma das carreiras que mais crescem no Brasil

Você já deve ter ouvido muito falar sobre os tais métodos ágeis, como o Scrum, Kanban, entre outros, ficou pesquisando sobre eles, mas não descobriu como aprender de verdade? Está tentando implementá-los na prática e não está vendo o real valor que eles proporcionam? Ou quer mudar de carreira e sabe que isso vai te ajudar? 

Se sua reposta foi sim, mas não sabe nem como começar, separamos algumas conselhos indispensáveis para você usar a Agilidade para alavancar ou mudar de carreira. Seja para mudar de profissão ou para gerar mais resultados ao seu atual trabalho, confira essas quatro dicas:

Conheça primeiro a mecânica do framework. 

Se você acha que está ficando para trás no mercado de trabalho ou se sua empresa está implementando a Agilidade e você já sabe que é algo que precisa aprender, comece pelo começo, literalmente. Não faça treinamentos mais avançados, neste momento!

Muitos pensam que é melhor investir em saber mais sobre o papel de Scrum Master ou de Product Owner, entretanto, o ideal é começar mesmo pelos fundamentos do Scrum (aqui na Agile School temos o treinamento Applying Professional Scrum, certificado pela Scrum.org). São esses treinamentos mais focados na mecânica e nos fundamentos que te darão embasamento para iniciar no mundo da Agilidade. 

Clique aqui e assista agora nosso minicurso 100% GRATUITO de introdução ao Scrum!

Se aprofunde e incorpore o mindset ágil! 

Isso mesmo, depois de conhecer a mecânica do Scrum, quais são seus elementos e como ele funciona, se aprofunde e integre realmente a Agilidade em seu dia a dia. Por exemplo, você sabe porque a Sprint Planning tem no máximo 8 horas? A Agilidade pode ser usada em qualquer ambiente? Por que existe o Manifesto Ágil? 

Ou seja, busque solucionar esses questionamentos mais avançados. Não basta saber todo o framework apenas na teoria e não saber o seu valor na prática. Por isso, é essencial mudar o mindset para poder aproveitar todos os potenciais dessas novas ferramentas de trabalho.

Entre numa dinâmica de prática desse novo aprendizado. 

Quando se quer mudar de carreira, é muito relevante colocar em prática todo esse novo conhecimento que vem sendo adquirido… E na Agilidade não é diferente! Se você não praticar os elementos do Scrum no dia a dia, você terá dificuldade em assimilar e realmente incorporar essa novidade.

Por isso, tente colocar o Scrum em prática no trabalho que você está hoje, seja esse agente de inovação. Ou até comece a implementar de forma voluntária em algum projeto ou ONG, por exemplo. Isso é fundamental para te dar um pouco de experiência prática, principalmente se seu objetivo é mudar de emprego. 

Geralmente, as pessoas que estão querendo mudar de carreira já possuem um pouco mais de bagagem e, para começar em uma área nova, é comum dar um passo para trás, aceitando ofertas de emprego com remunerações menores e posições mais iniciantes. Tal como um gerente de projetos pleno/sênior, que está começando no universo de Agilidade, ele não se tornará um Scrum Master nesse mesmo nível logo no ínicio.

Mas não se preocupe pois a escalada é rápida, já que o mercado está aquecido! Vale lembrar que o Especialista em Agilidade é um dos trabalhos que mais crescem nos últimos tempos, segundo um estudo publicado pelo LinkedIn, sendo considerada uma das 15 profissões emergentes de 2020 no Brasil.

Se envolva em uma comunidade. 

Participe de meetups, webinars, eventos e comunidades do universo de Agilidade. Não apenas para trocar informações, tirar dúvidas e ter mais aprendizados com profissionais de diversos níveis e áreas, mas para aumentar seu networking também. Essa conexão com comunidades é super enriquecedora e ainda pode te render uma nova oportunidade de trabalho!

E para saber mais sobre os nossos treinamentos, acesse nossa AGENDA clicando aqui!

Assista também:

Dicas para começar a usar o Scrum do zero
Uma imagem contendo equipamentos eletrônicos

Descrição gerada automaticamente

Estrutura de Times

Por que estruturar times?

A forma como seu time está estruturado tem um impacto significativo no sucesso do negócio. Quando falamos em modelos de equipe, estamos buscando a estrutura mais otimizada e que nos leve a melhores resultados. 

Se você está numa iniciativa de pequeno porte, uma equipe multifuncional provavelmente é suficiente para dar conta do recado. Contudo, à medida que sua empresa ou produto vai ganhando corpo, naturalmente surge o desejo de criar novos times, de crescer a estrutura, de acelerar a entrega de valor.

Porém, como essas equipes devem se estruturar de modo a alcançar coordenação, comunicação e performance?

Equipe de Componentes x Equipe de Feature 

times

Equipes de Componentes têm a responsabilidade sobre determinado componente, tornando mais fácil sua padronização e manutenção. Todo o foco do time está voltado à tecnologia e não ao negócio. Portanto, equipes de componentes não possuem todas as habilidades necessárias para entregar uma feature de ponta-a-ponta, ou seja, estão mais voltadas a práticas waterfall atendendo a diversas demandas porém de uma única fase.

São compostas por especialistas e possuem referência técnica dentro do próprio time, onde é comum haver ver uma certa segregação do conhecimento, onde geralmente o mais sênior é o líder/gerente da equipe.

Por não responder a uma feature em específico, precisam lidar com diferentes prioridades que podem acabar por impactar a entrega de outros times e consequentemente no desenvolvimento, lançamento ou respostas à mudança daquela feature. Prática comum é a famosa fila de demandas (first in, first out). 

incremento

Equipes de Feature são mais utilizadas em uma abordagem ágil por estarem focadas na entrega ao cliente de ponta-a-ponta, promovendo um menor tempo de resposta ao usuário final. Dessa forma equipes de feature tendem a criar funcionalidades mais user-centered, pois vivem mais a dor do cliente.

Essa entrega mais rápida é possível, pois times de features devem possuir todas as habilidades para entregar a feature por completo, reduzindo assim a dependência externa. Contudo, os códigos de componentes estarão distribuídos pelas features, ou seja, sua manutenção dependerá de maior comunicação entre os desenvolvedores, podendo contribuir para o aparecimento de débito técnico, subotimização ou inadequação de padrões arquiteturais.

Imagine a seguinte situação:

Existem 3 times de componentes (UX, Front, e Back) responsáveis por um único produto. A feature “Catálogo de Produtos” é então dividida para cada time, que ao final da Sprint deverá entregar um incremento integrado com os demais componentes. Até aqui tudo ok. A chance de dar algum problema é baixa, mas pode acontecer, caso algum time de componente não consiga entregar a sua parte, então todo o incremento estará em risco.

Agora imagine que esses mesmos 3 times de componentes, precisam trabalhar em 2 demandas diferentes: “Catálogo de Produtos” e “Pagamento”. Ao final da Sprint, os 3 times devem entregar sua parte de componente integrada ao incremento. Caso algum time não entregue, aquele incremento estará em risco, certo? A mesma coisa que aconteceu no exemplo anterior, mas dessa vez, há um detalhe a mais: E se o time de componente 1 priorizar a demanda de Catálogo de Produtos e os demais times priorizarem a demanda de Pagamento? Pode acontecer de, no final da Sprint, nenhum dos dois produtos terem um incremento entregue! Conseguem imaginar se tivermos 5, 10, 15 demandas para esses 3 times de componentes? A probabilidade de falha nessa entrega é enorme!

Para solucionar esse problema, podemos estruturar a equipe, como equipe de features, assim, todas as habilidades necessárias para criar uma feature estará dentro de um único time e não precisaríamos terceirizar uma parte de um componente.

Equipes de features reduzem a dependência externa e focam na feature como um todo enquanto equipes de componentes tem um foco mais individual e aumento de dependência externa

Uma forma de melhorar a comunicação entre os desenvolvedores de um mesmo componente cross-feature é adotar a estrutura representada abaixo, onde, na linha vertical temos a disposição de equipe de features, e na horizontal, os desenvolvedores organizados em componentes distribuídos nas features.

Essa é uma forma de alinhar padrões, tecnologias, conhecimentos e compartilhar problemas do dia a dia com os pares. Portanto, a estrutura horizontal é composta por desenvolvedores que possuem um mesmo domínio técnico – por exemplo UX – disposta em um nível hierárquico o qual geralmente é representado por um líder técnico.

Na vertical estamos otimizando a entrega de valor, na horizontal estamos otimizando a qualidade da camada/componente.

times

Fechamento

Embora pensando em escalabilidade a adoção de times de features seja mais adequada, não existe um veredicto em que a escolha pela abordagem de equipes de componentes não deva ser realizada. Muito depende do atual momento de transição da organização, de como as habilidades técnicas estão distribuídas e como a arquitetura técnica das features estão desenhadas.

É natural para empresas que estão fazendo transformação digital, haver uma transição de times de componentes para times de features. Já para startups, ainda em processo de amadurecimento da sua estrutura, os times de features acabam ocorrendo naturalmente pois geralmente começam com um ou poucos times multi-funcionais.

De forma geral, é comum encontrar os 2 tipos de estrutura em uma organização. Cabe analisar qual é a melhor configuração e distribuição de estrutura dentro do seu contexto.

quadro estrutura

O que é a Sprint Review?

A Sprint Review é o penúltimo evento da Sprint, geralmente acontece no seu último dia e tem por objetivo a inspeção do Incremento de Produto desenvolvido naquela Sprint e adaptação do Product Backlog caso necessário.

Esse é o único evento no qual, por definição, temos a participação de pessoas externas ao Time Scrum. Esses “envolvidos” na criação do produto, seja um patrocinador, membro da área usuária, parte da governança corporativa, compliance ou qualquer papel que tenha interesse e influência sobre o escopo da solução, devem ser convidados pelo PO para estarem presentes.

Portanto, o fórum participante da Sprint Review é todo o Scrum Team (PO, SM e Dev Team) e os Stakeholders. A ideia é que todos deem feedback sobre o que já foi feito, troquem informação, discutam as oportunidades de mercado para o produto e colaborarem sobre o que vem a seguir.

Como acontece a dinâmica?

A Sprint Review tem uma dinâmica sugerida pelo Scrum Guide. O evento começa com o Product Owner falando sobre o Objetivo da Sprint e quais itens estão “Prontos” – ou seja, aqueles que atenderam a definição de pronto estabelecida – e quais não estão, caso o Sprint Backlog não tenha sido completamente concluído. Contudo, esta não é uma reunião de status e a apresentação do incremento destina-se a motivar, coletar feedback e promover a colaboração.

Em seguida, o Time de Desenvolvimento apresenta o que foi bem dentro da Sprint, que problemas ocorreram e como estes foram resolvidos, e por fim realiza uma demonstração do incremento “Pronto” e que estará disponível para ser lançado.

Por fim, o PO fornece uma visão de budget, roadmap de produto e prováveis próximas datas de entrega. Além de ser mais uma oportunidade para todos colaborarem sobre os próximos passos, possíveis dependências externas e débitos técnicos previamente conhecidos devem estar mapeados e dar transparência para todos os presentes.

Cabe ao Scrum Master garantir que o evento ocorra e que os participantes entendam o seu propósito, ensinando a todos os envolvidos a manter a reunião dentro do time-box (limite máximo de tempo). Como referência, para Sprints de 4 semanas, o time-box da Review é de 4 horas e proporcionalmente menor para Sprints menores.

 

Nenhum incremento pode ser mostrado? E agora?

Mesmo na ocasião do time Scrum não ter um incremento pronto para inspecionar, a Sprint Review deve ser mantida como uma forma de:

1º) dar transparência aos stakeholders do trabalho desenvolvido, não é porque não houve entrega de incremento pronto, que o time não trabalhou;

2º) obter feedback dos stakeholders;

3º) mostrar os avanços e problemas encarados pelo time, como esses problemas impactaram a entrega e como foram resolvidos.

Conclusão

Ciclos curtos permitem que o Time Scrum foque no objetivo da entrega de valor. A Sprint Review tem o objetivo de mostrar a entrega sem causar “distúrbios” ao time ao longo da Sprint, ou seja, como as Sprints são curtas, o loop de feedback é rápido, o stakeholder não fica descolado do andamento do produto e assim o time consegue manter o foco naquilo que é importante, evitando interrupções ao longo do desenvolvimento, e as Reviews passam a ser uma oportunidade tanto de inspecionar o incremento, quanto de adaptar o Backlog do Produto caso seja necessário corrigir o seu curso, seja por estratégia, mudança de mercado ou tecnologia.

Se por outro lado, não houvesse essa oportunidade de ao menos uma vez ao mês, stakeholders estarem alinhados, o risco do time trabalhar em algo desalinhado com a entrega de valor cresceria de forma acentuada. Se assumirmos que o plano inicial está sempre certo e não fizermos esses alinhamentos intermediários, provavelmente ao final da entrega teremos surpresas e frustrações por parte do cliente.

Vamos falar sobre a Sprint Planning, o primeiro evento numa Sprint do Scrum. Nela acontece o planejamento do que o time buscará realizar, o objetivo a cumprir e o desenho de um plano, ou seja, as ações necessárias para cumprir com uma entrega de valor dentro dos próximos 30 dias ou menos.

Como funciona a Sprint Planning?

O evento tem um timebox (tamanho máximo) de 8 horas para Sprints de 30 dias e geralmente utiliza de menos tempo para Sprints menor duração. Os participantes são todos os membros do Time Scrum: Product Owner, Scrum Master e Development Team. Assim como em todos os eventos do Scrum, na Planning temos um input (entrada de informações), um processamento (entendimento, discussão e tomada de decisão) e um output (saída de um plano).

Quais são os inputs da Sprint Planning?

O elemento mais simples (e óbvio) trazido como entrada para a Planning é o Product Backlog (PB). O PB é uma lista extensa e ordenada contendo os desejos e características funcionais e não funcionais que devem ser parte do produto, serviço ou solução a ser construída.

O segundo elemento trazido para a Planning são a capacity e velocity do time. Mas o que que significa isso? A capacity representa a capacidade de trabalho do time, seja a quantidade de pessoas e a quantidade de dias da Sprint. Por exemplo, precisamos saber se todos do time estarão presentes todos os dias da Sprint, se alguém sairá de férias ou terá de ausentar para uma consulta médica. Nessa Sprint temos todos os dias “úteis” e dedicados ou teremos um feriado, treinamento ou evento corporativo?

Outro item a ser considerado é velocity ou velocidade do time. Isso diz respeito ao histórico de quanto de trabalho esse time conseguiu executar nas Sprints anteriores. Todos esse itens nos ajudarão a fazer um bom planejamento.

O terceiro elemento trazido para a Sprint Planning é a Definition of Done ou Definição de Pronto. Esse item é essencial pelo simples fato que estamos executando um planejando das atividades de trabalho para a Sprint. Para termos um planejamento mais assertivo, é necessário que todos os membros do time tenham um mesmo conceito de completude. Quais as atividades devem ser preenchidas para que cada item da Sprint possa ser considerado pronto?

Por último, temos o plano de melhoria que foi gerado na Retrospectiva da Sprint anterior. Por que isso deve fazer parte da Planning? Pelo simples fato que ao menos uma ação de melhoria traçada na Retrospectiva da última Sprint deve fazer parte da Sprint atual. Isso é uma regra que obriga o time Scrum a ter dinâmica de melhoria contínua e toma tempo do time, e portanto, deve ser considerada no planejamento.

O processamento da Planning

Dentro da Planning acontecerá o processamento de todos esses inputs mencionados. O time terá um momento de alinhamento, discussão, priorização, estimativa, criação para que possa construir um plano para Sprint que se inicia.

Não existe uma regra formal para executar a Planning. O framework Scrum permite o formato que o time achar conveniente. Uma sugestão pode ser o Product Owner iniciar com uma explicação sobre os primeiros itens do Product Backlog, que são os itens de maior prioridade. O Time de Desenvolvimento pode fazer a estimativa ou quebrar esses itens em tarefas menores, caso isso já não tenha sido feito numa atividade de refinamento.

O Time de Desenvolvimento determina a quantidade de trabalho que pode realizar dentro da Sprint. Isso geralmente é feito por heurísticas (práticas complementares), ou seja, não fazem parte do Scrum e cada time escolhe a prática que mais se adequa. A prática mais conhecida de estimativa é o Planning Poker, porém estimativas em horas ou projeções estatísticas (Probabilistic Forecast) da quantidade de trabalho que o time consegue executar também podem ser utilizadas.

Quais os outputs da Sprint Planning?

São três os elementos resultantes da Planning. Esses itens são uma decomposição um do outro e podem ser sintetizados pelas expressões PORQUE, O QUE e COMO.

O primeiro elemento é o Sprint Goal que simboliza uma meta a ser alcançada na Sprint, demonstra um objetivo comum compartilhado e um PORQUE para o time.

Em segundo lugar temos o Sprint Backlog que por sua vez pode ser dividido em duas partes. A primeira parte do Sprint Backlog é composto por O QUE nós vamos fazer. Esses são os PBIs (Itens do Product Backlog) que o time escolhe fazer dentro da Sprint, sendo uma previsão do que o time consegue construir. E por último vem o COMO o time vai trabalhar. São as tarefas que o time vai executar para implementar os PBIs.

Resumindo, temos o Sprint Goal (PORQUE) que pode ser atingido por meio dos PBIs (O QUE), que podem ser implementados por meio das tarefas (COMO), ambos são sintetizados no Sprint Backlog.

Esses são os Inputs, Processamento e Output de uma Sprint Planning. O grande princípio a ser levado em conta é, como tudo no Scrum, que seu time deve inspecionar o melhorar continuamente. Avalie o que estão fazendo, teste novas abordagens e reestruture a Planning para que seja mais efetiva possível na construção de um plano para a próxima Sprint.

Te vejo na próxima, Scrum On!

Momento curiosidade:
Você sabia que a Sprint Planning tinha um outro formato no passado?
Não sei há quanto tempo você já trabalha com Scrum, mas se for há mais de 5 anos, com certeza já ouviu falar dos termos Sprint Planning 1 e Sprint Planning 2. Pode ser que alguns desavisados ainda utilizam esses termos, porém eles não fazem mais parte da definição do framework Scrum. Por volta de 2013 o Scrum Guide foi revisto e Planning passou a ser um evento único, sem as tais divisões.

menu