Sobre otimização de processos e liderança... #scrum

Hoje eu quero falar sobre o Scrum. Esclareço desde agora que o que eu busco é trazer temas interessantes, contribuir para o desenvolvimento das pessoas, além de colocar a minha opinião e o meu ponto de vista sobre teorias e temas do meu interesse. A partir daí, quem sabe, trocar idéias e conhecimentos com quem está acordado aí do outro lado da tela. Basicamente é isso aí, espero que você embarque nessa viagem com um mínimo de curiosidade que seja, mas que ao final dessa leitura, tenha o sentimento de que não perdeu o seu tempo com redes sociais.

Começo esclarecendo que o Scrum é, de acordo com o Jeff Sutherland (criador do método e autor do livro “Scrum: A arte de fazer o dobro do trabalho na metade do tempo”), uma nova forma de pensar. O Scrum não é só uma teoria, ele “(...) já é utilizado para tudo, desde construir carros viáveis que fazem mais de 42 quilômetros por litro de combustível até fazer com que os sistemas de banco de dados do FBI chegassem ao século XXI”. E aí eu te adianto, caro leitor, que livro f*** no que diz respeito à quantidade de casos que o autor conta – juro que passei muita parte do livro me perguntando se ele realmente viveu tudo aquilo, se tem algo que ele inventou ou aumentou. A sensação que dá é que ele fez parte de tudo que é importante no mundo (citando alguns casos, vamos desde a origem do Scrum no sistema Toyota de Produção, na aviação de combate do exército, em como o FBI poderia ter evitado o 11 de setembro e por aí vai...).

Muita gente quando ouve falar de projeto consegue visualizar softwares como o MS Project – e similares – e o método da cascata. E aí vem o Jeff e te fala que os famosos diagramas de Gantt que apresentam todas as etapas do projeto, todos os eventos importantes e todas as datas de entrega – para grande maioria dos gestores esses diagramas são apreciados como obras de arte e única forma de apresentar projetos para as diretorias, para os acionistas – são pura ilusão!

O autor simplesmente rasga os diagramas na sua cara e diz “o único problema é que esses diagramas tão impressionantes de se ver estão sempre, sempre errados”.

Eu sou bem cética para algumas coisas, mas gosto de buscar outros pontos de vista, outras abordagens – principalmente quando se trata de otimização de tempo e gestão (seja de pessoas, de processos ou ambos). Eu tenho algumas características reconhecidas pelos meus colegas: metódica, direta, prática e amante de tecnologia para otimizar as tarefas do dia a dia - fatos, não nego nenhum. E quando eu estou no operacional, sempre busco formas de fazer a máquina trabalhar por mim para poder ter mais tempo para analisar os dados/resultados e pensar em como agregar valor ao meu ‘entregável’, isso simplesmente me encanta (igual jura de amor de adolescente mesmo)!

Eu não estou ganhando nada com isso - não é #publi , eu realmente gostaria de reforçar como é gostoso ler esse livro, como o tempo passa rápido e você começa a ter mil idéias sobre o que fazer com tantas informações. Alerta: se você trabalha naquelas empresas à moda antiga (para não ser indelicada) e não tem um cargo/função/oportunidade que te permita contribuir com este método sobre “como fazer o dobro do trabalho na metade do tempo”, já te adianto, é um bom livro, mas vai te causar uma baita frustração, meu amigo. 

De acordo com o criador do Scrum, hoje essa é a “única maneira comprovada para auxiliar projeto”. Jeff chamou o método de Scrum porque “o termo vem do rúgbi e se refere à maneira como um time se une para avançar com a bola pelo campo. Tudo se alinha, posicionamento cuidadoso, unidade de propósito e clareza de objetivo”. Trata-se de uma metáfora perfeita para o que é esperado das equipes.

PONTOS DE DESTAQUE SELECIONADOS POR MIM

“O Manifesto Ágil”: trata-se de um documento desenvolvido pelo Jeff comdezesseis outros líderes, em que eles declararam os seguintes valores “indivíduos em vez de processos; produtos que de fato funcionem em vez de documentação dizendo como deveriam funcionar; colaboração com o cliente em vez de negociação com ele; e responder às mudanças em vez de seguir um plano”. O Scrum é a estrutura construída para pôr esses valores em prática.

“Ciclos de ‘sprints’ ”: ao final de cada ciclo/intervalo (a ser definido pela equipe, pode ser uma semana, duas semanas, um mês) no projeto de desenvolvimento de um sistema, por exemplo, deve haver uma parte concluída do produto a cada final de ciclo. Isso significa que é preciso ter algo funcionando e que possa ser mostrado para qualquer um que queira ver, principalmente para os acionistas e futuros usuários. Essa metodologia permite que as equipes recebam um feedback quase imediato do trabalho realizado para saber se estão caminhando na direção certa e se o que planejam para os próximos ciclos seria de fato o que é esperado deles.

Autonomia: um dos conceitos-chave do Scrum é que os integrantes da equipe decidam sozinhos como trabalharão. É responsabilidade da gerência definir os objetivos estratégicos, mas é incumbência da equipe decidir como atingir essas metas.

“Scrum Master”: a cada ciclo deve-se fazer três perguntas simples “o que você fez desde a última vez que nos reunimos? O que você vai fazer antes da nossa próxima reunião? E quais as dificuldades que você está enfrentando?”. Na minha opinião, esse papel denominado no livro como “Scrum Master” deveria ser obrigatório em qualquer equipe. Se a sua empresa não tem a verba para investir em um profissional assim (e aí eu te convido a analisar se ela tem a verba para contratar alguém para ficar fazendo gráficos de sonhos e apresentando/modificando e ajustando prazos sempre que algum objetivo não é alcançado), você como líder deve assumir esse papel. De acordo com Jeff, na prática o Scrum Master tem o papel de assegurar que as dificuldades que a equipe enfrenta expostas em uma reunião encerrando um ciclo, sejam eliminadas antes da reunião seguinte. E quando falamos de obstáculos/dificuldades, pense que isso pode ser qualquer coisa, desde problemas com burocracia até encontrar ferramentas junto à TI que proporcionem os relatórios que a equipe precisa para continuar com as atividades, enfim, qualquer coisa que esteja atrasando o avanço esperado.

Quantidade não é qualidade: “acrescentar mão de obra a um projeto atrasado faz com que ele atrase ainda mais” – isso foi comprovado em estudos. Lawrence Putnam é citado por Jeff nesse ponto como uma figura lendária que dedicou a vida a estudar quanto tempo se gasta para fazer as coisas e por quê. Seu trabalho mostrava repetidas vezes que projetos com vinte pessoas ou mais demandavam mais esforço do que aqueles com cinco ou menos. “Uma equipe grande demorava cinco vezes mais horas do que uma pequena” para atingir os mesmos resultados.

Transparência: todos os integrantes de uma equipe do Scrum precisam saber o que todos os outros estão fazendo (o trabalho que está sendo realizado, os desafios que estão sendo enfrentados e o progresso que está sendo alcançado). Se o grupo fica muito grande, a capacidade de comunicação constante entre as pessoas é prejudicada.

Eu poderia seguir falando muito mais sobre o Scrum, mas para o intuito deste artigo, encerro por aqui. Se você se interessou, não deixe de ler o livro e procure mais sobre o assunto porque o que eu passo aqui é superficial e é o meu entendimento em relação ao que eu acredito que possam ser dicas sobre como otimizar processos, além de reflexões que você, como gestor, pode começar a fazer para melhorar a produtividade da sua equipe (o Scrum tem muito a contribuir). É o que diz um dos principais pressupostos da PNL (Programação Neurolinguística): Mapa não é território - são pontos elencados por mim devido ao mapa que venho desenhando através da minha percepção sobre o território que eu tenho percorrido na minha experiência profissional. Ou seja, pontos que eu percebi como possíveis melhorias em determinadas experiências que pude vivenciar na minha carreira.

“O que o Scrum faz é promover a união das equipes para criar grandes projetos, e isso exige que todos enxerguem a meta final e façam entregas parciais para atingi-la”.