Trilha de Valor #10: Não tem certo nem errado
Tempo de leitura: 12 minutos
Olá,
A edição de hoje foi inspirada na frase que mais ouvi nos últimos dias: "Não tem certo nem errado". Apesar de nem sempre ter sido direcionada para mim, em todas as vezes que a frase foi citada eu pensei no que estava duvidando sobre o meu trabalho.
Depois de alinhar as expectativas com o time que venho trabalhando, ajustei a proposta de trabalho que costumo fazer antes de iniciar a primeira Sprint e algumas dúvidas surgiram. Mesmo ouvindo constantemente que não existe certo nem errado e sabendo que já iniciei Sprints diversas vezes, fui atrás de leituras e feedbacks a respeito da minha proposta.
Na seção "Falando sobre agilidade", pretendo compartilhar a lógica por trás do material que montei e dos insights que tive pensando sobre como tomamos algumas práticas como padrão, sem ao menos questionar de onde vieram.
E, apesar de ter dito na edição anterior que estava encerrando a "Hack de carreira", decidi trazer um texto extra, falando sobre uma experiência particularmente desagradável e com mais um agradecimento para quem me acompanha.
Abraço,
Ingrid Machado
Nesta edição
🔄 Falando sobre agilidade: Qual é o melhor modelo?
🧭 Hack de carreira: Edição extraordinária
📝 Recomendações da edição
⌨️ Posts futuros do blog
🔎 Anúncio de vaga
Falando sobre agilidade: Qual é o melhor modelo?
Uma seção para falar de agilidade, mas trazendo a minha visão com anos de atuação como Scrum Master. Como fazer a teoria ser aplicada na prática? Como adaptar as diversas técnicas para os diferentes contextos onde a agilidade pode ajudar? Como usar a agilidade para fazer a diferença? São essas e outras perguntas que tentarei responder, além de também trazer questionamentos para quem me acompanha.
ㅤ
Sempre que vou iniciar o trabalho com algum time, gosto de saber quais são as expectativas. Principalmente quando vou fazer a adoção do Scrum com pessoas que nunca viveram o framework na prática. Cada time é diferente, então cada expectativa é diferente também. Sendo assim, me permito fazer alguns ajustes, mesmo que o Scrum Guide tenha se tornado menos prescritivo há pouco tempo.
No time em que estou agora, as expectativas envolviam organização das atividades, redução de reuniões desnecessárias e uma visibilidade clara do que entregamos versus o que a companhia espera que seja entregue. Sabendo essas informações, organizei um material para mostrar a proposta de trabalho inicial e tomei algumas decisões que eu mesma achei polêmicas num primeiro momento e, depois de ler e refletir bastante sobre, entendi que eram apenas escolhas que atenderiam às expectativas iniciais. Caso dê errado, a Retrospectiva está aí para nos fazer inspecionar e adaptar o processo para o melhor formato.
Em resumo, a proposta abordava os seguintes pontos:
Facilitação de todas as cerimônias do Scrum
Product Backlog formado por User Stories (USs) e tarefas
Sprint Backlog formado pelas USs e tarefas, quebradas em subtarefas
Uso de horas para estimar as subtarefas
Velocidade medida na contagem de itens entregues
Apesar de nunca ter trabalhado com essa exata configuração, entendi que a organização do time e as expectativas gerais pediam um formato mais simples. Por mais que estivesse pronta para ensinar o time a usar o conceito de pontos e a jogar o Planning Poker, pensei no tempo considerável que esse tipo de dinâmica ocupa no início e removi essa complexidade da Planning.
Parecia o plano perfeito. Porém, algumas discussões a respeito de mensuração de horas de trabalho e das diferenças do ágil para o cascata me fizeram pensar sobre esse formato. A dúvida principal era: estaria eu atuando como Scrum Master de um time e subvertendo o Scrum de alguma forma? A resposta para essa pergunta não é fácil e eu comecei a tentar responder a partir da fonte principal: o próprio Scrum Guide.
Orientações do Scrum Guide
Como comentei, o Scrum Guide em sua última versão apresentou um framework menos prescritivo, o que abre muito espaço para práticas que atendem às definições do guia. De qualquer forma, a definição de Product Backlog diz o seguinte:
O Product Backlog é uma lista ordenada do que é necessário para evoluir o produto. [...] Itens do Product Backlog que podem ser concluídos pelo Time Scrum dentro de uma Sprint são considerados prontos para seleção na Planning. Eles se tornam cada vez mais transparentes a cada refinamento, que é o ato de quebrar os itens em itens menores e mais precisos. Essa é uma atividade recorrente, onde são adicionados detalhes como a descrição, ordenação e tamanho. Os atributos podem variar conforme o escopo do trabalho.
Dessa definição, podemos tirar 3 conclusões:
O Product Backlog não necessariamente precisa ser formado por USs
Os itens que formam o Product Backlog podem ser quebrados em itens menores
Os atributos dos itens dependem do escopo do trabalho
Apesar dessa definição, o pensamento comum é que precisamos de um Product Backlog formado por USs, pontuadas usando Story Points para o time iniciar o trabalho. Mas essa é uma padronização que é repetida à exaustão, muitas vezes sem considerar se realmente precisamos ter esse formato para atender às necessidades do time. Então, se nem o Scrum Guide afirma qual tipo de item precisamos gerar e deixa a definição dos atributos em aberto, de acordo com o escopo do trabalho, entendo que um Product Backlog com User Stories e tarefas atende à definição do Scrum.
Uso de User Stories como itens do Product Backlog
User Stories surgiram com o eXtreme Programming (XP) e foram adotadas como práticas em outros frameworks por aproximar o cliente do desenvolvimento, permitir a coleta de feedback antecipada e entregar valor frequentemente.
Particularmente, esse é um padrão que eu considero como muito certeiro. Entendendo o que o cliente precisa, é muito mais fácil entregar a coisa certa. Mas nem sempre as demandas se traduzem em USs. Quanto mais técnico o que precisa ser entregue, mais difícil de formatar como uma US que tem real valor. Nesses casos, prefiro ter um Product Backlog com uma tarefa bem descrita, do que com uma US que apenas segue o formato esperado, sem trazer nenhum valor para quem está desenvolvendo.
Métricas de desempenho do time ágil
No momento, preciso pensar em duas métricas para avaliar o desempenho do time: Velocity e Lead Time.
Velocity: esforço realizado pelo time a cada iteração
Ao analisar um gráfico de Velocity, geralmente encontramos uma comparação entre a quantidade de Story Points estimados versus a quantidade de Story Points entregues ao final da Sprint. Porém, também é possível usar o mesmo gráfico comparando a quantidade de itens previstos para a Sprint versus a quantidade de itens entregues.
Pensando na segunda definição, não é necessário utilizar o conceito de Story Points no momento de estimar as USs. Mas é necessário realizar um trabalho de padronização para que cada uma delas reflita uma unidade de valor parecida. Dentre as referências que encontrei, uma das métricas que pode ser utilizada é a de um teste de aceite por US. Mas essa também é uma recomendação que pode ser avaliada pelo PO e pelo SM, que vão entender qual é a melhor maneira de dividir o Product Backlog e encontrar essa métrica.
Lead time: tempo entre a entrada da demanda no Backlog do time e a entrega de valor para o cliente
E, quando falamos de Lead Time, estamos pensando em itens do Product Backlog e o tempo que estes itens levaram para percorrer o fluxo de desenvolvimento. Sendo assim, temos outra métrica que pode ser mensurada sem a utilização dos Story Points.
Uso de horas em projetos ágeis
Como falei anteriormente, é necessário ter uma métrica para avaliar o tamanho similar das USs. Sem essa escala, dizer que a velocidade do time é 10 em contagem de itens pode não significar nada, se cada um desses 10 itens for de grandezas muito diferentes. Só que essa velocidade também não pode ser uma métrica que penaliza o time para ser encontrada. Por isso, insiro a sugestão de estimar com horas as subtarefas de cada item do Product Backlog.
Quando falamos de estimativas, seja em Story Points ou em horas, temos que lembrar que não teremos um valor certeiro. Pois, como o próprio nome diz, estamos apenas estimando. Sendo assim, combinei com o time a seguinte escala de horas para as subtarefas:
1 dia de trabalho = 6h
1 turno de trabalho = 3h
1/2 turno de trabalho = 2h
Subtarefas pequenas = 1h
O dia de trabalho tem oficialmente 8h, mas sempre considero o tempo que as cerimônias, reuniões extras e descanso tomam do nosso dia. Além disso, também precisamos ter um tempo para imprevistos como bugs ou até mesmo uma estimativa muito fora do realizado.
A minha intenção com as horas, nessa proposta, é entender o quanto o time consegue absorver de itens do Product Backlog. Depois de ter essa métrica, a ideia é remover a estimativas com as horas, enquanto nenhuma alteração no time ocorrer. Assim, eu pretendo conseguir uma previsibilidade de capacidade do time, Plannings mais dinâmicas e, futuramente, mais enxutas.
Nada é fixo
A proposta de trabalho ao iniciar com o time é somente um guia de como podemos organizar o nosso dia a dia. Independente do formato, sempre vão existir sugestões de melhoria de processo, que devem ser levadas em consideração. Por mais que o Scrum Guide possua algumas regras, sempre defendo a independência do time para mudar o que não funciona.
Nunca deixe de se questionar
Muitas vezes, fazer algo repetidamente nos leva a executar sem pensar bem no que estamos fazendo. Se não fossem as discussões que participei e os exemplos que vi ultimamente, provavelmente teria feito a proposta de trabalho para o time sem adaptar o suficiente. E foi essa adaptação que me fez questionar as minhas próprias práticas, o que me levou a ler muitos artigos e a reler o Scrum Guide com outros olhos. Trago na seção "Recomendações" dessa edição alguns dos artigos que nortearam essa minha reflexão e espero que te ajudem a entender que realmente não existe certo nem errado.
Hack de carreira: Edição extraordinária
Nesta seção, falei sobre como mudei alguns comportamentos que cultivei desde o meu primeiro emprego e que até pouco tempo atrás me prejudicavam e eu não tinha consciência. No decorrer das edições, expliquei um pouco melhor como tudo aconteceu e espero que sirva de exemplo e motivação. O primeiro capítulo dessa história foi contado na primeira edição.
ㅤ
Sei que na edição passada nomeei essa seção como "Parte final". Só que algumas coisas aconteceram após a publicação e decidi compartilhar em uma edição extraordinária.
Primeiro, gostaria de compartilhar o depoimento que dei em um grupo de mulheres a respeito de uma situação bem chata que aconteceu comigo:
Eu passei por uma situação muito chata numa entrevista ontem. O candidato claramente falava comigo de um jeito diferente do que ele estava falando com os meus colegas. Por isso, depois da primeira pergunta eu não fiz nenhuma outra. Quando chegou a hora de ele perguntar, eu respondi a pergunta e ele literalmente perguntou a mesma coisa de novo. Senti como se eu estivesse falando com uma parede. O lado positivo é que depois da entrevista os outros SLs comentaram que perceberam esse comportamento e, mesmo o cara sendo muito bom tecnicamente, ele não iria adiante no processo. O que me deixa muito feliz, porque já passei por várias situações onde relevam comportamentos desse tipo porque precisam da expertise...
Por ser uma situação que sei que não acontece só comigo e, infelizmente, sei que não vai deixar de acontecer tão cedo, achei importante compartilhar. E nem quero focar no fato de que passei por mais uma situação do tipo, mas sim na minha surpresa com a reação dos meus colegas. Estou tão acostumada a ser a única que avalia alguns comportamentos que até me emocionei com a quebra de expectativa.
Essa história serve mais para lembrar que, por mais que eu me especialize e ganhe experiência, eu tenho que seguir criando resiliência para situações que fogem do escopo profissional ideal. Mas também serviu para lembrar que não estou sozinha. No fim, vejo o saldo como positivo.
ㅤ
Para marcar o fim da seção e comemorar a décima edição da Trilha de Valor, decidi fazer o sorteio de um livro. E acredito que não tem um livro melhor do que o "Como as mulheres chegam ao topo" para marcar esse momento. Se você quiser participar do sorteio, basta preencher esse formulário. O resultado será divulgado na próxima edição.
Recomendações da edição
Seção com as recomendações relacionadas com o assunto da newsletter ou com novidades interessantes e que acho que vale a pena conhecer.
ㅤ
Why use hours vs story points when estimating software? - Codebots
Artigo muito completo, que fala sobre as vantagens e desvantagens do uso de horas e de Story Points nas estimativas ágeis. Reúne textos e comparações de muitas referências diferentes e traz pontos de vista interessantes sobre cada uma das abordagens. Em inglês.
ㅤ
Story Points Revisited - Ron Jeffries
O inventor dos Story Points esclarece nesse artigo a intenção inicial da pontuação e quais foram os desvios na definição original que o fizeram se arrepender de ter colaborado com a invenção. Além de falar sobre a origem, acredito que eleva o nível de discussão sobre mensuração e planejamento ágil. Em inglês.
ㅤ
Neste post, falei sobre a última versão do Scrum Guide. Acrescentei vários comentários sobre os pontos que tornam a edição de 2020 menos prescritiva em relação às anteriores, além de adicionar todas as novidades do framework.
ㅤ
Conferência organizada pela Product School, que vai contar com palestras de vários profissionais de produto que inclui empresas como a Uber, Disney e Tumblr. Vai ser possível assistir as palestras online e acessar as gravações posteriormente com a inscrição gratuita. O evento ocorre no dia 23 de setembro.
ㅤ
Vozes Negras - TAG Trilhas Literárias
A TAG criou uma coleção com 7 obras de autores negros. Além dos livros, também foi criada uma experiência para imersão literária, com debates e conteúdos exclusivos. No momento, está em pré-venda por mais duas semanas.
ㅤ
Procurando conteúdo sobre aprendizado, encontrei esse artigo que condensa vários conceitos num único material. É bem longo, mas com muitas dicas legais e que, na minha opinião, fazem muito sentido para quem está buscando técnicas de aprendizagem.
Posts futuros do blog
Sempre estou planejando novos conteúdos e gosto de compartilhar este processo com os inscritos na newsletter. Esta seção inclui as ideias que estão na fila e o que ando estudando e pode virar post.
ㅤ
Ainda estou querendo postar o resumo sobre o modelo 4I's do Change Management 3.0 que tinha comentado na edição anterior. Mas, sinceramente, não ando me cobrando tanto assim para manter uma frequência fixa no blog, já que tenho cumprido muito bem esse compromisso com a newsletter.
Além disso, tudo o que eu penso em escrever já é grande o suficiente para virar uma série de posts ou uma nova seção na newsletter. Sigo pensando a respeito.
Anúncio de vaga
Squad Leader - Financeiro - iClinic
A empresa em que estou trabalhando no momento está precisando de mais um Squad Leader para fechar o time. Caso você:
Goste de trabalhar com pessoas
Acredita nos valores e princípios do Manifesto Ágil
Quer vivenciar uma cultura de produto
E conhece o Management 3.0
Então provavelmente você se encaixa no perfil que estamos procurando. Mais informações podem ser encontradas no link da vaga. Caso tenha interesse, fique à vontade para responder esse email ou me chamar no LinkedIn.
A edição de hoje teve muito conteúdo e foi uma daquelas que me deixou bem orgulhosa de fazer. Quando mandei a primeira edição da Trilha de Valor, eu ficava bem envergonhada de compartilhar algumas experiências pessoais e hoje já tenho que me segurar na hora de escrever algumas coisas.
O motivo para essa abertura é bem simples: as pessoas que me acompanham aqui são muito gentis e sempre recebo ótimos feedbacks. Muito obrigada por isso. É muito legal sentir que estou formando uma comunidade tímida, mas muito respeitosa.
Sinto que algumas mudanças estão por vir, mas vamos ver o que acontece nos próximos quinze dias.
ㅤ
Por hoje é isso, boa quinzena!
ㅤ
Imagem do preview de Reed Mok, via Unsplash