Eu sempre falo isso nas minhas palestras de Scrum, mas eu não acreditava que o Scrum poderia me ajudar. Eu não entendia de que maneira um monte de “papeizinhos coloridos” colados no quadro poderiam me ajudar no meu dia a dia. Eu lia, lia e lia mas mesmo assim não estava convencido de que isso poderia melhorar meu trabalho… Foi ai que em um PHP Conference eu fiz um Workshop de Secrum e passei a ver como essa “bagaça” podia ser útil! Acho que só passei a reparar nos benefícios depois que ganhei uma equipe de 5 programadores e me identifiquei com inúmeros problemas apresentados e solucionados no Scrum. Tentarei agora passar um pouco da minha experiência com a implantação e aplicação do Scrum.

Aplicando e apanhando (Scrum em equipe)

Voltei do PHP Conference com muitas ideias e super empolgado com as possibilidades, preparei uma apresentação, convenci meu chefe de que o Scrum poderia ajudar no nosso trabalho, treinei minha equipe, arrumei um quadro, montei o Kanban e… FIASCO! Deu quase tudo errado.

1) Transparencia:  Não tive problemas com relação a isso e, na minha opinião, é um dos maiores problemas que um Scrum Master pode ter. Se sua equipe não passa exatamente o que está acontecendo, tenha certeza de que a chance do seu Sprint dar certo é minima!

2) Tudo junto e misturado: Vamos lá galera, Sprint Backlog pronto, equipe preparada, café pronto, equipe trabalhando a todo vapor e… Diálogo:

Chefe: Para tudo que você está fazendo e adianta esse trabalho aqui…
Você: Estamos no meio de um Sprint! Falta apenas alguns dias para terminar, vou colocar esse trabalho no próximo sprint.
Chefe: Não não… Eu preciso disso para ontem etc etc etc.

Resumo… Ou teremos um Sprint cancelado (isso é tão sério como roubar comida de um gordinho – sou gordo e sei como isso dói) ou teremos um atraso no Spint (isso também é como roubar comida de um gordinho). Cancelamento de Sprint desanima a equipe, atraso de Sprint desanima seu cliente e faz com que você perca a credibilidade e, tenha certeza, reconquistar essa credibilidade é uma terefa complicada e na maioria das vezes dói no bolso (no seu é claro)!

3) Reuniões periódicas? Experiência própria! Falar para seu cliente que você trabalha com desenvolvimento ágil é legal, agora tentar explicar o papel dele dentro do Scrum é um tiro na cabeça! Ele não vai acreditar que isso funciona, não vai querer as reuniões periódicas e vai tudo dar errado. O melhor a fazer é explicar de forma reduzida o que é o desenvolvimento ágil e fazer com que ele participe sem perceber que está participando. Marque as reuniões periódicas sem dar esse título para seu cliente, tente fazer ele participar dessas reuniões fazendo com que ele fale quando deve falar, opine quando deve opinar. Muitas vezes ele vai falar de mais e vai querer que você adicione inúmeras novas funcionalidades, não se desespere, não desanime, anote tudo!

4) Em quanto tempo o trabalho esterá pronto? Ai é que entra o seu jogo de cintura. Acabei de falar “…não se desespera, não desanime, anote tudo”. Anote tudo e faça o seu cliente entender que quanto mais funcionalidades ele pedir mais tempo vai demorar para você entregar o trabalho e mais dinheiro ele irá gastar. Vale lembrar que no Scrum, mudanças são bem vindas.

O resumo disso tudo é que você precisa ter jogo de cintura, não pode ser tímido e nunca deixe o seu cliente tomar conta do projeto! Lembre-se ele está apenas envolvido com o projeto e você está comprometido.