E quando o funcionário mente?

Em primeiro lugar, no topo deste texto, quero deixar claro que o sentido de funcionário é para toda a empresa, incluindo presidencia, diretoria e gerencia.

Sabemos que a mentira deriva de um ambiente onde a confiança está baixa ou sequer existe. Sabemos também que é uma característica existente no ser humano e até em outros animais. Nosso cérebro sente um certo prazer, pois ele é desafiado. Inclusive, seu cérebro mente para você várias vezes por dia.

Vamos refletir sobre agentes exteriores que contribuem para a propagação da mentira de uma corporação.

O primeiro agente, na minha visão, é a forma como é planejada e executada a distribuição de bônus. Da forma como é feita hoje em dia, (1) prejudica os relacionamentos internos; (2) prejudica a eficiencia da corporação, ao contrário do pensamento comum; (3) fomenta a competição nociva, em detrimento da colaboração; (4) favorece um ambiente fértil para a mentira. Existem outros.

O objetivo deste post é ser curto e não focar nestes quatro fatores que destaquei. Se surgir alguma dúvida sobre o parágrafo anterior, sinta-se a vontade para debatermos nos comentários.

Um segundo agente, já deixei uma pista, é o ambiente hostil à fomentação da confiança. Vários fatores contribuem para isso, (1) Cobranças públicas; (2) Prazos apertados; (3) Falta de visibilidade, dentre outros.

Mais uma vez, o foco não é esse. Deixo os comentários a disposição para um bate papo sobre isso.

A introdução foi longa por estarmos tratando de um assunto delicado. As pessoas não metem porque são más. Bem, algumas sim.

***

Uma máxima da gestão moderna é que você não melhora o que você não vê. Gestão moderna que está aí desde a decada de 70, pelo menos, com Demming, Ohno, Drucker e CIA.

Mas ver, de forma cristalina, todos os processos da sua empresa, detalhados em números, pode entrar em choque com uma necessidade de grande parte da empresa: mentir.

Sabemos como resolver o problema do ambiente nocivo à confiança, mas mais uma vez não é o foco aqui.

Como ver e mentir?

Através de números relativos. Ao relativizar você não mexe com um assunto delicado pré-existente. Lembre-se que o sistema é elástico. Ao introduzir um agente de mudanças, estamos gerando uma pressão interna. Precisamos de habilidade para lidar com essa propriedade elástica.

Boa parte da comunidade lean, sabe que a criação de um ambiente de confiança é fundamental para o aumento da eficiência. Entretanto, sabe que é muito importante medir. Se você não consegue introduzir mudanças, meça. Eu acredito muito nessa linha de pensamento.

Mas ao medir, você pode expor números e entrar em choque com muita gente. Se a sua empresa não está pronta para ver esses números, torne-os relativos.

Ex: Quando fizemos a mudança XPTO, reduzimos em X% a quantidade de bugs em produção. Reduzimos em Y% o leadtime médio. Z% das funcionalidades não retornaram para desenvolvimento. W% do nosso tempo agora é usado criando valor direto para o cliente.

É uma solução simples que pode salvar a aprovação de um trabalho que pode fazer toda a diferença para a saúde da empresa. Não apenas a saúde financeira, mas a saúde do organismo empresa.

E é uma abordagem natural para a maioria das empresas, que estão acostumadas a ver o seu retrato através das porcentagens.

Baseado nos processos de transição que eu vi acontecer, se eu tivesse que escolher uma ação indispensável, esta seria a metrificação. Metrificação de aspectos que ajudem a empresa a melhorar, evoluir. Alguns exemplos são o leadtime, throughput, takt time, touch time. Estes são números que, se melhorados, ajudarão a empresa a aumentar a eficiência. Ajudarão a empresa a poupar dinheiro.

Utilize métricas sempre, procure métricas do passado. Se o ambiente for hostil à metrificação, encontre uma forma de contornar e jogar com as resistências.

Afinal, essa não seria a maior qualidade de uma agente de transição?

Transição - E se não rolar?

Fishbowl durante o AgileTour em Maringá

Durante o fishbowl deste fim de semana, uma pessoa perguntou o que fazer quando a resistência está muito grande. O que fazer quando middle e top management começam a resistir ao norte da visão?

O primeiro ponto para refletir é que nada garante que a transição vai dar certo, mesmo lendo todos os livros do Kotter, Mary Lynn, Drucker, Demming e fazendo todos os cursos oferecidos pelo mercado. E o motivo para isso pode ser expressado na teoria da complexidade. A organização é um organismo vivo, que possui vontade própria, que pensa. Podemos prever algumas reações aos estímulos, mas a maioria é impossível. Nenhuma teoria e práticas anteriores podem garantir o sucesso de um processo de mudança organizacional.

O segundo ponto é que o senso de urgência pode estar baixo, a complacência pode ter se espalhado e o momento simplesmente não permite que você faça mais alguma coisa para tirar o projeto de mudança da inércia. E se o senso de urgência está baixo, pouca coisa poderá ser mudada. Existem alguns termômetros que devem ser utilizados para medir o senso de urgência.

Se você está conseguindo extinguir com facilidade pequenas picuinhas, problemas rasos, existe algum senso de urgência. Se não consegue, o senso de urgência é zero. Se consegue resolver com facilidade alguns problemas no nível gerencial, seu senso de urgência está elevado. Se não, o nível está baixo, mas ainda pode existir. Se você consegue resolver problemas envolvendo o top management e a empresa como um todo, o senso de urgência está elevadíssimo e se for mantido assim, existem grandes chances da transição fluir sem problemas até o fim.

Um exemplo deste último caso é a questão do bônus por meritocracia e a supervalorização das motivações extrínsecas. Se a transição estiver com senso de urgência suficiente na visão "se tornar a melhor empresa para se trabalhar no ramo que atuamos para assim atrair os melhores profissionais do mercado" a guiding coalition conseguirá mexer neste ponto tão delicado. Entretanto, se a visão estiver mal definida, mal comunicada ou nem existir, fica difícil elevar o senso de urgência. Sem senso de urgência, atividades lúdicas poderão ser vistas como palhaçada.

É difícil entrar neste assunto sem tentar analisar o que é falhar em um projeto de transição. Tecnicamente é não completar o projeto. Mas, filosoficamente, será que poderemos considerar uma falha, caso uma semente muito forte tenha sido plantada, que poderá germinar com força para completar o projeto um, dois anos depois?

Fica a reflexão.

Transição - Os efeitos sistêmicos

Muito tenho falado dos principais efeitos sistêmicos mas sem utilizar muito exemplos práticos. Isso acontece pois normalmente quando temos uma evidencia deste tipo de ocorrência, não seria ético divulgar. Entretanto nesta semana ocorreram, quase simultaneamente, dois exemplos que penso não ser anti-ético divulgar.

Transição - A cultura da liberdade

Todos os times, absolutamente todos, onde eu trabalhei a transição do modelo tradicional para o modelo ágil, se prenderam bastante na tal liberdade que os métodos ágeis prega para os trabalhadores do conhecimento. É comum você ouvir: não quero trabalhar neste work item, prefiro este. Estamos atrasados, mas isso não é problema meu.

Transição - Um exemplo de vitória de curto prazo

Bem, nesse caso considero de curtíssimo prazo.

Transição - A importância da visão

Neste post examinaremos a importância de uma boa visão para a transição, para a gestão de mudanças. A definição de uma boa visão está diretamente relacionada ao foco da transição. Ela ajudará a manter as pessoas de olho no objetivo e auxilia ao mostrar como as pessoas vêem a organização após a transição. Como a empresa estará daqui a 5 anos? O que ela estará fazendo de diferente? Como chegaremos até lá? Neste post que escrevi no blog da Crafters abordei todos estes assuntos.

Transição - Não existem métodos porta de entrada

Tenho visto uma onda de pensamentos modernos sobre como iniciar uma transição ágil. Modernos se estivéssemos na década passada. Parece que voltou a "moda" de que o Scrum seria uma boa porta de entrada dos métodos ágeis nas empresas. Apesar de respeitar quem pense dessa forma, eu tenho as minhas dúvidas. Para esse post, chega de rapidinhas.

Transição Ágil x Evolução Ágil

Muito tenho discutido ultimamente sobre o uso do termo transição para indicar um processo de mudança do processo tradicional para o processo moderno de desenvolvimento de software.

Como transição entendemos uma mudança do estado A para o estado B. No nosso caso, da cultura tradicional para a cultura moderna de gerenciamento de softwares.

Os defensores do termo "evolução" argumentam que não conseguimos definir um ponto B claro. Que na verdade o processo é mais evolutivo que transicional. Como eu já disse em alguns fóruns de discussão (e em discussões de mesa de bar), não acho que essa abordagem esteja incorreta. Mas também não acho que usar o termo transição esteja. O motivo é bem simples: eu costumo definir de forma clara o ponto B.

O ponto B, na minha visão, ocorre quando a empresa tem consciência de que é um sistema complexo, valoriza a descentralização, a auto-organização e tem clara ciência do processo de melhoria contínua evolutivo, de como ele ocorre e o que precisa fazer para fomentá-lo. E neste momento, acontece a mágica, aconteceu a transição.

A empresa não precisa mais de um consultor para indicar que é necessário um diagnóstico contínuo do processo. Não precisa de um consultor para dizer que precisa identificar a restrição no sistema. Não precisa mais de um consultor para dizer que é preciso submeter o sistema à restrição. A empresa, como "entidade" se tornou um Jonah. Existe um capítulo inteiro no livro do Goldratt, Theory of Constraints, sobre como se tornar um Jonah. Estou pensando em escrever sobre esse capítulo, pois procurei referências para linkar aqui e não encontrei. Se algum leitor desse singelo espaço conhecer/encontrar, fique a vontade para colocar nos comentários.

Como a transição, na maioria dos casos, acontece como uma evolução do ponto A para o B, os conceitos se intercalam. Eu não passo a adotar o termo evolução em vez de transição porque transição me remete a algo infinito e, na minha visão, o trabalho de um bom consultor/consultoria deve ser finito. O consultor precisa ser capaz de deixar a empresa independente, sendo capaz de conduzir a sua própria evolução, seu próprio processo de melhoria contínua. Quando a empresa acordar para o kaizen e souber como conduzi-lo, a transição estará terminada e teremos apenas a evolução.

Enfim esta é a justificativa do motivo pelo qual uso o termo transição e vou continuar usando, pois ninguém ainda me convenceu a não usar.

Uma pequena história de transição

Eis que ontem, se aproxima de mim, com uma expressão de ótimas intenções, uma menina de QA que me diz:

- Celso, estamos com a intenção de implementar Lean Six-Sigma aqui e gostaria de verificar como deixar as métricas aderentes ao processo de desenvolvimento ágil que a empresa está implementando;

- Ok, eu disse desconfiado. Mas de quem partiu essa iniciativa?

- Do meu diretor.

- Ok, podemos falar amanhã de 9hs as 10hs?

- Marcado.

E hoje cheguei para a reunião, com todas as cicatrizes que outras transições me infligiram.

Ela começa a reunião e no primeiro slide começa a falar sobre as métricas e sobre como medir a performance individual, eficiência individual, etc.

Falou por 10 minutos e não saiu do primeiro slide.

Levantei pedindo a palavra para explicar os princípios e valores daquilo para onde estamos transicionando. Expliquei sobre lead time, throughput, pontos de bug por pontos de história (sim, Agile-MMA), sobre times de fato e sobre o quanto é nociva para a empresa a medição individual. Expliquei sobre times cross funcionais, sobre como poderíamos chegar até isso e que métricas individuais atrapalhariam e muito nesse objetivo.

Expliquei como a área de QA deveria atuar neste novo contexto, buscando oportunidades de melhoria no fluxo e não medindo e apontando dedo para desenvolvedores. Falei que em muito breve QA estaria definitivamente no contexto do time e como os testers agora abraçariam o desenvolvimento, iniciando o fluxo e terminando-o e, principalmente, colaborando para o resultado final e não fazendo uma caça as bruxas.

Expliquei um pouco sobre o Lean, sobre o que eu acho do Lean Six Sigma e que, apesar de não gostar muito, ele está aderente ao nosso discurso de transição.

Então ela me disse que estava adaptando o Lean Six-Sigma ao modelo atual de trabalho deles e que conversaria com blackbelts sobre isso. Tirem suas conclusões. Por questões éticas, não vou colocar aqui as minhas.

Enfim, ela saiu da reunião espantada e disse que nada do que estavam fazendo estava aderente às minhas explicações. Ela fechou o notebook e uma reunião entre diretores será marcada e os pontos ajustados.

De uma coisa eu tenho certeza: Essa menina nunca mais será a mesma.

Transição - Como buscar uma boa reunião diária?

Em uma transição, é natural esperarmos diversos níveis de maturidade nas cerimônias e modus operandi de times diferentes. Uns estão mais maduros, outros menos. Dessa forma, compilei aqui alguns pontos de atenção que identifiquei em times ágeis em transição, em vários níveis de maturidade.

Os passos para uma transição ágil

Muito se fala sobre agilidade, principalmente desde o manifesto. As pessoas já vinham há uma década buscando formas diferentes de desenvolver software, como Scrum e a Extreme Programming. Mas em 2001, o conhecimento da época foi "verbalizado" pelo manifesto, na forma de 4 valores e 12 princípios.

Não, esse não é mais um texto sobre agilidade e seus princípios. Percebi que muito barulho foi feito em cima dessa nova forma de desenvolver software, muitas empresas nasceram ágeis, mas muito pouco foi falado sobre como realizar uma transição do modelo tradicional para o modelo ágil.

Especialistas não servem para transição

O Kanban parece estar se direcionando para outra estrada que considero perigosa: os níveis de maturidade/profundidade no sistema. O perigo nessa abordagem reside, na minha visão, na facilitação para o aparecimento do xiitismo, além de ter pouca eficiencia. Mas isso é assunto para outro dia.

É interessante termos especialistas, como sempre foi interessante em todas as áreas e em todos os tempos. O problema é que esse tipo de mindset simplesmente não serve para uma transição. Disso estou convencido.

Vamos inicialmente deixar claro quem estou chamando de generalistas, especialistas e o que é essa transição.

• Generalistas: Pessoas que conhecem diversos métodos/sistemas/processos/frameworks para desenvolvimento de software ágil, saindo do waterfall que teve a sua importância na sua época, mas que hoje é reconhecidamente ultrapassado e ineficiente;
• Especialistas: Pessoas que conhecem apenas um método/sistema/processo/framework para desenvolvimento de software ágil;
• Transição: Processo onde uma empresa quer mudar do waterfall para outra forma mais eficiente de desenvolvimento de softwares, comumente próximo do Lean.

Quando começo um trabalho de change agent em uma empresa, um dos maiores princípios da abordagem dos sistemas complexos, norteia as minhas ações: observar como o sistema se comporta para então sugerir mudanças. Esse "detalhe" é tão importante que pode significar o sucesso ou o fracasso de uma transição. Precisamos entender que o sistema está acostumado a se comportar daquela forma. As pessoas estão acostumadas a se comportarem daquela forma. Uma ruptura imediata, vai gerar stress no sistema. Uma transição já gera stress demasiado e não precisamos de change agents gerando mais stress. Na verdade, o papel dessa figura é justamente aliviar a tensão que toda a mudança naturalmente gera. 

O sistema é elástico, está sofrendo tensão e está ansioso para voltar ao seu estado inicial. Se tentarmos gerar uma ruptura logo de início, vamos obter como resposta uma resistência (natural) e a tendencia é de tudo voltar a ser como era antes. Entretanto, se tentarmos a abordagem do sapo fervido, temos uma chance muito maior de que a ruptura aconteça sem o sistema perceber. E o melhor: com as pessoas que antes eram resistentes, vendendo as novas idéias como se fossem delas.

Isso quer dizer que não precisamos mais de especialistas no mundo? Não, precisamos de especialistas. Mas especialistas não podem atuar como change agents. Os especialistas não terão independência suficiente das suas especialidades para se afastar do sistema (como nos afastamos de um desenho ou quadro) e buscar a melhor opção. Em uma transição, os generalistas chegam primeiro e os especialistas depois.

Entretanto, neste contexto, os generalistas precisam ser especialistas em uma área de atuação: o pensamento sistêmico e sua derivação, os sistemas complexos. Esse cara precisa saber como analisar o comportamento do sistema e que tipo de mudança será mais eficiente e gerará menos impacto. A consolidação dessas pequenas mudanças e, principalmente, os seus resultados, serão responsáveis por fortalecer o processo de transição e dará aos responsáveis estratégicos da empresa a percepção de que esse processo está indo no caminho certo.

Estou convencido que esse mindset contribui sobremaneira para a implantação dos princípios do Lean, com uma cadência adequada ao contexto, sem rupturas bruscas que poderiam levar uma grande empresa a falência.

[Resenha] Using Kanban to Turn Around Distressed Projects

O autor deste artigo, Steve Andrews, abordou um assunto que me interessa bastante: transição ágil. Neste post vou colocar os meus comentários sobre os pontos que achei interessante e vou terminar com uma observação que julgo importante, mas que aparentemente foi excluida pelo autor do artigo, depois que fiz o comentário no site.