Que me desculpem a falta de flexibilidade, mas algumas coisas na vida não aceitam tons de cinza. Ou é preto, ou é branco. Não há como um negócio ser “meio” Ágil, nem como um time usar “um pouquinho de Scrum”, como se fosse uma pimenta que se coloca no prato. Uma mulher não pode estar “meio grávida”, nem uma empresa ser “meio transparente”.
Transparência, seja interna, entre diferentes times e departamentos, ou externa, na forma como nos relacionamos com clientes, faz parte da Cultura de uma empresa. Cultura com C maiúsculo. Cultura empresarial é, entre outra coisas, o que os seus funcionários fazem quando não estão sendo monitorados, é como você se relaciona com clientes e colegas de trabalho, é você receber (e esperar) dos outros o que você oferece – gentiliza gera gentileza, respeito gera respeito, e por aí vai…
Transparência é fundamental na jornada Ágil de qualquer business e um dos princípios mais difíceis de serem aplicados no dia a dia. Fazer o seu trabalho visível aos outros, e ter visibilidade no trabalho dos outros são elementos cruciais quando se deseja a criação de times Ágeis eficientes e a quebra de barrerias na forma como nos comunicamos.
A velocidade de um time é mais importante do que quantos pontos ele fez no último Sprint. É a velocidade do time que permite ao PO planejar e priorizar estórias com confiança, e todos sabemos os requerimentos para obtenção de uma velocidade confiável: manter o time estável, sem retirar e adicionar pessoas, blindagem contra pedidos e favores paralelos, evitar alterações durante o Sprint, etc. Quando esses requerimentos não são atendidos, a velocidade flutua, as estimativas falham e o caldo entorna.
Muitas vezes as razões que causam a falha do Sprint não são claras – como no caso de um programador realizando um “pequeno favor” para o CEO e atrasando em outras tarefas do Sprint – e com isso o processo empírico não acontece. Se você não sabe porque falhou, como pode ser possível melhorar?
A Lixeira dos Pecados
A lixeira dos Pecados (Sin Bin) é uma área da sua Sprint board onde o time registra qualquer atividade que atrapalhe o andamento do Sprint. A idéia é simples: toda vez que alguém pedir algo a um membro do time que esteja fora do escopo do Sprint, deve-se registrar tal atividade em uma carta – o que foi feito, por quem e quanto tempo foi gasto na tarefa.
Nós não estamos buscando exatidão, o objetivo não é chegar a um número preciso de horas “perdidas”, mas sim, ter-se uma idéia das tarefas que acontecem regularmente (ou não) e atrapalham o desempenho do time. A origem é mais importante do que o sintoma.
Se um membro do time está trabalhando em algo que não está representado na Sprint board, ele está atrapalhando o time. Se você não está sendo transparente em comunicar o que está ocupando seu tempo, você está atrasando o progresso do time. Comunicar abertamente qualquer interrupção, sem medo ou pressão, é fundamental, e a Lixeira dos Pecados é uma ótima ferramenta.
Registrando disrupções em nosso Sprint
Desdobramentos
Uma vez instaurada a Lixeira, fica fácil visualizar quais problemas são recorrentes ou não durante o Sprint, e utilizando-se de métricas paralelas, justificar atenção do business para esses assuntos:
- “Os programadores passam muito tempo dando suporte ao pessoal do Financeiro” – vamos estabelecer um horário e um programador para atender o pessoal. Vamos fazer um sistema de triagem, etc.
- “O CEO pediu para eu alterar a fonte do site” – vamos educar o CEO na importância de tais pedidos serem filtrados e priorizados pelo PO.
- “Fiquei envolvido em uma reunião com o cliente durante toda a tarde” – isso acontece sempre? Não. Ótimo, vamos então registrar e prestar atenção para que isso não se torne rotina.
Simples? Hmmm… Not really. Nem tudo são flores na vida de um Scrum Master 🙂
“- Murilo, eu achei essa história de Lixeira dos Pecados bem interessante, mas há um problema: nosso cliente está vindo aqui amanhã, ele vai passar perto da nossa board e eu não acho uma boa ideia mostrar que não estamos trabalhando 100% no projeto. Eu concordo que precisamos ser transparentes, mas nesse caso…”
Ah! A maldita transparência. E quantas vezes eu ouvi isso… – Claro, vamos enganar o cliente! Vamos sumir com o problema como se trabalhássemos 100% no projeto e quando falharmos em entregar as tais funcionalidades, vamos culpar os programadores por serem lentos e preguiçosos. Vamos culpar o time, e não culpar ninguém. Vamos sujar o processo empírico como um puleiro, não aprender nada e evitar resolver a raiz da questão, a nossa falta de educação e organização empresarial. – Soa familiar? Utopia para uns, desafio para outros.
Quando isso aparece, fica evidente a necessidade de um longo e profundo processo de couching por parte do Scrum Master, e isso daria um outro artigo, mas essa é a parte difícil e gostosa do trabalho, pelo menos na minha opinião. Note também o uso da palavra “evidente”. Antes, nós não sabíamos o que acontecia, agora nós entendemos e podemos agir de acordo, trabalhar para mudar a mentalidade, people hacking como eu gosto de chamar.
O cargo de Scrum Master envolve bem mais do que os problemas do time, é também sua responsabilidade, ou deveria ser, fazer com que a empresa como um todo entenda a radical mudança de mentalidade necessária para sermos mais Ágeis, e isso não é fácil. Muitas vezes ser Scrum Master envolve dizer as verdades que ninguém que ouvir, ou fazer as perguntas que ninguém quer receber.
Boa sorte! 😉
