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

Esqueceram de mim

Posted in papéis, scrum by Rafa Nascimento on 11/08/2011

A principal tarefa de um Scrum Master é curta e grossa: garantir o bom funcionamento do Scrum. Existe uma tarefa implícita nesta frase, que é extremamente desafiadora: educar bons Product Owners. Muitos Product Owners ainda não conhecem seus papéis como deveriam, geralmente têm bastante experiência em projetos de software e raramente são incentivados a criar uma comunidade para que possam desafiar suas certezas em prol de uma nova realidade. Além disso, eles enfrentam a principal mudança que os métodos ágeis trazem consigo: foco nas pessoas como o verdadeiro motor durante o desenvolvimento de um produto, não no projeto. Em um primeiro momento, a cultura ágil privilegia os times de desenvolvimento de produtos, o que torna a adoção da cultura mais fácil para os desenvolvedores. Por conta da dificuldade particular de educar Product Owners, muitos acabam “esquecidos” pelos Scrum Masters e viram verdadeiros pedregulhos no caminho dos times.

Quem é o Product Owner?

O primeiro passo para se educar um Product Owner é saber quem ele é (ou quem ele pode ser). E definir quem é o Product Owner é uma tarefa do Scrum Master. Algumas características ajudam nesse desafio:

Segundo Roman Pichler, em Agile Product Management with Scrum, um Product Owner deve ser:

  • Visionário e executor;
  • Líder e membro do time;
  • Comunicador e negociador;
  • Com poder de decisão e comprometido;
  • Disponível e qualificado.

Levando em consideração tais características, podemos elencar alguns profissionais que podem se encaixar no papel:

Analista de negócio: Este profissional tem a peculiaridade de conhecer bem as regras de negócio de uma organização sendo ele um profissional de TI. Pelo forte foco no produto que a cultura ágil prega, ele acaba sendo uma boa opção por seu conhecimento das necessidades da organização. O problema é que nem todo analista de negócio sabe ou quer medir o progresso do desenvolvimento do produto e resolver, ele próprio, as barreiras de comunicação que dificultam a integração entre as partes de um produto.

Gerente de produto: Pouco explorado, este profissional é utilizado em pouquíssimas empresas. Na minha opinião, é a melhor representação de um Product Owner. É um analista de negócio, que tem responsabilidade sobre o prazo de seu produto e precisa reportar o progresso do desenvolvimento do mesmo aos seus clientes. O único perigo com este profissional é o de ser uma pessoa hiperativa que não consegue esperar que as soluções emirjam do próprio time. Esta atitude pode minar a auto-organização e a auto-gestão do time.

Gerente de projetos: Algumas empresas já tentaram elencar gerentes de projetos como Product Owners. Funciona bem, desde que o profissional consiga se desvencilhar do hábito de comando e controle que seu papel original propõe. Adotando uma mentalidade de coach, de liderança-servidora e focando no produto e na satisfação do cliente acima de tudo, o gerente de projetos também pode se tornar um bom Product Owner.

Usuário-chave: Usuários têm outros afazeres em suas rotinas que não podemos ignorar. Quando estamos falando de projetos pequenos, onde o próprio dono de um empreendimento trata com 1 ou 2 desenvolvedores, o usuário-chave como Product Owner funciona muito bem. Quando o produto começa a crescer e ficar mais e mais complexo, surgem questões tecnológicas das quais um usuário-chave não tem a mínima ideia do que significam. Sem contar que este tipo de Product Owner tem a tendência à otimização local e ignora as questões de integração com outras áreas da empresa dentro do produto. Nesse momento, um usuário-chave como Product Owner pode ser extremamente prejudicial ao produto.

Um bom Product Owner leva todos a bons sprints

Um time Scrum que não tem um bom Product Owner está fadado a fracassos. Os insulmos oridundos deste papel são tão importantes quanto o produto que está sendo desenvolvido pelo time de desenvolvimento. Em todas as experiências que tive com times ágeis, o Product Owner tinha um peso enorme sobre o progresso do time. Negativo ou positivo. Um bom Product Owner sabe motivar o time em prol da sua visão de produto e consegue, facilmente, definir o plano de ação para ter aquele produto, ao final de um projeto ou período. Um mau Product Owner é capaz de segurar o progresso do time inteiro e, mais do que isso, desmotivá-lo por sua falta de visão, clareza e segurança e colocar seu produto em sérios apuros. Sem um bom Product Owner, não há um bom time. Sem um bom time, não há um bom produto.

Coaching, não só mentoring

Para um time de desenvolvedores, o que importa é desenvolver software e ter seu conhecimento constantemente desafiado para que criem boas soluções para os problemas que encontram durante a construção de um produto. Se estamos utilizando Agile ou Waterfall, pouco importa. Desde que todos sintam-se em casa e estejam felizes em estar ali. Em minhas experiências, é relativamente fácil conduzir a adoção de um framework ágil em um time de desenvolvedores. Principalmente porque a cultura ágil favorece seu bem-estar. É um trabalho muito mais forte de mentoring, de ensino, do que de coaching.
No caso do Product Owner, a realidade é outra. Desenvolvedores, designers, testadores. Todos continuam sendo desenvolvedores, designers e testadores. Mas um Product Owner, provavelmente, era gerente de projetos ou analista de negócio. Além disso, a cultura ágil “prejudica”, à primeira vista, o seu tempo de resposta ao cliente. Ele está passando por 2 grandes mudanças: no formato do seu trabalho e no seu próprio papel dentro da cultura. Não há dúvidas: haverá resistência. E tal resistência não é quebrada somente com o mentoring em Scrum do Scrum Master. Este Product Owner vai precisar de um Scrum Master no papel de seu coach, ajudando-o a desenvolver novas competências para uma nova realidade e auxiliando-o no questionamento de suas certezas para descobrir novas certezas. Não é um trabalho fácil, nem breve, mas é fundamental.

Scrum Master: seja parceiro do seu Product Owner

Costumo dizer que, no Scrum, o gerente de projetos foi dividido em 2: Scrum Master, responsável pelo processo e pelas pessoas, e Product Owner, responsável pelo produto. Antes, um gerente de projetos era responsável por processo, pessoas e produto. Fatalmente, e não pouco frequente, seu foco se mantinha no produto, ignorando o bem-estar das pessoas e a manutenção de um bom processo de desenvolvimento do produto. Scrum Masters e Product Owners, juntos, devem representar gerentes de projetos melhores do que os representados em uma só pessoa, pois as atenções estão bem divididas. Se estes dois papéis representam um profissional, para que ambos tenham sucesso é preciso uma colaboração e parceria muito fortes. Apesar das rusgas e discussões que os prazos e negociações trazem, Scrum Masters e Product Owners trabalhando em parceria são vitais para o bem-estar e felicidade do time de desenvolvimento  e, consequentemente, para o time Scrum e, consequentemente, para o produto e, consequentemente, para a empresa e, consequentemente…

Tagged with: , ,

Reunião Diária: muito maior do que se imagina

Posted in scrum, time by Rafa Nascimento on 15/05/2011

Uma Reunião Diária é muito mais do que uma simples reunião onde todos os membros do time se juntam para dizer o que estão fazendo. Se fosse tão simples quanto isso, eu diria que a Reunião Diária não tem utilidade alguma, pois simplesmente olhar para o quadro já informa tudo o que cada pessoa está fazendo. Esta reunião é uma reunião de “status report” para o próprio time. Ora, se um time se diz auto-organizável, este deve ser maduro o suficiente ao ponto de que cada um de seus membros assuma compromissos perante o time e o próprio time saiba cobrar estes compromissos. A Reunião Diária é o momento para isso.

Times iniciantes no Scrum ou no XP utilizam a seguinte fórmula para obter o real valor desta reunião e mantê-la “chamativa”:

  • 15 minutos de reunião
  • O que fiz até esta reunião?
  • O que farei até a próxima reunião?
  • O que impede meu trabalho?

O valor envolvido nesta reunião é a comunicação. E a maior utilidade dela é a possibilidade de os membros do time assumirem compromissos perante os outros membros e cobrarem compromissos anteriores. É bom lembrar: aquele grupo específico de pessoas está reunido em prol de um objetivo maior. Em um time, o sucesso é compartilhado e o fracasso também. O que o outro está realizando é tão importante quanto o que eu estou realizando. É tão parte do meu trabalho quanto o código que eu mesmo faço. Isso se chama código comunitário: todo o código gerado pelo time é de responsabilidade de cada um de seus membros. Portanto, se você fez besteira ou está enrolando para terminar uma tarefa, seja humilde o suficiente para se retratar perante o time e agir em prol do seu sucesso.

Quando um compromisso é assumido em uma Reunião Diária, isso quer dizer que, até a próxima, este compromisso estará liquidado. Se não estiver, o mínimo que os outros membros do time devem fazer é se interessar pelo que impediu o compromisso de ser honrado. Uma falha do próprio time pode ter ocasionado isso. Uma falha do ScrumMaster pode estar causando isso.

A Reunião Diária mantém-se curta para que não seja evitada. Assim, caso haja algum problema maior para ser resolvido, outra reunião, entre as partes interessadas ou todos, pode ser iniciada após o status, e todos os outros membros seguem o seu fluxo de concentração. O tamanho e a frequência desta reunião permitem que os membros do time mantenham-se focados pela maior parte do tempo no objetivo do sprint. Sua frequência diária é fruto do tamanho curto de um sprint, e permite que não haja desperdícios ou surpresas durante o mesmo, além de manter o time sincronizado.

Ou seja:

  • 15 minutos de reunião – mantém a reunião relevante e enxuta.
  • O que eu fiz até esta reunião? – O compromisso que eu assumi na última reunião deve estar liquidado nesta reunião. Se não estiver, há um impedimento ou mal-planejamento.
  • O que farei até a próxima reunião? – O compromisso é assumido perante todos os outros membros do time. Respeitar este compromisso é respeitar o time.
  • O que impede meu trabalho? – Impedimentos devem ser relatados ao ScrumMaster. A resolução de impedimentos deve ser cobrada do ScrumMaster.
Tagged with: , ,

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: