Concrete Logo
Hamburger button

Como aplicar os valores Scrum no dia a dia?

  • Blog
  • 23 de Abril de 2019
Share

Ao longo da minha jornada como Scrum Master, tenho notado cada vez mais a necessidade de que relembrar e reforçar os valores do Scrum. Isso porque muitas vezes ficamos mais preocupados com os papeisartefatoseventos e regras descritos no Guia do Scrum do que com a base do framework efetivamente. 

De um modo geral, tenho percebido que alguns Scrum Masters, ao assumir um Time Scrum, se comportam de um modo um pouco impulsivo, começando a implementar eventos quase que imediatamente, por exemplo. Já partem para envolver a equipe em Reuniões de Scrum Diárias, definir regras e papeis, falar sobre Backlog do Produto e incremento…. mas nada disso é mais essencial do que conhecer o time e o cenário em que ele se encontra, incluindo o nível de maturidade tanto do time quanto dos stakeholders. Não ser um bom ouvinte e ignorar a situação atual pode comprometer o relacionamento com as pessoas, e voltar aos “primórdios” do framework pode nos ajudar bastante nesse sentido.  

Então vamos entender um pouco mais sobre a essência do Scrum? Bom, os valores do framework apareceram pela primeira vez na versão do Guia do Scrum de 2016. Como dizem os próprios autores,  Ken Schwaber e Jeff Sutherland“quando os valores do Scrum são assumidos e vividos pelo Time Scrum, os pilares do Scrum de transparência, inspeção e adaptação tornam-se vivos e constroem a confiança de todos

Segundo o Guia do Scrum de 2016, são cinco os valores do Scrum, e eles representam comportamentos e o que chamamos de mindset ágil. São eles:

Fonte: http://www.fabiocruz.com.br/wp-content/uploads/2016/09/valores-scrum.gif (modificado)

 

Coragem: o Time Scrum tem que ter coragem para fazer a coisa certa e trabalhar em problemas difíceis. 

Foco: todos focam no trabalho da Sprint e nos objetivos do Time Scrum. 

Comprometimento: as pessoas se comprometem em alcançar os objetivos do Time Scrum. 

Respeito: os membros do Time Scrum respeitam-se mutuamente para serem pessoas capazes e independentes. 

Abertura: o Time Scrum e seus stakeholders concordam em estarem abertos a todo o trabalho e aos desafios com a execução desses trabalhos. 

 

Exemplos Práticos dos Valores do Scrum com Foco nos Eventos do Scrum

“A definição do Scrum consiste em papeis, eventos, artefatos e as regras do Scrum, que unem os demais e os mantêm integrados”.

2016, Guia do Scrum 2016, p.3

Para dar exemplos de situações em que esses valores devem ser praticados, resolvi relacioná-los aos quatro eventos do Scrum: Sprint, Planning, Review, Daily e Retrospectiva. Vamos a eles:

Coragem:

Imagine que a Sprint já teve início e o time está trabalhando os itens 1 e 2. No terceiro dia, o Product Owner cede à pressão do cliente, que solicitou para tudo e focar o trabalho nos itens 3 e 4. Neste contexto, o Time de Desenvolvimento precisa de coragem para avisar ao Product Owner o impacto da interrupção, a todo tempo, com troca de prioridades. Na Planning, considere que o objetivo da Sprint já foi definido e já se sabe de quais itens do Backlog precisamos para atingi-lo. Agora é hora de determinar quais itens do Backlog do Produto vão entrar na próxima Sprint, ou seja, o que vai ser o Backlog da Sprint. Para isso, o Time de Desenvolvimento se reúne para fazer o “planning poker”, uma dinâmica em que cada membro expõe a estimativa de quantos pontos de estória (ou “story points”) cada item tem, com base no esforço que ela demanda. Aqui os devs também precisam de coragem para estimar o esforço corretamente.

Em uma Review, imagine que o Time de Desenvolvimento não conseguiu atingir o Objetivo da Sprint a que se propôs atender, porque subestimou a complexidade dos itens. Fica claro, né? É necessário coragem para assumir que a Sprint falhou. Na Daily, se o time não tiver coragem para informar seus impedimentos, a evolução do time fica comprometida. Por fim, é na Retrospectiva que o valor coragem deve ser o mais aplicado. Os pontos a melhorar podem ser polêmicos, e todo o time deve ter segurança e coragem para expor o que não funcionou bem.

Foco:

Agora pense que durante uma Sprint, também chamada de “iteração”, cada desenvolvedor escolha trabalhar em um item do Objetivo da Sprint. Assim, o risco de começar e não terminar é grande. É por isso que recomendamos o pair-programming, em que dois desenvolvedores trabalham pareados em uma mesma atividade. Assim, paramos de começar e começamos a terminar, evitando desperdício e gerando valor mais rapidamente. Aqui, o foco é muito importante para priorizar e desenvolver um item de cada vez na Sprint. Costumeiramente, dizem que a Planning pode ser dividida em duas partes. Eu, porém, digo que são quatro: definição do Objetivo da Sprint; estimativa do esforço das estórias; seleção das estórias que devem fazer parte do Backlog da Sprint, considerando a prioridade pré-definida pelo Product Owner, e por fim a quebra de cada estória. Para não perder tempo estimando e quebrando estórias com baixa prioridade, o Time de Desenvolvimento trabalha com foco. Com base na quantidade de story points que conseguiu completar na Sprint anterior, o time discute se pretende fazer a mesma ou uma maior quantidade na próxima Sprint e define qual esses story points. Daí, levando em consideração a ordem de prioridade estabelecida pelo Product Owner, seleciona as atividades, das mais prioritárias para as menos, e somam o esforço que eles acreditam dar conta de cumprir.

Na Review, pode acontecer de o Product Owner discutir com o Scrum o Backlog da Sprint, do jeito que está, e projetar uma meta ou datas de entrega. Neste momento, é importante que o Time inteiro esteja focado em colaborar, dando opinião a respeito do que fazer em breve, pois isso pode gerar inputs valiosos para a Planning, que vem na sequência. Na Daily, o foco é muito importante para não virar uma reunião de status report. Imagine que o time está discutindo seu progresso em relação ao Objetivo da Sprint e de repente é interrompido pelo Product Owner que abruptamente questiona sobre o prazo de entrega. Nem um pouco legal, não? O time pode se basear nesse valor para evitar esse tipo de situação. Por fim, considere que em uma Retrospectiva o cliente começa a falar de bugs que precisam ser consertados com urgência. Para seguir o objetivo da reunião, que é inspecionar o que funcionou bem e o que pode ser melhorado para a próxima Sprint quanto a pessoas, ferramentas e relacionamentos, o Scrum Master pode agir e levar o time a focar nesse propósito. Para ajudar com isso, uma dica é anotar em uma área de “Parking Lot”, na parede, a questão do bug para ser discutida em outra oportunidade.

Comprometimento:

Desde o início até o fim da Sprint o Time de Desenvolvimento deve zelar pela qualidade, que não deve diminuir ao longo da Sprint. O Scrum Master pode ensinar e incentivar o Time de Desenvolvimento a criar seus próprios “DoR” (Definition of Ready) e “DoD” (Definition of Done) para estimular o comprometimento com a qualidade do incremento a ser entregue, respectivamente, na entrada e na saída da Sprint. Na Planning, depois de definido o objetivo da Sprint, o Time Scrum precisa também de compromisso para escolher itens que ajudem a atingir o objetivo e a entrega do incremento ao final da Sprint. Durante uma reunião de Review, o Time de Desenvolvimento apresenta seu incremento de produto potencialmente lançável às partes interessadas, visando obter feedback para melhorias futuras. Aqui, também é importante que os stakeholders estejam comprometidos em dar o feedback sobre o incremento do produto entregue e exibido nessa reunião. Só assim conseguimos melhorias constantes.

Por dois dias seguidos se vê que o Time de Desenvolvimento se estendeu na Daily em 10 minutos, estourando o timebox de 15 minutos. É usando o comprometimento como valor que o Scrum Master deve reforçar ao Time de Desenvolvimento que o timebox da Reunião Diária de Scrum precisa ser respeitado e procurar ajudá-lo a entender o porquê de isso não ter ocorrido recentemente. Logo após discutirmos os pontos positivos que ocorreram na Sprint recém-finalizada e também os pontos a melhorar em uma Review, é hora de definir ações para o que não funcionou bem quanto a processos, ferramentas ou relacionamentos. Aqui, só com comprometimento o Time Scrum pode criar um plano para implementar melhorias à forma de trabalho.

Respeito:

A Sprint está em progresso e, a dois dias do fim, o Product Owner decide incluir no Backlog da Sprint itens que o cliente acabou de colocar em suas metas. Além de ir contra o Objetivo da Sprint definido na Planning, essa intervenção fará com que o Time de Desenvolvimento perca o foco dos itens a que está se dedicando e, como o PO colocou itens de maior esforço no topo, o Objetivo da Sprint pode ser impactado. Aqui, o Product Owner precisa tomar cuidado ao absorver demandas do cliente sem antes obter e respeitar o parecer do Time de Desenvolvimento, pois mudanças que prejudicam o Objetivo da Sprint consequentemente impactam a evolução do produto.

Durante uma Planning pode ser que seja implementado o “planning poker”, em que o Time de Desenvolvimento estima o esforço dos itens que possivelmente farão parte da próxima Sprint. Durante essa dinâmica, quando há divergência de opinião entre os devs, a ideia é que eles exponham o raciocínio que está por trás de sua escolha. Uma vez discutida a quantidade de story points planejada para a próxima Sprint, pode acontecer de o Product Owner, por exemplo, sugerir que os devs se comprometam com um determinado número de story points ao invés de deixar o Time de Desenvolvimento decidir. Aqui, é importante lembrar que a opinião dos devs sobre a quantidade de story points a ser assumida para a próxima Sprint não só deve ser respeitada como considerada, já que o Time de Desenvolvimento é quem realmente “coloca a mão na massa” e está ciente da real complexidade de cada item.

Imagine que um dia antes da Review um cliente resolve cancelá-la, pois acredita que ela vai atrapalhar o trabalho do Time de Desenvolvimento, que tem muito o que fazer. É papel do Scrum Master, nessa situação, garantir que os participantes da reunião compreendam seu propósito, fazer com que respeitem sua cadência, e explicar que adiar esse evento seria o mesmo que estender o período da Sprint, pois causaria impacto direto nas métricas do Time de Desenvolvimento. O comparecimento às Dailys também é uma questão de respeito. Caso uma pessoa sempre chegue atrasada, é papel do Scrum Master explicar a ela o valor da reunião em questão e a importância de se respeitar as outras pessoas do time que entendem a importância da cadência diária e do horário combinado. A Retrospectiva é uma ótima oportunidade para aplicar o conceito de respeito, porque é ao discutir os pontos negativos e positivos da Sprint que temos que respeitar a opinião de cada um do time e ter empatia com cada ponto exposto. Além de, é claro, todos respeitarem o objetivo da reunião, que é o de inspecionar como foi a última Sprint em relação a pessoas, relacionamentos, processos e ferramentas.

Abertura:

Imagine que, durante uma Sprint, o cliente solicita coisas urgentes que devem gerar impacto direto ao cliente final, causando perdas financeiras, mas apesar disso nada têm a ver com o Objetivo inicial definido. Neste contexto, qualquer pessoa do Time Scrum tem que ter abertura para sugerir ao Product Owner o cancelamento da Sprint por perda de sentido do Objetivo. Durante a Planning, logo após a definição do Objetivo da Sprint pelo Time Scrum e, consequentemente, a seleção de itens a serem realizados na próxima Sprint, é hora de o Time de Desenvolvimento decidir como fará e, se necessário, quebrará esses itens da maneira que lhe for mais conveniente. A Abertura aqui também é essencial para que o time decida como vai transformar a funcionalidade em um incremento de produto “pronto”. Durante a Review, o Time de Desenvolvimento demonstra às partes interessadas o trabalho que foi “Feito”, e dessa vez os stakeholders é que precisam de abertura o suficiente para fazer perguntas ao Time de Desenvolvimento sobre o incremento entregue.

Em uma Daily, o Time de Desenvolvimento precisa de abertura para liderar a reunião da maneira que achar mais produtiva, sem ter que, necessariamente, responder às três perguntas do Scrum Guide em relação ao Objetivo da Sprint. O importante é saber se há algo o impedindo de atingi-lo, traçar um plano para as próximas 24 horas e se alinhar quanto ao que tem sido feito. Para a Retrospectiva, também é necessário abertura para que o time aponte os pontos de melhoria para a próxima sprint.

Conclusão

Apesar de estarem presentes no Guia do Scrum desde 2006, os cinco valores do Scrum muitas vezes passam despercebidos pelos praticantes que, devido à dinâmica do dia a dia, acabam focando mais nos papeis, artefatos, eventos e regras, e deixam em segundo plano o que de fato está relacionado aos pilares do framework de transparência, inspeção e adaptação. Baseada em minha própria experiência, tentei trazer a esse post exemplos práticos de como aplicar os valores aos eventos do Scrum para gerar valor. Isso porque aplicar o framework de forma mecânica, sme analisar bem o cenário complexo, pode causar efeitos catastróficos para o relacionamento entre as partes interessadas, entre outras armadilhas.

Por isso, é importante que os valores sejam lembrados a todo momento e inclusive usados como argumentos para reforçar a segurança do time. Ficou alguma dúvida, tem alguma dica a mais ou quer acrescentar algo? Aproveite os campos abaixo! Até a próxima =)