Ei Scrum Master, 10 dicas para deixar sua Sprint tranquila e favorável…

Olá Pessoas,

Antes de mais nada eu gostaria de agradecer o WordPress, por ceder este espaço para que a gente possa, em alto nível, discutir a gestão de projetos (e demais assuntos) no Brasil… (protocolos e blá blá blás cumpridos, vamos ao que interessa)

Ao confessionário… quem nunca começou uma Sprint com aquela sensação de que havia algo de “estranho” — o original é podre (Hamlet, Shakespeare) mas achei a palavra meio inadequada para o contexto — no reino da Dinamarca, que atire a primeira pedra…

Foi pensando em você Scrum Master, que às vezes se sente meio perdido olhando para suas 75 métricas, as quais, algumas delas, te dizem mil coisas e outras não te dizem coisa alguma… que em horas do dia se sente abandonado pelos institutos que te certificaram e te disseram que o Scrum Guide é o caminho, a verdade e a vida e que por fim, não permite, nem sob tortura, que o seu time sucumba ao eXtreme GoHorse (XGH)… que decidi investir uma fração do meu dia para apresentar-lhe as dicas abaixo. Creio, contudo, que você já conheça muitas delas, de todo modo é sempre bom revisitá-las. :mrgreen:

Sem muitas delongas… desembuchemos:

1) Conheça muito bem os pontos fortes e os GAPs do Time de Desenvolvimento

Como a marketagem é pesada (⇐ qualquer dia destes escreverei sobre isto)… muitos times ágeis são tentados a utilizar a sopa de letrinha (TODA), criada pela indústria de software, num único projeto. TDD, BDD, FDD, DSDM, PSP (PlayStation Portátil? — Não PSP não…) e por aí vai. Sou extremamente adepto da utilização de práticas modernas de engenharia de software. Aliás julgo a utilização de tais práticas de fundamental importância para a sobrevivência de qualquer produto de software. O problema, entretanto, é que nem todas as pessoas, têm habilidades relevantes ou se sentem confortáveis em aplicá-las. Por esta razão a recomendação que faço é que se aplique técnicas para mapear o conhecimento e a evolução do conhecimento dos membros do Time. Isso servirá para diminuir riscos e permitirá que você encontre formas de auxiliar o Time de Desenvolvimento a melhorar suas lacunas (GAPs).

2) Certifique-se de que o Time de Desenvolvimento esteja confortável com o Sprint Goal

Ao final de cada planning convide o Time de Desenvolvimento para avaliar a meta da Sprint (Sprint Goal) — aliás peça sempre ao PO para definir uma meta clara e objetiva para a Sprint — que pode ser feita através de uma votação rápida, para saber se todos concordam que a meta é alcançável e para verificar se todos estão comprometidos com ela.

Nota 1: Sprint Goal ajuda a dar maior flexibilidade para sua Sprint 😉

Nota 2: Em empresas mais tradicionais (não gosto muito deste termo, mas não encontrei um melhor para substitui-lo) transparecer a meta da sprint para os stakeholders, pode ser uma forma eficiente de reportar o status do projeto.

3) Utilize o refinamento para entendimento da histórias e para levantar possíveis IMPEDIMENTOS

Refinamento (ou grooming, como alguns preferem) ajuda a reduzir dúvidas técnicas e dúvidas de negócio, permitindo ao Time de Desenvolvimento planejar a próxima Sprint de uma forma mais produtiva. Você pode, além disso, no refinamento, mapear possíveis impedimentos e trabalhar para evitar que eles ocorram. Por exemplo. Sua empresa possui processos rígidos (tá bom, burocráticos) como abertura de requisições com SLAs de 2 ou 3 dias… supondo que sua sprint seja de 10 dias úteis, este prazo de SLA certamente causará impactos negativos. Se você tiver visão, já no refinamento, do que será demandado para a próxima sprint, talvez você consiga se antecipar reduzindo o prazo de atendimento das requisições.

4) Saiba o que fazer com as métricas do contrário, deixe-as de lado!

Coletar métricas só porque você ouviu o galo cantar que métricas são importantes, mas não saber o que fazer com elas, é um tremendo desperdício. Uma das formas que utilizo para saber o que devo medir e como medir, é respondendo as perguntas a seguir:

  1. O que quero saber ao levantar este tipo de informação (métricas)?
  2. A partir do momento em que eu tiver essas informações em mãos, quais ações propor caso haja necessidade?

Se por ventura você NÃO conseguir responder as perguntas acima de forma coerente, não perca  mais seu precioso tempo medindo mais nada. Sente-se junto ao Time de Desenvolvimento e ajude-os no que for preciso.

5) Esteja convencido da importância das cerimônias, a partir daí, trabalhe para engajar o time acerca desta importância.

Amigão(ona), deixa eu te contar um segredo. Se você não tiver pelo menos 3 boas razões para promover as cerimônias dentro da sua sprint, tanto as que constam do guide, quanto qualquer outra que por ventura seja conveniente para o seu contexto, você tem um sério problema. O que quero dizer com isso é que, falar por exemplo que retrospectivas são boas porque permitem analisar o que foi bom e o que foi ruim, é relativamente fácil. Um pouco mais complicado é você, olhando para a sua realidade, mostrar ao seu time que é importante ser feita uma retrospectiva, por causa deste, daquele ou daquele outro motivo… convencendo-os inclusive que, além de necessário, é crucial que todos se comprometam com o objetivo do evento. Esqueça um pouco o guide e responda a si próprio… porque você faz daily meeting? Já refletiu sobre isso?! :mrgreen:

6) Não confunda, jamais, auto-organização com  Laissez-faire

 Querido(a) — lembrei da Presidenta afastada Dilma Rousseff — auto-organização é auto-organização e Laissez-faire é Laissez-faire. WTF??? Calma. Explico. Não antes das definições. Times auto-organizados são times auto suficientes, que conseguem resolver seus conflitos, que dão vazão as suas demandas com habilidade, que não necessitam de ninguém mais, além deles mesmos, para planejar suas atividades e tomar decisões a fim de atingir seus objetivos e os objetivos apresentados pela companhia. Laissez-faire é uma expressão muito utilizada pelos economistas liberais para referirem-se ao mercado auto regulado, ou seja, sem a intervenção do Estado. Nestes termos, se o seu time não é auto-organizado (e times assim não são fáceis de achar) cuidado para não praticar, comodamente, o que costumo chamar de Laissez-faire. Exemplo… você decidi atuar de forma mais neutra, sem maiores interferências, por achar que o time tem de se auto-organizar e aquela coisa toda… e com essa “inércia”, você acaba perdendo a oportunidade de contribuir para que o time atinja seus objetivos de uma forma mais eficaz. Pense bastante nisso e fique tranquilo porque isso não tem nada a ver com comando e controle. Isto tem a ver com colaboração. 🙂

7) Tente promover as cerimônias de término e início de sprint no mesmo dia, e seja feliz!

Acredito que você, a esta altura, já deva ter percebido que reviews geram importantes entradas para retrospectivas, que por sua vez geram importantes entradas para plannings… concorda?  Se concorda, imagine a review da sua sprint acontecer numa sexta-feira ensolarada, pós-almoço… e coladinho na review, a retrospectiva?! O time certamente estará com a cabeça na bavaria gelada do happy hour que se aproxima… (bavaria é osso hein) sem contar que depois de um final de semana, o time pode não se lembrar do que foi discutido na sexta-feira e sua planning, talvez, perca pontos importantes a serem considerados e discutidos. Dito isto, embora reservar um dia todo para as cerimônias, seja um pouco cansativo, ainda vejo mais vantagens do que desvantagens. E todas as vezes que perguntei ao time sobre o que achavam de “matarmos” tudo no mesmo dia, a unanimidade foi absoluta.

8) Timeboxes são importantes. Objetivos são mais importantes ainda! 

Pelo amor de Deus… ninguém aqui tá falando pra você fazer daily de 1 hora. Mas não acho razoável você privilegiar o timebox de um evento e deixar de lado o objetivo que aquele evento se propôs a atingir. Por exemplo. Segundo o guide, uma planning deve durar 4 horas para sprints de 2 semanas. Você como Scrum Master (certified rsss) não vai, uma vez que este timebox expirou… interromper o planejamento, tomar os postits e canetas da mão do time e “mandar” eles se posicionarem em suas mesas para começar a implementação, vai? kkk… pois é! Então se você perceber que o desrespeito aos timeboxes estão sendo recorrentes e estão gerando problemas, analise junto ao time o porque isto está ocorrendo e mude.

9) Desenvolvedores e Analista de Testes fazem parte do Time de Desenvolvimento

Isso parece óbvio, mas não é… já peguei times em que os desenvolvedores faziam uma planning e os analistas de testes faziam outra planning. Se o objetivo é ter um incremento potencialmente utilizável ao final de cada sprint, e a grande maioria da empresas possuem uma área de QA (Quality Assurance) ou QS (Quality Software), como é que você pode ter um incremento pronto sem ter passado pelos analistas de testes? Aliás você como um bom Scrum Master deve, dentro do seu time, buscar aproximar os desenvolvedores dos analistas de testes. Já vi em várias empresas, analistas de testes rivalizarem com desenvolvedores e vice-versa… isto é muito ruim. Estimule os analistas de testes a sentarem ao lado dos desenvolvedores, a mostrarem a eles a estratégia de teste e estimule ainda os analistas de testes a automatizarem a maioria, se não todos, os casos de testes previstos. Isto trará bons frutos ao seu time e a sua sprint.

10) Comemore as metas atingidas (inspirado no PMBOK® Guide) 

Você já parou para pensar que a cada final de sprint, uma fase do seu projeto foi concluída? O PMBOK® diz que a cada ciclo de um projeto concluído deve ser feita uma comemoração, para evidenciar aos stakeholders que aquela fase foi concluída (existem vários benefícios por isso acontecer, mas não entrarei aqui em maiores detalhes). Porque então você não pode combinar com o seu time que a cada meta atingida, vocês irão almoçar num restaurante mais refinado!? Ou, sovinices a parte, porque você como Scrum Master, não poderia trazer uma caixa de chocolate para comemorar uma meta atingida e estimular o time a fazer o mesmo, quando uma nova meta for alcançada?! Ações como esta, no mínimo, agregará mais o time… acredite!

Nota: Meta da release cumprida, a comemoração deve ser caprichada! (com direito a fumaça, globo e strip-tease rsrs)

That’s all folks…

Espero que estas dicas sirvam para sua reflexão e lhe ajudem no seu dia a dia… espero também que elas contribuam para o aprimoramento do papel do Scrum Master nos Times Scrum. Sinta-se a vontade para discordar, ou para enriquecer este post com outras dicas baseadas em sua experiência.

Em tempo: coloquei no post a imagem destacada do Dr. Sergio Moro, porque assim como o Scrum Master, ele também é dono do processo. :mrgreen:

Saudações. Ψ

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: