Rafa Nascimento

Os 10 mandamentos da transição para Agile

Posted in cultura by Rafa Nascimento on 29/11/2012

Neste post, exponho a mentalidade que acredito que deva existir para uma transição para Agile seja bem-sucedida.

  1. Queira e informe-se
    O primeiro passo para a mudança é a vontade de mudar. E, fundamentalmente, a mudança pode acontecer porque a situação atual é ruim ou porque a situação visada é simplesmente mais agradável. De qualquer forma, a mudança só encontrará a vontade de mudar quando a mudança visada toca alguns de nossos valores e impulsionam a emoção necessária para a tomada de decisão e a ação. Ou seja, sem a consciência de que uma mudança é necessária e sem a vontade de passar pela transição, não há perspectiva de sucesso.
    Quando há a vontade de mudar, os próximos passos dizem respeito à informação sobre a mudança pleiteada. Informe-se e, mais importante, compartilhe as informações com as pessoas que querem mudar junto: livros, artigos, comunidades ágeis espalhadas pelo Brasil, conferências e cases de sucesso de líderes da indústria são excelentes fontes de informação. Saiba o que é Agile e, principalmente, o que não é.
  2. Capacite as pessoas
    Um dos equívocos mais comuns no contexto de uma transição para Agile é a falta de capacitação dos profissionais responsáveis ou envolvidos na transição. Mais importante do que simplesmente capacitar as pessoas é gerar nelas o senso de urgência pela capacitação dada a necessidade de uma mudança, de forma que elas mesmas queiram se capacitare não dependam somente as ações da empresa para que isso aconteça. É responsabilidade de toda empresa séria capacitar seus profissionais em busca de bons resultados. Porém, as fontes de capacitação oferecidas pela empresa não são as únicas pertinentes. Além disso, há um ponto importante em Agile: a importância do trabalho coletivo faz com que o perfil comportamental dos profissionais seja tão ou mais importante que o perfil técnico.
    Não buscar garantir que as pessoas estejam preparadas para a mudança de paradigma e querer que a mudança seja bem-sucedida é viver no “mundo de Alice”.
  3. Invista em coaching e gestão de mudança
    Raras são as empresas que tratam uma transição para Agile sequer como um projeto. A grande maioria trata a transição apenas como uma nova forma de desenvolver software. Porém, essa nova forma exige uma mudança de atitude em todos os envolvidos em um projeto ou produto de software. É uma mudança organizacional pesada, que precisa ser efetivada com consistência e precisa ser tratada, no mínimo, com a seriedade que qualquer projeto é tratado.
    Quando falamos em mudança organizacional e transição para Agile, coaches com experiência em ambientes ágeis, transições e mudança organizacional são mais do que necessários para apoiar os responsáveis pela transição, ajudá-los a potencializar os pontos fortes da organização em prol da mudança e a identificar e tratar os impedimentos para a transição em nível organizacional. Coaches, principalmente durante uma transição ágil, que demanda mudança organizacional, não são artigos de luxo. São uma necessidade.
    Tão necessária quanto um coach é a gestão de mudança, para que seja possível gerar senso de urgência nas pessoas envolvidas, realizar uma mudança consistente e de acordo com o contexto e capacidade da empresa, pautando-se em objetivos, como em um projeto.
  4. Assuma a complexidade e a incerteza
    A transição para Agile não é fácil, como já disse em um post anterior. Toda organização é um grande sistema humano complexo e dinâmico, repleto de subsistemas, igualmente complexos e dinâmicos. É importante assumir a existência de tal complexidade e as incertezas que a rodeiam e buscar métodos que ajudem a gerir e buscar os resultados perante essa complexidade, como o Management 3.0 ou Systems Thinking. Seja humilde e busque soluções originais para novos problemas.
  5. Não mecanize-se
    Sistemas complexos, como organizações, performam melhor regidos por princípios. Times são sistemas complexos. E Agile tem como um de seus fundamentos o trabalho coletivo de times auto-organizáveis. Só essas 3 frases deveriam ser suficientes para evitar a simples adoção de práticas sem o conhecimento dos princípios que as baseiam. Agile é um paradigma, não uma metodologia. É uma nova forma de pensar e agir, não um simples conjunto de práticas. Quando adotamos práticas ignorando os princípios que as fundamentam, corremos o risco de prejudicar a performance de nossos times, porque passamos a exigir uma boa execução das práticas engessadas e mecanizadas. Princípios servem para flexibilizar e impulsionar a performance dos nosso times, mantendo-nos focados nos resultados que queremos atingir e nos problemas que precisamos resolver.
  6. Seja o exemplo da mudança
    Acredite na mudança e seja você mesmo o exemplo para a mesma. Em tempos de gestão moderna, onde coaching e liderança servidor estão cada vez mais presente como fortes skills de gestores, simplesmente demandar a transição para Agile não é o suficiente. Para criar o senso de urgência necessário, é preciso que os líderes da empresa acreditem fortemente na mudança que estão liderando. Parece óbvio? É cada vez mais comum ver a transição para Agile ser tratada como uma demanda para a área de TI ou, quando não é demandada, ser constantemente posta à prova.
    Se você mesmo não acredita que a transição para Agile pode melhorar os processos organzacionais e os resultados, nem comece.
    Os maiores líderes que já existiram, como Hitler, Gandhi, Henry Ford, Steve Jobs e Bill Gates acreditavam piamente em seus paradigmas, mesmo que não fossem lá tão éticos.
  7. Transforme problemas em oportunidades
    Toda empresa tem problemas. São esses problemas que devem ser os motivadores para a adoção de métodos ágeis e, por consequência, de uma mudança de paradigma. Quando uma transição é pautada pela simples vontade de ter os métodos ágeis presentes na empresa, as chances de falha são enormes.
    Além disso, todos nós somos contratados para desempenhar determinados papeis. A adoção de práticas ágeis deve ser provenientes de um novo modelo mental que nos faz pensar em novas formas de resolver problemas do nosso dia-a-dia através de novos princípios. Para chegar ao ponto de uma transição para Agile, justifique-a. Faça o seu trabalho do dia-a-dia e resolva seus próprios problemas baseando-se em novos paradigmas nos quais você acredita. Mas não mantenha as melhorias lozalizadas em 1 ou 2 times. A maioria dos problemas que chegam aos times são partes de problemas organizacionais, maiores. Tenha sempre em mente a otimização global, que influenciará na tomada de decisão por uma transição.
  8. Desburocratize a comunicação
    Agile nada mais é do que desburocratizar processos e eliminar gaps de comunicação. Justamente o contrário do que existe em grandes e médias empresas, principalmente naquelas que têm seus processos regidos pelo CMMI. Em vez de primar pela excelente execução das práticas do Scrum ou do Kanban, procure observar como andam os níveis e burocracia e comunicação olho-no-olho na sua organização, não só dentro dos times de desenvolvimento de software. Utilize-se dos princípios de transparência, visualização, inspeção e adaptação, por exemplo, para liderar uma transição. E não deixe de ter uma visão muito bem comunicada, simples e disposta onde todos possam ver todos os dias.
  9. Meça
    Como disse em um post anterior, sem histórico não há melhoria. Todas as mudanças organizacionais em termos econômicos e administrativos são pautadas em mudanças comportamentais da empresa indicadas em gráficos de dados colhidos frequente e consistentemente. Para que as mudanças derivadas de uma transição para Agile sejam assertivas e efetivas, é necessário medir a produtividade dos times, para que os pontos de melhoria sejam revelados e as ações de melhoria provenientes da adoção de um novo paradigma sejam bem-sucedidas.
    Grande parte das transições para Agile são dogmáticas e não-contextuais, o que não funciona.
  10. Mostre competência
    Um dos pontos fundamentais para a geração de confiança é a competência. Nada melhor do que resultados para atestar a competência. Uma transição para Agile só começa a ganhar força, e os responsáveis pela mesma começam a ganhar a confiança da organização em prol da mudança, quando resultados positivos aparecem, e não quando teorias são bem defendidas. E como estamos falando de contextos distintos entre empresas e incretezas mil, a única fórmula mágica que existe para o sucesso é: inspeção e adaptação.
Anúncios
Tagged with: , , ,

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!

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 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: