Choque cultural e falta de identidade...

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Sexta-feira perdi dois ex-funcionários meus. Motivo? Eles diziam que não queriam seguir o rítmo que estava sendo impondo e muito menos ficar trabalhando em projetos "batata assada".

Um projeto estilo "batata assada", como eu chamo, é aquele projeto em que a diretoria te aloca sem te dar nenhuma explicação maior (faz uma reunião explicando o que é o projeto, o que deve ser entregue) e te dá um prazo "para ontem". Outras características: não temos poder para definir escopo, prazo, equipes e muito menos planejamento. Tudo é inferido pela diretoria: eles acham que somos capazes, eles acham que a equipe porque trabalhou no projeto A vai aprender o projeto ABC em dois minutos, etc.

O rítmo de trabalho que está sendo imposto é o comum de algumas empresas. Cobrança por resultados, desenvolvimento de produtos ao invés de protótipos e pesquisas, padronização de alguns comportamentos, "comando & controle", mais horas trabalhadas, etc.

Agora vamos analisar. Considerando que estamos em um grupo de pesquisa, normalmente em projetos de pesquisa (mesmo que alguns envolvam empresas), com pessoas com mentalidade de pesquisa e num ambiente onde não existe perspectivas de crescimento profissional, como é que a diretoria realmente quer comprometimento do pessoal simplesmente fazendo as mudanças descerem goela abaixo?

Eu não tenho a menor dúvida do que irá acontecer: assim como meus ex-funcionários sairam, outros vão se dar conta e sair fora. Entre receber X reais em um grupo de pesquisa e X reais em uma empresa, para onde vocês acham que as pessoas boas e inteligentes vão preferir ir?

É uma pena. Mas ao que parece a diretoria não está pensando estrategicamente. Muitas coisas poderiam ser feitas para tornar o grupo de pesquisa um centro de excelência. Mas dessa forma... acho difícil.

Abraços

Correções de links

Acabo de descobrir que alguns links para download (principalmente os mais antigos, como os do podcast) estão quebrados. Estou corrigindo todos, mas peço aos leitores que se identificarem algum problema, postem comentários avisando ok? :)

Abraços!

Dinâmica: fábrica de aviões versão 2.0

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Pessoal, com atraso estou publicando para vocês a dinâmica da fábrica de aviões que apliquei na turma de "Especialização em gerenciamento de projetos" na PUCRS. A idéia da dinâmica é vivenciar os conceitos do SCRUM, de forma prática, facilitando a visualização dos benefícios. Usamos bastante o conceito PDCA e processos empíricos, que são algumas das bases do SCRUM.

Esta dinâmica foi desenvolvida com base na primeira versão, só que agora ela se tornou mais "ágil" e divertida. Por quê? Inseri algumas novas variáveis e situações que tornam ela mais aderente ao que desejamos passar, ou seja, o conceito do SCRUM.

Para acompanhar este post, é legal você primeiro baixá-la no link abaixo.

Baixar a dinâmica (PDF)
Baixar a tabela em excel (XLS)
Baixar as fichas de responsabilidades (PPT)

Qual a essência da dinâmica? Criar uma linha de produção de aviões de papel que segue uma regra bem simples: a folha de papel começa numa ponta e "termina" avião na outra ponta. Na dinâmica que eu apliquei, foram 3 equipes com 7 membros cada. Se você tiver mais gente envolvida, tente manter no máximo 4 equipes com os membros necessários. Assim você consegue fazer o papel de Product Owner, avaliando o que foi produzido. Crie nomes do alfabeto grego para as equipes (no meu caso foram Sigma, Omega e Gama. Você já verão o por quê disso.

Avise as equipes que a forma como eles se organizarão para fazer a engenharia é com eles. Se quiserem ficar de pé, organizar as mesas em círculos, etc. é problema deles. DESDE QUE o produto comece numa ponta e acabe na outra. Além disso, a outra restrição é que não pode haver estocagem de material, ou seja, cada grupo só pode pegar mais 10 folhas quando a última folha entrar em produção. Isso existe só para tornar o processo mais difícil e para dar trabalho ao Scrum Master, na hora dos sprints :)

A estrutura da dinâmica é simples: as equipes tem três minutos para discutir o processo (retospectiva e planejamento) e ao final do tempo passam a estimativa de produção. Depois elas tem três minutos para produzir o que prometeram, conforme as definições do escopo solicitadas. E assim por diante (ciclo PDCA).

Neste primeiro momento, os papéis não existem ainda. O cliente fictício é a Força Aérea. É informado que a organização quer um novo avião e entrou em contato com as empresas deles. Então a organização quer saber das equipes quantos aviões eles produzem em três minutos. E eles tem UM minuto para dar a estimativa.

Isso mesmo, curto e grosso assim. Qual a idéia por trás? Quantas vezes nossos clientes e chefes chegam para nós: "Quanto tempo a gente entrega um sistema de cadastro e relatórios para o cliente XYZ?". "Bem... depende, como é o escopo?". "Escopo? É um sistema de cadastro e relatórios!! Quanto tempo?". Notaram a semelhança? É exatamente essa. Dar uma estimativa de algo que não se tem a menor idéia. No fim da dinâmica, na retrospectiva, isso serve para avaliar como as estimativas melhoram quando a equipe trabalha e conhece sua capacidade.

Enquanto as equipes fazem as estimativas, abra a planilha Excel para fazer o controle do "previsto / realizado". E marque ali assim que eles derem as estimativas.

Continuando, passe para eles que a Força Aérea gostou das estimativas. E vai abrir concorrência. Agora, a organização passou o escopo do avião. Com base no escopo, as equipes terão 3 minutos para produzir um protótipo. O escopo é bem simples:

- O avião deve possuir 12 janelas
- Deve possuir uma cabine
- Deve possuir o logotipo da empresa que está produzindo, nas asas e na cauda (o logotipo tem que ser o símbolo do Sigma, Gama, Omega - aqui é outra pegadinha!)

Note que não é dito "que tipo de avião" deve ser produzido. A idéia é mesmo que as equipes quebrem a cara na hora de apresentar o protótipo. Esse é o momento mais divertido da dinâmica. Se as equipes perguntarem algo mais sobre o escopo, diga que você não sabe... a organização não passou mais informações.

Cuidado para não passar o próximo slide, onde tem o projeto que a Força Aérea quer. Esse slide é para depois das apresentações!!

Após a produção, peça para um de cada equipe vir até a frente e apresentar o avião. No final, faça o teste do vôo. Não esqueça de solicitar os aplausos para cada apresentação :)

Depois das apresentações, passe o feedback de cada avião. Compare os protótipos com a idéia do que o cliente queria (o slide que mostra isso). Uma coisa que quase nenhuma equipe coloca é PORTA. Pergunte: "Como o pessoal vai entrar no avião???". Se eles reclamarem que isso não foi dito no escopo, fale: "Mas precisava dizer?!". Aqui é a velha demonstração das expectativas do cliente versus produção. :)

Pronto. Agora eles já sabem o que deve ser produzido. Então as linhas de produção vão começar. Diga que eles terão 3 minutos para avaliar a engenharia que irão utilizar para o processo e ao final, passarão a estimativa de produção. Eles deverão produzir os aviões criteriosamente conforme o escopo passado. Aqueles que, ao final dos três minutos do sprint, não estiverem de acordo (faltou uma janelinha, faltou o logotipo correto, etc) não contam como finalizados, mas podem voltar para a linha de produção para serem finalizados. Essa regra é importante e segue os princípios do SCRUM.

Antes de começar, porém, é preciso definir os papéis. Utilize as fichas que estão ali em cima para download (imprima mais fichas "membro da equipe"). Diga que você irá passar para cada um dos membros das equipes uma ficha contendo o papel deles na equipe. Invente que as equipes serão multi-funcionais e cada um terá um papel para desempenhar. Diga que eles devem ler a ficha e atuar conforme está escrito ali e não devem comentar com ninguém quais são suas atribuições.

Por que dessa cena toda? Porque os papéis nas equipes são: SCRUM MASTER (não pode produzir, deve cuidar do time, avaliar o processo, remover impedimentos e buscar matéria-prima), MEMBRO DO TIME (produzirá o produto e avaliará o processo) e ... ELO FRACO.

Cada equipe tem UM Scrum Master e UM Elo Fraco (se você quiser colocar dois por equipe, dependendo do tamanho, é uma idéia interessante também). O Elo Fraco tem como função principal ser exatamente a pessoa que atrasa o processo todo. Aquele cara descompromissado, que destoa dos demais. É o gargalo do time. Mas ele participará do time como se quisesse melhorar o processo (dará sugestões, etc), mas na produção será sempre o gargalo. Ele tem que ser um bom ator e não pode deixar ninguém saber que ele está atuando assim, dai a importância de deixar claro que ninguém pode ler a ficha do outro (se possível, recolha as fichas após eles lerem).

Sabendo disso, diga que o SCRUM MASTER deverá sair da linha de produção e ficar de pé, auxiliando o time nas suas funções. Ele, lógico, pode dizer o que pode ou não fazer.

Feito isso, as regras estão expostas, o escopo é sabido e os papéis e responsabilidades são conhecidos. Dê o start para que eles comecem a planejar o processo e ao final passar a estimativa.

Uma sugestão que causa um efeito psicológico bacana: Durante esses períodos de planejamento, controle o tempo e passe para eles quanto tempo falta para encerrar. Mas nos sprints não avise o tempo, só diga quando encerrou. A idéia é que o Scrum Master ou a equipe percebam que eles que tem que controlar o tempo.

Ao final do planejamento, eles começam os sprints de 3 minutos. Repita daí o processo de "planejamento/estimativa 3 minutos" e "sprint 3 minutos". São três sprints (um número ideal para ninguém cansar ou encher o saco!).

Quando as equipes passarem as estimativas, marque na planilha Excel, na coluna "previsto". Quando você fizer a contagem dos produtos finalizados (que devem estar totalmente de acordo com o escopo) marque na outra coluna "realizado". Assim até acabarem os sprints.

Ao final do terceiro sprint, veja qual foi a equipe vencedora (a que entregou o maior número de produtos). Entregue algum prêmio, como uma caixa de "Bis" para motivá-los :)

Encerrada a dinâmica, avalie com o pessoal como foi o processo. Revele os papéis "obscuros" que existiam nas equipes (os elos fracos) e questione se a equipe havia percebido isso e se tomaram alguma atitude para contornar o problema. Avalie a questão do protótipo versus expectativa do cliente... a questão do trabalho em equipe... a identificação do limite de produção da equipe... o desafio de superar esse limite... a questão do empowerment (onde os membros da equipe avaliavam o processo e tinham poder de sugerir mudanças)... os benefícios da inspeção e adaptação com base na experiência... e encerre comentando a idéia de usar sprints de trabalho.

Faça a pergunta que contém no slide: "Seria melhor entregar todos os aviões em 10 minutos ou % deles a cada 3 minutos?". Dificilmente alguém dirá que o ideal será a primeira opção. Lembre da teoria do estudante (deixar tudo para a última hora), a motivação que será alta nos primeiros minutos e depois cairá com o tempo (afetando a produção).

Antes de terminar, abra a segunda aba da planilha Excel, onde tem o gráfico baseado nas estimativas passadas. Demonstre que o primeiro ponto representa a estimativa quando eles não sabiam NADA do que tinha que ser feito (quando a Força Aérea pediu estimativa sem passar nada). As outras estimativas já foram com base na experiência e no conhecimento do escopo. Possivelmente você terá um gráfico que começa mais alto ou baixo e que depois tende a ficar parecido com uma reta, estabilizando. A idéia é que a gente erra nas estimativas iniciais em +400% e -20%, normalmente. E com o tempo, conhecendo o escopo e nossos limites de produção, as estimativas tendem a ser mais próximas à realidade e tendem a estabilizar. Comente que se houvessem novas sprints, o gráfico se estabilizaria de vez, cabendo à equipe e ao Scrum Master a idéia de tentar encontrar soluções para superar aos poucos estes limites.

Por exemplo, se as equipes produzissem 15 aviões no máximo, o que eles teriam que fazer para otimizar o processo para produzirem 17-18? E assim sucessivamente, quando conseguissem atingir os resultados.

Por fim conclua, demonstrando que eles vivenciaram a essência do SCRUM, ou seja, um ciclo PDCA onde eles planejaram o que fariam, realizavam as tarefas, checavam e avaliavam o processo e por fim tomavam decisões de mudança com base nisso, para alimentar o planejamento.

Termine desafiando: "E se usássemos isso na produção de um software?". Aí é discussão para não acabar mais :)

Ufa! Apesar deste texto longo, eu tenho certeza que você conseguirá aplicar essa dinâmica com o mesmo sucesso que eu tive ao aplicar na turma de especialização em gerenciamento de projetos, na PUCRS. Ali foi muito bacana. Os momentos mais divertidos foram na prototipação e durante os sprints (tive a sorte de escolher bem quem seriam os elos fracos - que foram excelentes atores!).

Ao final da dinâmica, todos entenderam a essência do SCRUM. A mensagem foi passada com total sucesso e tenho a certeza que abriu um novo horizonte para aqueles que não conheciam essas práticas.

Use essa dinâmica como um reforço para passar a mensagem do SCRUM ou mesmo para vender a idéia para sua diretoria. Apesar do pretexto bobo (criar aviões de papel) tenha a certeza de que ao final todos vão ficar bastante satisfeitos com o resultado.

Peço encarecidamente que, quem for aplicar a dinâmica, me envie um email contando como foi a experiência :)

Um grande abraço e façam bom uso!

Decisões nem sempre populares...

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Hoje tive que tomar uma decisão nada popular para a equipe. Sabendo que o projeto em que estávamos estava encerrado (pelo menos na minha visão) e que a equipe ficaria o mês de julho ociosa... e sabendo ainda que o projeto não tem mais verba, tive que tomar a decisão que considerei mais justa para a empresa e para a equipe: fazer o pagamento dos salários de meio mês de trabalho.

O problema: a equipe acabou sabendo disso HOJE quando recebeu.

Por quê? Simplesmente o meu chefe não se decidia. Eu tentava falar com ele pedindo uma decisão, e ele não respondia objetivamente. Então hoje abracei a idéia e tomei a atitude que considerei a melhor, dadas as circunstâncias.

A equipe não recebeu bem a notícia, claro. Mas tratei de conversar com eles e explicar os motivos da minha decisão e assumir a decisão como sendo minha. Notei que isso, apesar do impacto negativo da atitude, melhorou um pouco a percepção deles... uma vez que joguei em pratos limpos com eles.

O segundo problema: eles vão trabalhar este mês em outro projeto... e vão receber como? Isso é outra história. Que possivelmente será bem enrolada também.

Enfim, lá vou eu falar a palavrinha mágica que originou este problema todo: COMUNICAÇÃO. Sempre.

Dinâmica 2.0

Pessoal, ainda hoje eu publico pra vocês a dinâmica "Fábrica de aviões 2.0" que é uma versão bem melhor da dinâmica que eu havia criado anteriormente, para vivenciar SCRUM.

Introduzi algumas variáveis e situações bacanas, que tornam a dinâmica mais "ágil" e divertida.

Vão gostar :)

Abraços

Just a "perfect" day...

Hoje foi mais um daqueles dias típicos de uma pequena empresa e (des)organização.

Ontem mobilizei novamente a equipe do meu projeto, pois o meu chefe disse que queria finalizar o projeto com os testes no trator (do nosso protótipo) sendo aprovados. Então mobilizei a equipe para que eles estudassem o que precisaríamos para completar o projeto. Em paralelo, tive uma bomba para resolver: os pagamentos. Nosso projeto de pesquisa está sem verbas. Logo, o pagamento sairá do bolso da empresa. Prevendo isso, eu desmobilizei a equipe fazendo-a trabalhar apenas 15 dias. Assim negociei com os meus chefes do pagamento apenas destes 15 dias, reduzindo o impacto do custo no bolso deles.

Hoje, eu estava trabalhando no planejamento dos próximos 15 dias de projeto, até o teste no trator. Recém havia enviado um email para o meu chefe, e o meu outro chefe passou na minha mesa e falou: "Flávio, preciso falar contigo e com a tua equipe". Ok, fui até o laboratório e chamei a todos. Fomos para a sala de reunião.

Qual foi a pauta da reunião?

- Vocês foram alocados para outro projeto, que está crítico e precisamos finalizá-lo.

Foi aquele "hã??" geral na equipe. Mas a reunião seguiu com a explicação do tal projeto. 60% de software e uns 40% de hardware. O engraçado é que a minha equipe atual é composta de estudantes de ENGENHARIA da computação, ou seja, software não é a praia deles. Mas durante a reunião o nosso chefe teimava em abordar mais os aspectos de software e também lembrava que "eles já haviam mexido com GPS e então teriam um aprendizado rapidíssimo, de 15 minutos, no projeto".

Um parênteses: eu acho sensacional esse conceito que meus chefes tem, e que é muito comum por aí. Se nós trabalhamos com uma tecnologia em algum projeto, isso nos torna especialistas em qualquer projeto que envolva a mesma tecnologia. Ou seja, a equipe trabalhou com GPS para auxilio de guia de um trator... e agora vai aprender rapidíssimo tudo o que envolve o projeto de GPS para rastreamento de veículos (inclusive com banco de dados e interface gráfica). É aquela mesma história que a gente que cursou informática sofre quando alguém vem e pergunta algo como "tu sabes fazer um índice no Word? Não??? Pô, mas o que vocês fazem nessa faculdade??!".

Ao final da reunião, como de praxe, este nosso chefe definiu que espera resultados já para a próxima sexta-feira. Resultados e decisões "triviais", que envolvem variáveis complexas. Afora o exagero na exigência, toda equipe admitiu que é melhor trabalhar com este chefe, pois ao menos ele é bem objetivo :)

Enfim, até as 15h eu estava planejando um projeto com a equipe. Às 15h05 já estávamos alocado, sem mais nem menos, em outro projeto. E a importância dos testes no trator, que teríamos que fazer? Bem... inexplicavelmente virou secundário.

Uma pequena empresa normalmente possui um ambiente propício para a comunicação, pois é relativamente simples (pouca gente, processos informais, etc). Mas é impressionante a tendência que as pessoas tem de complicar. A previsibilidade é ZERO no meu trabalho. As decisões são tomadas e apenas nos informadas quando a batata já assou. Daí eles jogam no nosso colo e falam "é para ontem!". Mas falar de comunicação lá no meu trabalho é bater na mesma tecla, sempre... infelizmente.

Abraços

Comunicação x Percepção

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Existem diversas formas de passar uma mensagem. Podemos ser tendenciosos ou não. Um bom líder precisa garantir que a mensagem esteja sendo passada da forma correta, sem que haja má interpretação. Já pensou se você quisesse fazer um elogio e o seu subordinado entendesse como uma crítica?

Eu vinha há algum tempo pensando em criar uma forma de mostrar a questão da percepção de uma forma prática. Tive uma idéia de modificar o trailer de um filme mudando totalmente o contexto (uma comédia para um filme de terror, por exemplo). Mas eu as vezes esqueço que, na era da internet e da informação, quando nós pensamos em uma coisa, outros 100.000 já estão colocando em prática.

Vejam os dois exemplos abaixo. Uma versão do trailer original e uma versão "modificada" por... gente com muito tempo livre :)

E se vocês procuravam uma forma de mostrar a importância entre a mensagem e a percepção que ela gera, vocês tem abaixo.

Peguei dois filmes, os excelentes "Rain Man" (um drama) e "O iluminado" (um terror sensacional).

RAIN MAN ORIGINAL


RAIN MAN TERROR


O ILUMINADO ORIGINAL (trailer meia-boca já que é quase impossível achar o original!)


O ILUMINADO COMEDIA ROMANTICA