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#


Wednesday, October 23, 2013

Decisões difíceis de se tomar!!!!

Bom galera.

Hoje foi necessário eu tomar uma decisão que acredito que todos que um dia forem se aventurar em aplicar SCRUM vão se deparar em algum momento.

O mercado está repleto de bons profissionais mas infelizmente não existe tantos que realmente sabem como trabalhar em um time.
Precisei tomar uma decisão de dispensar um desenvolvedor.

Tive alguns problemas anteriores a adoção do SCRUM que também impactaram na decisão.
Mas no geral estava tendo bastante report negativo do time e eu mesmo estava percebendo as disparidades.
Uma falta de comprometimento com o time que estava prejudicando o andamento dos trabalhos.
Após a retrospectiva os pontos foram ajustados mas não resolveu.

Eu imaginava que isso poderia acontecer e infelizmente minhas impressões se concretizaram.

Quero deixar claro que tecnicamente era muito bom, mas em um Dev Team isso não é o mais importante. Precisa ter muita transparência e comprimento com o time....

Well,
E a vida segue e que venha o próximo....

Thursday, October 17, 2013

Sprint Review e Retrospectiva

Salve...

Sexta passada dia 11/10  e dia 16/10  tivemos nossas primeiras reviews e  retrospectivas.

Quanto aos sprints ,na review , tudo OK. As metas foram cumpridas.

Na retro já tivemos calorosas discussões que foram muito bem pontuadas pelos times. A grande maioria estão diretamente ligadas a falta de organização do time, afinal foi o primeiro Sprint de ambas as equipes e isso era mais que esperado.

Com certeza o próximo sprint já será diferente e o percentual de foco vai aumentar.
Nesse primeiro momento o percentual ficou em aproximadamente 60% e o ideal seria de 70 a 80% mas também era esperado nesse momento.

Algumas falhas foram identificadas e algumas documentações necessárias para nosso processo já emergiram e alguns processos foram adicionados ao Framework.

Já tive um feedback positivo da Diretoria que já enxerga que logo logo vai ficar bem interessante o processo mas os POs ainda estão um pouco apreensivos e um pouco perdidos em organizar o famoso status report e como ainda não conseguimos diminuir o CAOS que está sendo tratado por uma equipe específica ainda estamos com atrasos em alguns projetos.

Hoje vejo times comprometidos , com vontade de trabalhar e bater a meta com qualidade e todos só temos a ganhar com isso.

Estou pensando em um game entre os times para que após alguns sprints completados todos tenham uma parte do Sprint para trabalhar em algo que ajude todos os times a melhorar a performance ou automatizar alguma coisa ,algo assim, para depois apresentar para os outros times.
Acho que isso vai trazer um benefício muito grande para todos e é um trabalho para distrair e mudar um pouco o foco do trabalho pesado do dia a dia.

Bom. . Por hoje é isso.


Até a próxima. ..

Thursday, October 10, 2013

Primeiro Sprint Planning da equipe FÊNIX

Bom.
Here we go again..

Na Quarta dia 09/10 aconteceu o primeiro planning da equipe Fênix..
Definitivamente para minhas equipes pontos de dias ideais funcionaram melhor, portanto vamos seguir assim...

Framework explicado e estimativas feitas.
Pela primeira vez fiquei realmente cansado no Planning, resultado do trabalho duro para colocar tudo em ordem nesses últimos dias.
Quase usei o cafezinho do baralho...
Mas deu tudo certo..



Estou muito contente com o resultado que conquistamos até agora.
A primeira funcionalidade de todos os times atrasaram um pouco, mas nada que não fosse esperado já que estão aprendendo a trabalhar em equipe.
O Orion terminou o sprint antes do dia como previsto, então juntos colocamos mais algumas funcionalidades que caberiam no sprint para completa-lo até a review de amanhã.

É muito importante que os membros do time se dediquem para aprender a trabalhar em equipe já que isso é um pré requisito para ser trabalhar em um dev team scrum juntamente com a auto-organização.

Vejo que meus times estão se esforçando para se adaptar a todas essas mudanças e estou escutando muitas discussões dentro dos times que estão sendo muito produtivas para os projetos e para o crescimento profissional dos integrantes dos times.

De repente olhei pela manhã e vi o time Orion, que foi o primeiro a entrar no sprint, fazendo o Daily Scrum sozinhos e com uma boa organização.
Não me envolvi apenas fiquei de longe observando.



Estou vendo o Canis começar a se organizar também e em alguns momentos interrompo para volta-los para o foco que deve ser discutido na daily. .
Já estou tendo trabalho para barrar as interferências e infelizmente nunca iremos agradar a todos ,mas sempre vamos fazer o máximo possível...
Espero que as outras áreas entendam que é preciso manter o controle sobre as interferências afinal isso é um dos principais papéis do Scrum Master, mas quem for se aventurar em desempenhar o papel de Scrum Master se prepare para enfrentar problemas nessa esfera..

Amanhã dia 11/10 teremos nossa primeira review e retro. 
Tomara que o time tenha anotado muitas coisas durante o sprint para discutirmos e refinarmos o processo...
Até a próxima...



Saturday, October 5, 2013

Primeiro Sprint Planning da equipe Canis

Olá galera..
Na quinta-feira dia 03/10 aconteceu mais um sprint planning. O primeiro da Equipe Canis.
Bom dessa vez cometi alguns erros que preciso me policiar para não ocorrer novamente.
Acabei atrasando o sprint planning por alguns motivos.

1 - Um dos integrantes do time atende o suporte 24 hrs da empresa 1 semana por mês e calhou de exatamente na madrugada anterior ao planning precisar atender um cliente..  Ou seja chegou mais tarde um pouco.

2 - Pela manhã ainda existiam algumas pequena pendências para eles fecharem e preferi esperar um pouco.

3 - Quando estávamos prontos um colega entrou em reunião na sala que iríamos utilizar então tivemos que adaptar e fazer na mesa de algumas pessoas que não estavam lá.. 

Bom é claro que isso atrapalhou...
O planning não acabou antes do almoço e tivemos que voltar após o almoço acabando por volta das 15 hrs..
Mesmo assim o planning foi bom e novamente usando a estimativa com pontos de dias ideais se mostrou mais adequada para a maturidade da equipe.
Não quis forçar a barra para o time pegar a quantidade de tarefas que acredito que eles tenham capacidade de fazer pois é o primeiro sprint e precisam se adaptar a esse novo processo de desenvolvimento.

Metodologia explicada e tarefas quebradas...
Go Canis...

E que venha o planning do time Fênix na próxima quarta.




Monday, September 30, 2013

Primeiro Sprint Planning do Time ORION

Pessoal, conforme prometido, após muito trabalho no final de semana consegui deixar o Backlog pronto para o nosso primeiro Sprint Planning...

Eu acho que nesse primeiro momento o time sub-estimou a capacidade do time, mas eu não interferi e deixei-os confortáveis para assumir aquilo que eles realmente podem entregar como DONE.

Tentamos fazer as estimativas utilizando Story Points, mas foi meio complicado esse método.
Como esses desenvolvedores já trabalham na empresa a bastante tempo fica muito subjetivo estimar por story points. Eles acabavam fazendo a relação com horas e isso acabava não funcionando.

Percebi que era mais fácil mudar o método que ficar batendo nos Story Points, então mudei a estratégia para pontos de dias ideais, que para quem não sabe, consiste em dizer em quantos dias ideais , ou horas ideais é possível implementar a funcionalidade. Lembrando que horas ideais corresponde ao time sem nenhum tipo de interferência. Eu falei da seguinte forma para deixar isso claro ...  Imagine vocês trancados em 1 sala com comida, água, café... Quantas horas fariam o item, sem nenhuma interferência .

Isso para nossa experiência funcionou melhor, mas vou fazer o mesmo exercício com os outros times.

Depois de +- 2 horas de Planing fechamos o Plano e a Meta (menor que o plano) + detalhamento das tasks..

O exercício de quebrar as tarefas foi bem produtivo e consegui mostrar a possibilidade de quebrar o item em pequenas atividade menores que 1 dia para que todo o time trabalhe no mesmo item até matá-lo.

Essa alteração para colocar auto-organização no time e todos trabalharem em cima do mesmo item já foi uma grande mudança na forma que eles estão acostumados a trabalhar. Acho que por esse motivo não quiseram se comprometer com mais coisa.

Bom, é isso, nos próximos dias escreverei mais sobre essa implantação conforme for tendo o feedback do processo.

Segue a foto do time feliz pelo trabalho feito e é isso que mais importa. Todos motivados...!!!

Estamos usando o JIRA com o Plugin Agile aqui na empresa, mas para o planing nada melhor que o velho quadro e post-its.