Concrete Logo
Hamburger button

10 sinais de que seu time de Scrum está rodando ciclos curtos em Waterfall

  • Blog
  • 21 de Agosto de 2015
Share

Minhas experiências recentes têm mostrado que o quotidiano de desenvolvimento ágil de produtos é um duplo desafio: colocar no mercado um produto que as pessoas amem (como se só isso já não fosse suficiente) enquanto lidamos com a armadilha de trabalhar com pessoas, processos e circunstâncias que, muitas vezes, não se encaixam nos frameworks nos quais baseamos nosso trabalho.

image00

Se você trabalha com desenvolvimento de produtos como eu, certamente ao terminar de ler o post desdenhará da lista pensando: “ok, uma compilação do óbvio…”. É assim que me sinto quando leio alguns autores que admiro justamente por considerar que o que fazem de melhor é abrir meus olhos para o que eu ando fazendo (e falhando) com a melhor das intenções.

Portanto, não considere esse post como as regras de ouro de qualquer coisa, ou os mandamentos que vão garantir que seu produto sairá como esperado, mas como um exercício de empatia, ok? Vamos aos 10 sinais de que o que você está rodando não é Scrum:

  1. Os objetivos estão obscuros

Lembre-se do que o Scrum Guide fala sobre transparência: “aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados”. Lembra? Quem faz e quem aprova deve estar na mesma página (pelo menos) sobre pontos fundamentais do produto. Seu time não sabe para que o produto serve? Os stakeholders desconhecem a definição de pronto com a qual o time está comprometido? Mau sinal.

  1. Hoje não vai ter daily

Todos os participantes devem fazer, respeitar e entender os objetivos das cerimônias, como o daily. O objetivo fundamental aqui é, sem dúvida, o de inspeção, e fazê-lo sem regularidade altera os resultados. Fazer de forma resignada, burocrática ou como um extenso relatório em formato de chamada oral também não vale.

  1. Existe resistência a mudanças

Não adianta medir e não reagir. Se na retrospectiva discute-se um problema mas, ao propor uma solução, o time ou cliente não está disposto a se adaptar, então isso também não é Scrum.

  1. Príncípios fundamentais estão sendo “negociados”

A definição “esforço temporário empreendido para obter um resultado exclusivo” é normalmente usada para projetos, certo? Em todo caso, poderíamos usá-la para explicar o que é uma sprint, com algumas ressalvas: aqui, o intervalo das iterações é regular, sendo o resultado exclusivo tudo aquilo o que o time prevê fazer nesse intervalo. Não é incomum trabalharmos com clientes que sugerem encurtar ou prolongar a sprint para cumprir uma entrega, ou em alguns casos mudam o objetivo durante seu andamento. Um equívoco tão comum em ambientes que estão em fase de adoção da metodologia quanto ceder à sugestão de “flexibilizar” e pôr todo o esforço a perder.

  1. Faltam objetivos atômicos

Histórias que superam um ou mais ciclos para ser entregues contradizem um dos principais artefatos do Scrum: o Incremento de Produto. Para determinados produtos, superar uma sprint para entregar um requisito pode acontecer, mas é exceção. Sempre que um requisito leva muito tempo para ser entregue, ele tende a ser modificado em vez de evoluído. Parece a mesma coisa, mas não é: ao entregar um requisito com potencial de ser incorporado ao produto e lançado, ainda que ele não o seja de fato, permite que seja experimentado e adaptado. Se as hipóteses de seu produto não podem ser validadas, então não há produto, apenas projeto.

  1. O time está fortemente segregado por competência

Se seu time tem divisões internas muito claras por skill (UX, Android, iOS) em vez de valorizar sua formação multidisciplinar, não é regra, mas o risco é grande. Não à toa, as histórias são de usuário e não de desenvolvedor e, para que ele, usuário, cumpra seu objetivo é necessário que as competências de UX, QA, dev e todos os perfis do time sejam somadas e não divididas.

  1. Existem fluxos e alçadas de aprovação alheias ao time

A maioria das companhias adota o modelo organizacional hierárquico. Esse modelo afeta diretamente o que será desenvolvido, direcionando estrategicamente o produto. O problema aqui é quando a participação de membros fora do time interfere no andamento da sprint. Alçadas de aprovação devem afetar a preparação do requisito, nunca a entrega. Se o trabalho de um  ou mais stakeholders é uma dependência forte e constante, talvez ele deva fazer parte do time e não apenas ter participações especiais. Resolva antes que seja tarde.

  1. Há sobreposição de papéis

Membros do time devem ter autonomia para definir o que vai ser feito (PO) e como vai ser feito (time de desenvolvimento). Evidente que ambos são consultivos e podem (e devem) sugerir abordagens, trabalhando colaborativamente. No caso dos desenvolvedores é mais raro, mas no caso do PO, é muito comum que apareçam um ou mais agentes externos que tentam atuar como um comitê, definindo o que, como e quando o time deve fazer. A separação entre os papéis do PO e do Scrum Master deve se manter bem clara e, se o cliente não está confortável com a ideia de um time autônomo, ele não rodará Scrum.

  1. O foco está no processo

Papéis, eventos e artefatos atendem a um propósito e não têm valor por si só. Se está com a sensação de que está fazendo tudo certo, seguindo a metodologia à risca, mas depois de algumas sprints ainda não tem produto, se questione.

  1. Os participantes não estão se divertindo

Pense no framework como um jogo: um gasto de energia voluntário, com regras (mais ou menos claras e previsíveis) e com um objetivo que ao ser atingido atua sobre nossos sistemas de recompensa. Se estamos jogando e não estamos nos divertindo, há algumas causas prováveis: ou não gostamos desse jogo (é raro, mas pode acontecer), ou estamos jogando errado. Se esse for o caso, vale a pena de tempos em tempos reler as regras no verso.

Se você se identificou com um ou mais itens dessa lista, não há razão para pânico, nem tudo está perdido. Afinal, o primeiro passo para ser um competente inconsciente é se tornar um incompetente consciente.

Ao se dar conta do que está acontecendo com seu time, poderá observar e pensar em soluções para cada uma das questões que estão impedindo que seu time trabalhe melhor. Procure pensar que o time, considerando pessoas e relacionamentos, também é um produto que evolui a cada sprint e, seja mínimo ou já maduro, deve continuar a evoluir. Agora ficou fácil!

Dúvidas ou comentários? Deixe seu recado abaixo.