Agilidade – Indo além dos Post-its

Post-it e canetão. Se aparece alguém andando no corredor com eles nas mãos já vem o pensamento: “Olha lá o Scrum Master com seu kitzinho”.

Mas você sabia que ser Scrum Master vai muito além disso?

“Ah, mas o “Manifesto Ágil” tem um item que diz assim:

Indivíduos e interações mais que processos e ferramentas”

Mas, afinal, hoje em dia, o que é interação? Em plena pandemia com as pessoas trancadas em suas casas, voltando aos poucos para os escritórios, já é óbvio que as ferramentas e práticas foram vitais para continuidade dos projetos e, claro, para manter as interações entre os indivíduos o mais saudável possível.

Então minha ideia neste artigo é focar em algumas práticas da Agilidade que o Scrum Master precisa aplicar se quiser mandar bem nas suas Sprints.

Antes de tudo: Sprint entrega CONHECIMENTO, não partes do projeto.

Aqui uma rápida explicação: O que a Sprint entrega? O que o Ágil entrega? Projetos? Softwares? NÃO.

Ao meu ver, o Ágil entrega CONHECIMENTO. Se você já sabe exatamente o que precisa fazer, como fazer e quando precisa entregar, você não precisa do Ágil. O bom e velho cascatão resolve. Joga la um cronograma de 500 linhas com o passo a passo maroto e segue a vida só acompanhando e fazendo report pra galera. Aliás, se você já sabe tanto como fazer, como diriam os mineiros, o “trem”, se bobear nem precisam de um GP, só fazer e entregar.

Mas se você não sabe como construir a necessidade do seu PO (Product Owner), nunca fez, usará tecnologias novas, precisa CRIAR algo que não exista com pessoas e áreas que raramente atuou em conjunto, então, sim, a Sprint entregará o CONHECIMENTO de como fazer e, por consequência, um incremento daquilo que seu PO precisa.

Quando você estuda para uma prova, se alguém perguntar “Quando você conseguirá saber 100% da matéria para a prova dia X” você saberá dizer? Não. Você sabe quando é a prova mas o quanto você conseguirá aprender até lá, você não sabe. Pode mandar bem e tirar 10 (100%) ou tirar um belo de um 6 (60%) e ter que melhorar para a próxima prova (versão?)

Em Agilidade não é diferente: Negócios SEMPRE definirá uma data (seja time to market, portfólio ou puro achismo) mas é um fato: é extremamente raro um projeto ágil, que entrega algo novo, inovador e não repetido, ser entregue 100% naquela data. Mas, claro, alguma coisa será e o Ágil favorece essa visibilidade.

É como no exemplo: Você está se preparando pra uma prova e, ao longo do tempo, fará simulados e entregará exercícios para ver onde melhorar e direcionar esforços. A mesma coisa com as Sprints. A cada Sprint uma parte do todo será entregue e vista pelo seu avaliador (nosso amigo PO).

Mas agora, vamos pra algumas dicas pra ir além dos post-its e canetão?

Estimar seu Backlog

Aqui meu voto é pra simplificar. Sem olhar práticas de outros métodos (hibridismo), focando apenas na agilidade, a melhor forma ao meu ver pra estimar é

  • Ter estórias SMART e bem quebradas
  • Marcar quais são P, M, G (E avaliar se a G não pode ser quebrada em duas)
  • Deixar nosso amigo PO (Product Owner) dizer ANTES quais ele quer na frente – e pedir para que ele ser parceiro e tentar não mudar a prioridade a cada semana.
  • Os Devs (e somente os Devs) pontuarem as histórias usando Fibonacci com conceito de complexidade, não tempo. Times que trabalham há muito tempo até conseguem pontuar em horas determinadas atividades mas não é a melhor forma.
  • Fazer a Planning e, pela percepção do time, decidir quanto cabe na Sprint.

Projeto novo? Ao invés de uma Sprint 0, considere a primeira sprint como “Curva de Aprendizado”. Use talvez o conceito de Spike pra validar a solução proposta.

Não importa que a equipe tenha anos de experiencia juntos ou os Devs tenham 430 certificações. A primeira Sprint serve pra validar se as histórias estão realmente bem escritas, se a solução proposta pela equipe funcionará e qual a capacidade do time para aquela demanda. Falando em Capacidade, espere ao menos 3 ou 4 Sprints pra saber, de forma aproximada, a capacidade do time. Isso ai, 3 ou 4 meses pra entender o quanto o time consegue entregar pra responder aquela pergunta que todo PO faz: “quantas horas é um ponto?”

Transparência

Sim gente, transparência é uma prática. Time está com problemas? Chama o SM pra ajudar, ele irá buscar ajuda necessária para destravar as coisas. “Resolver impedimentos” é um termo bonito mas aqui quero destacar algo mais importante, que é a transparência em si.

O time é bom, a turma é esforçada mas a atitude de “bate no peito e deixa que resolvo” não funciona – e isso acontece demais. Muitos times tem “vergonha” de pedir ajuda e ficam la, dias e dias tentando resolver sozinhos pra, ao fim da Sprint, terem aquela sensação de heróis.

Deixa disso. Chame o time, aponte os problemas na daily ou em um fórum específico e mostre o que está acontecendo. Alguém de fora poderá ajudar a destravar o tema mais rápido do que o time ficar quebrando a cabeça sozinho. E, se quebrar a cabeça for a unica solução, ao menos todos saberão que o time está com dificuldades e que pode surgir impacto na Sprint – ou no projeto como um todo

Leve a sério as Retrospectivas

As retrospectivas do time são como as Lições Aprendidas do Cascata. Não adianta fazer retrospectiva sem olhar as anteriores e, de fato, ter atuado nos itens pontuados pela equipe. Aqui fica ao seu critério fazer a Retrospectiva só com o time, com PO, com gerentes ou quebrar em mais de um momento (Só com Time e com Gestão). Fazer no bar, na empresa, online, também fica ao seu critério.

O ponto importante aqui é: É na Retrospectiva que você tem que criar um ambiente aberto, para que todos falem com sinceridade, bem ou mal, incluindo sobre sua atuação como Scrum Master. Você como SM atuará em cima dos itens levantados e levará para a gestão SOMENTE os itens que você não consegue resolver E com autorização da equipe ou da pessoa que relatou a questão. Afinal, se você ficar de “leva e trás” com os gerentes e isso prejudicar o time ou a pessoa de alguma forma, esqueça retrospectivas sinceras.

Divida/Débito Técnicos devem ser endereçados corretamente.

Desenvolvedor, Arquiteto, pessoas envolvidas a fundo na parte técnica ODEIAM lidar com o cliente. Isso é um FATO, não adianta você, como SM, querer se enganar achando que a equipe se envolverá com o cliente, PO, parte interessada, enfim, sem você atuar ou intermediar de alguma forma. “Ah, colaboração com o cliente bla bla bla”. Sim, precisa ter colaboração mas o time técnico prefere ficar isolado desenvolvendo, criando, inovando. Se for um quarto escuro então, melhor ainda, a maioria adora.

Só que isso irá gerar um caminhão de débito técnico e conceitual. Com o isolamento social, avanço de times remotos e crescimento dos projetos, a maioria dos desenvolvedores prefere focar nas Histórias que envolvam minimamente o cliente. Mas muitos processos dependem de proximidade com eles, simular em conjunto, perguntar se é isso mesmo durante o desenvolvimento e não somente no fim da Sprint.

Saber endereçar isso, entender quando é hora de pegar na mão do Dev e do PO e colocarem juntos, poderá fazer a diferença na qualidade da entrega.

Conclusão

Lide com o fato que existe muito mais material sobre Agilidade e Gestão de Projetos mostrando exemplos de fracassos. Ou seja: Se você pesquisar motivos que os projetos fracassos, encontrará MUITO conteúdo para aprender e melhorar sua forma de gestão para evitar que fracassos semelhantes aconteçam com você.

É muito mais fácil aprender olhando os erros dos outros do que focar apenas no “By The Book” e tentar fazer o que dizem ser certo ao invés de ver onde outros erraram, entender porque erraram e usar isso ao seu favor.

Espero que as dicas neste artigo tenham ajudado você de alguma forma e que perceba que o trabalho de um Scrum Master pode ser muito mais profundo que apenas tramitação de post-it no quadro branco.

Os comentários estão encerrados.

Crie um site ou blog no WordPress.com

Acima ↑

Crie um novo site no WordPress.com
Comece agora
%d blogueiros gostam disto: