Thursday, October 8, 2015

Saindo das filas individuais

Salve galera..

Agora vou tentar explicar como sai das filas individuais na equipe de desenvolvimento.

Eu tinha a convicção que cada um trabalhando na sua atividade era péssimo para conseguir um ambiente colaborativo.

Hoje conhecendo mais a fundo Kanban e pensamento sistêmico entendo que o efeito que essa mudança causou foi muito maior que a colaboração.

É de extrema importância procurarmos sair do modelo de filas individuais para que possamos melhorar o processo de trabalho.

Temos dois modelo de filas..


O modelo A (filas únicas para cada servidor) não lida bem com a variabilidade no tamanho dos lotes, pois quem está na fila de um servidor que recebeu um lote muito grande o restante da fila ficará muito tempo parada.

O modelo B (fila única geral) é bem melhor para suportar variabilidade no tamanho dos lotes.

Além desse problema o modelo A gera uma especialização excessiva (ja que tendemos a passar o trabalho para a pessoa que mais conhece do assunto), gera também uma ansiedade desnecessária no servidor que precisa, além de executar o trabalho, se preocupar com a fila dele,  e gera um problema sério para se ter um ambiente colaborativo pois cada servidor não tem estimulo nenhum para colaborar com o servidor do lado, já que cada um é responsável somente pela sua tarefa, fazendo com que não exista o conceito de time.
Outro problema é a cultura de heróis e vilões onde as pessoas boas sempre vão processar as filas muito rapidamente que outras pessoas. Essas pessoas que processam rápido serão valorizadas e outras não. Isso é um problema pois perdemos a capacidade de organizar em times pessoas onde a fraqueza de uns é compensada com a especialização de outros para conseguirmos que todos evoluam em um ritmo sustentável.

Bom quando eu fiz essa transição nem de longe eu tinha todos esses conceitos em mente, mas sem querer tomei a decisão correta.

Como eu fiz a transição.???

Tínhamos muitos projetos simultâneos, eu separava as funcionalidades mais complicadas, com mais riscos, para os devs mais experientes, ou seja, eles sempre pegavam as buchas. Eu ia separando conforme a complexidade, não existia colaboração nenhuma e o aprendizado não era difundido.

Quando decidi separar em times todos os Seniors estavam com vários projetos e funcionalidades travadas neles, mas eu precisava deles dentro do time, mas se eu colocasse eles dentro do time com suas respectivas atividades eles iam ficar descartados do mesmo jeito e os outros não conseguiriam andar sozinhos..

Além das funcionalidades que eles estava trabalhando existiam várias que estavam em homologação, testes que com certeza iriam voltar com algum tipo de problema, mas ninguém mais conhecia aquilo..

O fato era , para funcionar em times eu precisava de 1 deles em cada time.

O primeiro trabalho que fiz foi mapear o que cada 1 estava fazendo, quais projetos estavam parados e poderiam voltar a qualquer momento, problemas esperando resolução, etc.

Junto com eles tentamos definir o tamanho e o tempo para acabar as coisas, riscos, tentando prever o que poderia acontecer no futuro.

Com isso conseguimos mapear qual deles estava com o menor risco para entrar em um time.

Dividi a atividade desse um que estava no fim para os outros dois experientes..

Pontuamos o risco de coisas que estavam penduradas neles e batizei como bolas de natal. Como estávamos no final do ano nossa meta era após o natal as bolas já não estarem mais nas árvores (eles)..

Cada um ficou com algumas bolas de natal penduradas. O primeiro Senior entrou no primeiro time , ele e mais 2 devs, 1 pleno e 1 júnior. (cenário já explicado em posts anteriores).

Nós colocávamos uma tarefa dentro do Sprint para caso uma das bolas de natal acordassem dentro do Sprint o Senior pudesse atuar.

Os outros Seniors continuaram em filas individuais assim como todo o restante do time.

Dessa forma fomos virando em times conforme os Seniors iam liberando suas atividades atuais.

A saber, as bolas de natal perduraram até quase o meio de 2014 , mas fomos nos organizando e retirando cada uma delas. Conforme 1 liberava pegava alguma bola de natal do outro e assim seguimos.

Obviamente isso afetou um pouco nossa eficiência, mas, agora tenho em mente que eu estava partindo para um mindset da eficácia sem perceber e isso foi muito bom..

Espero que esse relato ajude vocês caso precisem sair dessa enrascada, mas alinhem internamente antes, pois vai diminuir inicialmente a quantidade de trabalho que será possível executar até que todos aprendam a trabalhar em time.

Outra coisa é que possivelmente você encontrará alguma resistência de algumas pessoas em trabalhar em time. Mantenha o foco e se envolva tentando retirar os problemas em conjunto com o time.

No meu caso precisei dispensar pessoas pois elas estavam sendo resistentes demais a colaborar e o próprio time começou a exclui-la. Prepare-se para isso também.




Muito além de Scrum.. Não posso me apaixonar pelo Martelo.

Galera, faz um tempo que não escrevo nada.. 

Muita coisa aconteceu nesse tempo, continuo na mesma empresa, e os times continuam formados na mesma estrutura. 

Porém agora temos 3 times de projetos, que hoje tenho outra percepção deles, e um de sustentação que era o meu time que trabalhava e trabalha dentro de um ambiente mais caótico.

Comecei a perceber muita dificuldade de continuar a implantação do Scrum by the book. A mudança dos papeis, a mudança na forma de trabalho que metodologias ágeis pedem é extremamente difícil de fazer em uma empresa com o método tradicional correndo no sangue. 
Pessoas desmotivadas e despreparadas para mudanças sugam nossas energias e desmotivam qualquer processo de mudança. 

Então percebi que isso precisa ser feito de outra forma , e isso Scrum não trata.

Esse é o motivo do assunto do post. "Não posso me apaixonar pelo martelo."
Qualquer metodologia é uma ferramenta para resolver um problema.  O maior problema é quando nos apaixonamos pela ferramenta e começarmos a tender a querer usá-las em qualquer situação, achando que ela sempre vai resolver os problemas. O Scrum era o martelo que eu aprendi a usar e comecei a achar que ele era a solução para todos os problemas. Sonho meu.. 

Foi nesse momento, em buscas de possíveis soluções para esse problema de implantação que eu comecei a estudar Kanban e venho procurando me especializar cada vez mais em métodos ágeis mais que frameworks e ferramentas específicas. Cada problema requer diferentes abordagens. 

Hoje estou começando a aplicar esses conceitos que tenho aprendido e melhorado com o curso do Software Zen com o Alisson Vale, que de longe é o melhor curso que eu ja fiz. E nem acabou ainda :).

Uma coisa extremamente importante que eu aprendi foi que a primeira coisa que trava qualquer possibilidade de melhoria de um ambiente de trabalho é o uso de filas individuais. 

Eu nem sabia que isso era de extrema importância para esse Mindset que estou estudando agora, mas por muita sorte eu resolvi esse problema em 2013. 

Agora acho importante mostrar como fiz para me livrar das filas individuais. Mas isso é um assunto para o próximo post.

Um grande abraço a todos. 

#Confie na sua intuição#