Rafa Nascimento

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”.

Como está o seu Kaizen?

Posted in scrum by Rafa Nascimento on 28/02/2011

A reunião de retrospectiva é o ritual mais importante dentro do Scrum. Esta pausa permitida pelo processo ao time abre espaço para o aprimoramento do processo de desenvolvimento de software utilizado pelo time. Este é o momento sagrado dentro de cada sprint para que o time avalie que práticas deve manter e que práticas deve mudar. Sem esta reunião, o Scrum perde 2 de seus 3 pilares – transparência, inspeção e adaptação. Permitir-se inspecionar e adaptar às necessidades de um time, ambiente, cultura ou contexto específicos é um dos maiores trunfos do Scrum. Isso lhe confere flexibilidade, diferentemente dos processos tradicionais de desenvolvimento de software. É esta oportunidade de parar e rever o que está sendo feito que confere ao time a possibilidade de se superar, sprint pós sprint. Isso porque o time consegue adaptar o processo à realidade de sua existência, para que consiga manter o foco no produto a ser entregue mais facilmente. Sem esta possibilidade, o time seria desmotivado pela obrigação de participar de um processo onde não há o acordo consensual sobre a necessidade de suas práticas, podendo ser retardado pelo processo, ou, pior, dizimado. Retrospectivas são vitais para processos empíricos como o Scrum, e não é de hoje.

Sistema Toyota de Produção
O Sistema Toyota de Produção (TPS) é um sistema de produção integrado, desenvolvido pela Toyota, que compreende a sua filosofia e práticas de gestão. O TPS organiza fabricação e logística para o fabricante de automóvel, incluindo a interação com fornecedores e clientes. O sistema é um importante precursor do “lean manufacturing”. Taiichi Ohno, Shigeo Shingo e Eiji Toyoda desenvolveram o sistema entre 1948 e 1975. Originalmente chamado de “Just In Time Production”, baseia-se na abordagem criada pelo fundador da Toyota, Sakichi Toyoda, seu filho, Kiichiro Toyoda, e o engenheiro Taiichi Ohno. Os fundadores da Toyota atraíram-se fortemente pelo trabalho de W. Edwards Deming e pelos escritos de Henry Ford. Quando estes homens chegaram aos Estados Unidos para observar a linha de montagem e a produção em massa que tinha feito a Ford rica, eles estavam impressionados. Enquanto faziam compras em um supermercado, observaram a ideia simples de um substituidor automático de bebidas: quando o cliente quer uma bebida, ele pega uma, e outra a substitui. Os princípios subjacentes à TPS são incorporados no Toyota Way. Dentre os princípios do Toyota Way, que se dividem entre Aprimoramento Contínuo e Respeito pelas Pessoas, está o Kaizen, um dos maiores responsáveis pelo seu sucesso.

Kaizen: Aprimoramos nossas operações continuamente, sempre buscando inovação e evolução
Kaizen é a palavra japonesa equivalente à palavra “aprimoramento”. Em sua aplicação no TPS, a filosofia é que toda a linha de produção deve parar seu trabalho caso haja algo anormal no processo. Junto com seu supervisor, estes operários sugerem soluções para a anormalidade, e um Kaizen deve ser iniciado. Sendo assim, um ciclo de Kaizen pode ser definido desta forma:

  • Padronizar uma operação
  • Medir a operação padronizada
  • Comparar métricas com requisitos
  • Inovar para atingir os requisitos e aumentar a produtividade
  • Padronizar a nova e melhorada operação
  • Continuar o ciclo infinitamente

Este ciclo também é conhecido como ciclo PDCA (Plan, Do, Check, Act).

5S: Disciplina japonesa objetivando o Kaizen
5S é o nome de uma metodologia de organização de trabalho que usa uma lista de cinco palavras japonesas que são Seiri, Seiton, Seiso, Seiketsu e Shitsuke. A lista descreve como os itens são armazenados em um ambiente de fábrica e como a nova ordem deve ser mantida. O processo de tomada de decisão geralmente vem de um diálogo sobre padronização que constrói um entendimento claro entre os funcionários de como o trabalho deve ser feito. Ela também permite a apropriação do processo por cada empregado. É interessante refletir como cada um dos S’s pode ser aplicado a um time de desenvolvimento de software para aprimorar sua disciplina em prol do aprimoramento próprio.

Selecionar (Seiri): Eliminar todas as ferramentas, peças e instruções desnecessárias. Avalie todos os materiais, ferramentas, e assim por diante, na área de trabalho. Mantenha apenas os itens essenciais e elimine o que não é necessário, priorizando as coisas conforme são requisitadas e mantendo-as em locais de fácil acesso. Todo o resto é armazenado ou descartado.

Simplificar (Seiton): Deve haver um lugar para tudo e tudo deve estar em seu lugar. O lugar de cada item deve ser claramente rotulado ou demarcado. Os itens devem ser organizados de uma forma que promova o fluxo de trabalho eficiente. Os trabalhadores não devem ter que curvar-se repetidamente para acessar os materiais. Cada ferramenta deve ser mantido próximo ao local onde ele será usado – em outras palavras, simplificar o fluxo.

Limpeza Sistemática (Seiso): Manter o local de trabalho limpo e organizado. No final de cada turno, limpar a área de trabalho e estar certo que tudo será restaurado ao seu lugar. Isto torna mais fácil saber onde estão as coisas e garante que tudo está no lugar certo. Um ponto chave é que a limpeza sistemática deve ser parte do cotidiano de trabalho – e não uma atividade ocasional iniciada quando as coisas ficarem muito bagunçadas.

Padronização (Seiketsu): Práticas de trabalho devem ser consistentes e padronizadas. Todos os postos de trabalho devem ser idênticos. Todos os funcionários devem ser capazes de trabalhar em qualquer estação fazendo o mesmo trabalho com as mesmas ferramentas que estão no mesmo local em cada estação. Todos devem saber exatamente o que suas responsabilidades são para aderir ao 3 primeiros S’s.

Manter a disciplina e a auto-disciplina (Shitsuke): Manter e revisar os padrões. Uma vez que os 4 S’s anteriores foram criados, eles se tornam a nova forma de operar. Manter o foco sobre essa nova maneira e não permitir um declínio gradual de volta aos velhos costumes. Ainda pensando sobre a nova forma, também pensar sobre melhorias. Quando surge um problema como uma melhoria sugerida, uma nova forma de trabalho, uma nova ferramenta ou um novo requisito, revise os 4 primeiros S’s e faça as alterações apropriadas.

Uma Retrospectiva sem Kaizen foi tempo perdido
O pensamento Lean, dentro da cultura Agile, exige, primariamente, um processo enxuto de desenvolvimento de software. Combinar o Lean ao Scrum sugere uma mistura poderosa que, além de buscar o maior valor de negócio para o software, busca o melhor processo para que um time específico desenvolva este software. Um processo que elimine exageros ou tarefas desnecessárias do ponto de vista do desenvolvimento de software. Um processo que permita que o time mantenha o foco nos requisitos de negócio e na qualidade sem que ele seja interrompido por exigências desnecessárias do mesmo. O Kaizen é muito importante para que um time atinja a alta performance. Se suas reuniões de retrospectiva não produzem ciclos de Kaizen, a evolução do processo de desenvolvimento de software do seu time está fadada à estagnação, e seu projeto ao fracasso.

Tagged with: , ,
%d blogueiros gostam disto: