Rafa Nascimento

Baby Steps: os passos mais firmes para a melhoria contínua

Posted in mudança by Rafa Nascimento on 13/11/2012

Comentei neste post sobre a impressão que tenho de que a prática dos métodos ágeis e, principalmente, a transição para uma cultura mais favorável aos trabalhadores da informação, está dando sinais de que está andando para trás. Como uma mola, que estica ao seu máximo e volta com toda a força. Uma reação sistêmica causada pela falta de novos princípios e valores bem enraizados nas empresas. Princípios e valores mais aderentes a uma nova cultura. Princípios e valores que, quando bem enraizados, permitem que uma empresa seja capaz de superar as dificuldades de uma transição cultural. E á isso que representa uma transição para Agile ou Lean. Transição cultural. Diante desta minha impressão, fica a comprovação de que a aplicação de práticas de forma mecanizada fica a mercê de preferências. E se a cultura, a forma de pensar, não muda, o status quo prevalece. E práticas antigas também.

Que fique registrado: quem diz que a transição para uma cultura Agile ou Lean é fácil está mentindo. E nenhum dos profissionais sérios que conheço afirmam tal coisa. Toda mudança corporativa é complexa. Muito mais é uma transição cultural. Porque a cultura emana de pessoas, de comunidades, de sociedades. E o mais importante de tudo: tais mudanças são demoradas. Parece-me que, quando envolvidos em uma transição, em uma mudança, esquecemos de um princípio básico abraçado por uma prática de um dos métodos ágeis mais bem-sucedidos que existem: baby steps, presente na prática de Test-Driven Development (TDD), presente no Extreme Programming (XP).

Baby Steps significam nada mais que “um passo de cada vez”. Ser paciente em prol da qualidade. Ser atencioso e focado em prol da melhoria contínua. Enquanto os orientais, precursores do Lean, pensam em melhoria contínua como uma questão de meses ou anos, nós, ocidentais, pensamos em semanas ou dias. E perdemos os resultados de longo prazo. Perdemos a consistência de uma mdança embasada pela real melhoria contínua. Embasada por baby steps.

Em seu livro An Agile Adoption and Transformation Survival Guide, Michael Sahota adota uma abordagem mais suave para a transição cultural, sugerindo que as empresas devem dar os passos que estejam dispostas a dar e assumir as consequências que estejam dispostas a assumir durante uma transição. Porém, esses passos devem ser firmes, focando em uma transição consistente baseada em novos princípios e valores e que não agridam os resultados.

Em seu livro Leading Change: Why transformation efforts fail, John P. Kotter, especialista em gestão de mudanças, defende: “A maior lição que pode ser aprendida dos casos mais bem-sucedidos de mudança é que o processo de mudança transcorre por uma serie de fases que, no total, exigem uma quantidade considerável de tempo. Pular passos somente cria a ilusão de velocidade e nunca produz um resultado satisfatório.”

Tenho visto cada vez mais times de desenvolvimento e líderes tentando empurrar as mudanças “goela abaixo”, o que gera um resultado de curtíssimo prazo, resistência e estresse. Vejo muita impulsividade no que diz respeito à adoção de métodos ágeis, e um dos resultados mais frequentes de tal impulsividade é a falta de resultados consistentes da transição cultural. E a posterior desistência da empresa que estava, no mínimo, curiosa para analisar o resultado do esforço. Desistência muitas vezes irreversível e geradora de rótulos como “o Scrum não funciona” ou “Agile é para mimar os desenvolvedores”.

Enfim, é preciso muita paciência, disciplina e perseverança quando falamos de qualquer tipo de mudança que envolva pessoas e cultura. Da menor à maior. Porque pessoas são complexas e reagem de diversas formas diferentes aos mais diversos estímulos que o ambiente pode lhes gerar. Cuidado com a sua transição. Cuidado com a sua mudança. Foco nas pessoas, e menos nos processos. E Baby Steps!

Anúncios

A importância do RH em uma transição cultural

Posted in ágil, cultura by Rafa Nascimento on 06/11/2012

Tenho visitado algumas empresas de desenvolvimento de software durante as últimas semanas, e vivenciando uma excelente experiência sobre o ambiente de trabalho e os processos dessas empresas. Estas visitas e a hospitalidade dessas empresas têm sido uma excelente fonte de informação e aprendizado sobre o que está funcionando, o que não está funcionando e o que está sendo adaptado em um contexto agile/lean. Mas, em uma dessas empresas, uma coisa me chamou muito a atenção. E foi algo inclusive já vivenciado por mim e que trouxe lembranças úteis: o apoio do RH para o desenvolvimento de um ambiente de trabalho leve, descontraído e, ao mesmo tempo, produtivo.

Em muitas empresas percebemos uma mescla entre o Departamento de Recursos Humanos e o Departamento Pessoal, muitas das vezes havendo somente 1 departamento, com separação interna entre RH e DP. Mas, afinal, qual a diferença? Basicamente, um Departamento de RH tem como objetivo maior cuidar do bem-estar e desenvolvimento do capital humano da empresa. Este é o real responsável pelas pessoas e seu bem-estar. Normalmente é administrado por administradores e psicólogos. O Departamento Pessoal cuida de toda a burocracia que envolve folha de pagamento, admissão, demissão, férias, etc. Normalmente é administrado por contadores. Um documento de graduandos da Inesul explica mais detalhadamente as diferenças. E daí?

Daí que por muitos anos o “bem-estar das pessoas” ficou firmemente ligado ao cumprimento de leis trabalhistas e às burocracias relacionadas a pessoas. Poucas são as empresas (em sua maioria, as grandes empresas) que executam de fato a diferenciação entre RH e DP. E as consultorias de desenvolvimento de software? Conto nos dedos de 1 das mãos, e ainda sobra dedo, as consultorias que possuem um departamento ativo de RH. Felizmente, não é o caso dessa consultoria que visitei. Embora ainda existam vergonhosos casos de subordinação do RH ao DP. Enfim, por muitos anos, o Departamento de RH da grande maioria das empresas ficou, também, mergulhado nas burocracias que cabem única e exclusivamente ao Departamento Pessoal.

Com a adoção dos métodos ágeis para desenvolvimento de software, emerge uma preocupação humana muito forte, que se relaciona diretamente com motivação e, consequentemente, com produtividade. Uma preocupação psicológica, sociológica e antropológica, que está ligada única e exclusivamente ao RH das empresas, mas não ao DP. Mas, como o RH pode cuidar de tantas pessoas e observar de perto suas necessidades como seres humanos e profissionais? Surge, então, a figura do coach de equipes. O profissional que está ligado a cada equipe da empresa, assim como gerentes de projetos ou coordenadores, e que está única e exclusivamente focado na performance dos times do ponto de vista da motivação e do bem-estar. Enquanto gerentes de projetos e coordenadores têm por objetivo realizar a entrega de projetos ou produtos, ou seja, a execução do trabalho propriamente dito, e fazem a “ponte” com outros departamentos para que o trabalho seja coerente, o coach tem por objetivo garantir que a suas equipe tem as melhores condições possíveis, sob diversos pontos de vista (processos, clareza de requisitos, engajamento entre as pessoas do time, ambiente de trabalho, desenvolvimento profissional) para executar o trabalho que lhes é solicitado, mais importante ainda, como uma equipe de fato. Este é o profissional que vai fazer a “ponte” com o RH e atuar como um “braço” do RH em cada equipe. Não como um regulador um cumpridor de normas do RH, mas como um verdadeiro porta-voz das equipes para o RH, em busca da melhoria contínua da gestão e do ambiente de trabalho.

Fica claro, então, a importância do apoio do RH em um processo de transição para métodos ágeis ou lean para desenvolvimento de software. Mais do que apoiar, é preciso que o RH também acredite na nova cultura. Dessa transição surge um papel estritamente ligado às pessoas e ao seu bem-estar, que precisa de apoio, e mais do que apoio, de parceria com o RH (não o DP), ou seja, com os psicólogos da empresa, para que o seu trabalho seja bem-sucedido e a transformação dos processos e do ambiente de trabalho aconteça de fato e, mais do que isso, transforme-se em uma mudança cultural, firme e duradoura.

Arrisco dizer que sem o apoio dos psicólogos da empresa, a transição para a agilidade pode transformar-se em mais uma mera mudança nos processos. E é preciso muito mais do que video-games expostos ou budgets exclusivos para treinamentos. É preciso que os valores da empresa sejam identificados, expostos e celebrados todos os dias, e que eles sejam a base de todas as ações corporativas. Assim como fez essa empresa que visitei, hoje, uma das “100 Melhores Empresas para Trabalhar” do Rio de Janeiro.

Tagged with: , , , , ,

O futuro da Agilidade não é bonito

Posted in futuro by Rafa Nascimento on 30/10/2012

Concordo com o que Jurgen Appelo diz em seu post I don’t care about “Agile”.

Muitos fatos e experiências levam-me a crer que o Agile não tem um futuro necessariamente bonito. Embora a vontade, obviamente, seja oposta, é inegável o momento controverso pelo qual a filosofia passa. Compartilho abaixo alguns fatores que chamam a minha atenção e convido-os a uma reflexão.

  1. A figura mais emblemática rumo à adoção da agilidade e à mudança cultural necessária à agilidade, o Scrum Master, é um papel cada vez menos requisitado nas empresas. No ano de 2011, uma média de 8 a 10 anúncios de emprego buscando um Scrum Master eram encontrados para a cidade do Rio de Janeiro. Hoje, nenhum é encontrado. Muitos Scrum Masters que emergiram, emergiram de vontade de ver um novo ambiente de trabalho. Poucos têm o preparo necessário para exercer o papel, que, hoje, é mesclado por muitas empresas ao cargo de desenvolvedor, ao papel de líder técnico ou até mesmo ao papel do gerente de projetos. “Mas o Scrum Master é um papel!”, muitos dirão. Sim. Segundo o PMBoK, o Gerente de Projetos também.
  2. Não houve e nem está havendo uma mudança substancial na disciplina de gerenciamento de projetos, documentada hoje em dia pelo PMI. Muitos anúncios buscando gerentes de projetos que citam os métodos ágeis passam a impressão de que o conhecimento requerido é um “backup” para o caso de aparecerem projetos que fujam aos tradicionais, guiados pelo RUP. Resta a esperança de que gerentes de projetos tradicionais incorporem os princípios ágeis e que os líderes ágeis compreendam que o conhecimento sobre gerenciamento de projetos só tem a acrescentar ao trabalho. E resta a esperança de que a nova versão do PMBoK traga uma mudança substancial na disciplina considerando-se a gestão ágil, e não apenas citações.
  3. Uma sensação de final de “oba-oba” paira no ar. O Scrum foi inegavelmente o framework ágil de maior sucesso que apareceu, o método Kanban, até então, não tem mostrado grandes resultados e nenhum dos frameworks ágeis, nem mesmo o XP, pelas experiências que tive até hoje, conseguem manter as pessoas imbuídas em manter o processo funcionando minimamente bem. No mínimo respeitando os princípios do Agile e do Lean. Isso se deve a uma adoção mecanizada dos processos e a ausência de um trabalho de mudança cultural, que é muito mais complexo e demorado. Fica a impressão de modismo. A impressão de que a agilidade não vai ultrapassar a barreira da novidade. Vale lembrar que, apesar de a filosofia ágil ter mais de 10 anos, somente entre 2006 e 2008 ela começou a adentrar grandes empresas.
  4. Muitas empresas que adotaram a agilidade, hoje, estão tendo uma “recaída”de comando-controle, basicamente, por expectativas de produtividade não atendidas. Mais uma vez, fruto da falta de mudança profunda na cultura, que faz aferir a produtividade da mesma forma como aferia-se antes da “mudança” e da subestimação do fator humano no ambiente de trabalho. Além disso, empresas famosas por seus ambientes favoráveis aos profissionais da informação e criação, como a Google e o Facebook, evitam afirmar que utilizam métodos ágeis.
  5. A crença de que a filosofia ágil é algum método milagroso que transforma todas as pessoas que são tocadas em pessoas altamente comprometidas. É fato que a atenção ao fator humano na agilidade é imensamente maior, mas pessoas que não são comprometidas com as metas da empresa estão por toda a parte. Apesar da agilidade tratar essas pessoas de forma diferenciada, com compaixão e buscando encontrar a melhor equipe e projeto para elas, em certos casos não há solução que não a dispensa do profissional. Nem sempre há final feliz. E profissionais “espertos” e imaturos existem em qualquer lugar.
  6. Foco exagerado no processo e baixo na gestão do ambiente de trabalho. Uma das formas mais efetivas de provocar uma mudança cultural é mudar o próprio ambiente de trabalho e fazê-lo fluir “no sangue”. E exemplos não faltam: Google, Microsoft, Facebook, Philips. Na minha opinião, a parte mais efetiva de uma mudança concreta rumo aos princípios do Agile e do Lean é a mudança do ambiente de trabalho e a sua adequação ao trabalho com a informação e criatividade. E mais do que fazer a transformação: garantir que as novidades são úteis e são utilizadas pelos profissionais. Cansei de ver videogames e salas de descompressão “espetaculares” disponíveis aos profissionais que são vigiadas ou só podem ser usadas fora do horário do expediente. Acreditar que as mudanças podem gerar aumento de produtividade e incentivar o funcionamento de todas as iniciativas de ambiente. Se o foco estiver todo no processo, há grandes chances de ser só mais um processo que foi experimentado pela empresa.
  7. Negligência ao histórico dos times. A filosofia ágil é baseada em experimentação. E não há experimentação se não há estado anterior e estado atual. Métricas de performance são importantes para que as ações de melhoria contínua possam ter chance de ser efetivas. Métricas de satisfação do cliente são importantes para garantir que o planejamento dos esforços está apontando para a melhor direção possível.

Enfim, se continuarmos ignorando estes e outros fatores que, talvez, nem eu perceba, definitivamente há grandes chances de a filosofia ágil ser só mais uma moda. Assim como a Qualidade Total e a mais recente Re-Engenharia.

Como medir a produtividade de times ágeis

Posted in métricas by Rafa Nascimento on 22/10/2012

Um dos mantras mais repetidos em uma cultura ágil é “melhoria contínua”. Porém, pouco se faz de fato para facilitar o surgimento de um verdadeiro fluxo de melhoria contínua em um time ágil. Na maioria das vezes, apenas retrospectivas lúdicas com dinâmicas que visam diminuir o tormento de mais uma reunião e que, com o passar do tempo, por conta de resultados superficiais, perdem o efeito “suavizante” que deveriam ter para que a reunião gere um bom plano de ação. Então, como podemos tornar nossas retrospectivas mais produtivas e factuais? Como podemos ajudar nossos times na árdua tarefa de aferir a sua própria performance? Eis a maneira que encontrei de endereçar estes problemas.

Segundo Patrick Lencioni, em seu livro The 5 Dysfunctions of a Team, um time não pode ser considerado um time de verdade se o mesmo não é capaz de aferir os seus próprios resultados e reagir conforme a informação conhecida. Isso porque não é possível melhorar o seu processo se não há um histórico no qual se basear. A melhoria contínua, enfim, só se torna realidade quando é possível concluir que aspectos do processo são passíveis de melhoria, através de métricas.

Em muitas empresas, métricas são vistas como vilãs pelos times de desenvolvimento de software. Isso porque, durante muito tempo, as métricas foram utilizadas, em grande parte, para promover verdadeiras “caças às bruxas” em times que não vinham colhendo bons resultados. Ou seja, as métricas eram utilizadas, tardiamente, para buscar culpados por falhas e insucessos em projetos. Algumas vezes, métricas eram utilizadas sem um propósito claro, e sim pelo simples fato de que elas deveriam existir, perdendo-se excelentes oportunidades de descobrir problemas antes que eles acontecessem.

Para facilitar o processo de melhoria contínua no meu time, me fiz a seguinte pergunta: o que é interessante como métrica para o meu time, e ao mesmo tempo enxuto? Que métricas deveriam estar presentes em seu dashboard? E para responder a estas perguntas, recorri ao livro Agile Project Management, de Jim Highsmith, e ao triângulo da agilidade proposto por ele.

Segundo Highsmith, projetos ágeis devem buscar o equilíbrio entre valor agregado ao negócio, qualidade técnica e as restrições tradicionais de um projeto (tempo, custo e escopo). Tendo em vista estes prismas, criei um dashboard que oferece métricas para aferir os dados de cada um deles. O dashboard, então, fica dividido em 3 partes: o quão efetivo o time está sendo em trazer valor para a empresa que comprou o projeto, o quão efetivo o time está sendo em desenvolver um produto de alta qualidade e o quão efetivo o time está sendo em entregar valor e qualidade dentro das restrições de tempo, escopo e custo do projeto.

Para o prisma de valor agregado, por exemplo, utilizo-me de métricas como velocidade (quantidade de story points que um time á capaz de entregar por iteração), lead time (tempo decorrido entre o pedido de uma feature e a disponibilização da mesma em produção) categorizado por story points, tail (tempo decorrido entre a conclusão de uma feature e a utilização da mesma pelo usuário final) e cumulative flow (representando o tempo que cada passo do processo consome durante o desenvolvimento das features).

Para o prisma de qualidade interna, realizo, por exemplo, medições como a quantidade de pares distintos que estão sendo formados por iteração, a quantidade de releases com features e com bug fixes e a quantidade de quebras do CI por iteração.


Por fim, utilizo, por exemplo, um burndown por story points do trimestre e um gráfico de alocação de horas do time categorizado por tipo de atividade para o prisma das restrições de projeto (um empréstimo da galera da Globo.com!).

Desta forma, deixo visível para o meu time a performance de cada iteração e podemos discutir de uma forma mais factual as possíveis melhorias no nosso processo. Retrospectivas lúdicas são úteis em determinadas ocasiões e momentos do time, mas há momentos em que a melhor opção é vasculhar os dados históricos para encontrarmos possíveis pontos de melhoria que talvez não seriam vistos a “olho nu”.

A arte de contar histórias

Posted in apresentação, evento by Rafa Nascimento on 13/10/2012

No dia 6 de setembro vivi um dos dias mais felizes da minha vida: ministrei a minha primeira palestra em um evento de proporções nacionais, a Agile Brazil. A palestra se chamava “Team Building: A arte de transformar grupos em times.”. Mas o que eu gostaria de compartilhar aqui não é a minha experiência em ministrar uma palestra nesse evento ou o conteúdo da própria palestra. Gostaria de compartilhar o processo de criação da mesma.

O processo que utilizei para compor a palestra foi o descrito no livro Presentation Zen. Mais importante do que as dicas sobre utilização de imagens, diminuição da incidência de textos e utilização de espaços em branco é a ênfase na história que você deseja contar durante a sua apresentação. A história que compartilhamos durante nossas palestras são muito mais importantes do que a apresentação em si. De fato, a apresentação (Keynote ou Powerpoint) são apenas apoio para que o apresentador conte a sua história. Criar uma palestra seguindo tal processo faz com que, no final, os slides, sozinhos, não façam sentido algum. Porém, quando acompanhados da história que se deseja compartilhar, parecem complementar perfeitamente o palestrante.

Seguindo o processo sugerido, realizei um grande brainstorming de termos que rodeavam o tema da minha palestra em post-its. Em seguida, colei os post-its na parede, organizando-os em 3 grupos temáticos:

  1. O que é um time?
  2. Modelos de desenvolvimento de times
  3. Mantendo o team building

Nenhum destes 3 temas ficam visíveis ou estão presentes durante a minha apresentação. São apenas grupos que me ajudaram a organizar as minhas ideias e juntá-las de forma que fizessem sentido dentro de uma história. Aproximadamente 70% do trabalho foi focado na organização da história e dos grupos temáticos. Em seguida, organizei a ordem cronológica de cada um dos grupos, possibilitando a visualização da minha palestra na parede, em post-its, organizados como um user story map. Utilizar os post-its e organizá-los em grupos e depois cronologicamente foi essencial para a organização da minha história por conta do fator facilitador da visualização dos dados com os quais estava lidando. Foi muito fácil mover, remover, errar, desfazer, apenas utilizando papeis e a parede. Provavelmente, se eu estivesse utilizando o Keynote, levaria algum tempo entre ir e voltar, fazer e desfazer, e reorganizar slides dentro do arquivo e cronologia das imagens.

Por fim, depois da minha história pronta, construí os slides utilizando o Keynote e buscando por imagens que me ajudassem a contar a minha história pela internet. Todo o processo de construção da apresentação durou pouco menos de 1 semana, sendo que o processo de construção dos slides no Keynote durou menos de 1 dia, tamanha a facilitação promovida pelo processo de criação de história que utilizei.

Observando atentamente, 2 coisas me chamaram a atenção: primeiro, a facilidade natural que temos em lidar com o paupável (os pos-its colados na parede). Porque a minha história estava fisicamente disponível e dividida para mim, não hesitei em tomar as melhores decisões e em voltar atrás algumas vezes. Segundo, a visualização da minha história. De forma simples, a história que eu queria contar estava na minha frente. Isso facilitou deveras a criação da mesma. Talvez, se eu tivesse partido logo para o Keynote, a história estaria disponível na minha frente após muito trabalho, e seria muito mais difícil de me desfazer de algumas decisões e desfazer algumas coisas, forçando uma posterior reorganização dos slides. Todas as decisões ainda estariam sendo tomadas no campo das ideias, enquanto os post-its na parede me ajudaram a concretizar rapidamente as ideias e brincar com elas.

De forma simplificada, foi esse o processo que me ajudou a ministrar uma das palestras mais celebradas da Agile Brazil 2012! /

%d blogueiros gostam disto: