Veja neste post, como que o amigo Celso Martins está transformando uma equipe para observar os valores da agilidade, dentro de um ambiente relativamente hostil ao próprio movimento ágil.
Nessa sua jornada, o sistema principal escolhido foi o Kanban. Entretanto, neste contexto complexo, ele decidiu aplicar um conceito mais amplo, o AgileMMA (que apresentei aqui em outro momento).
Sugiro fortemente a leitura desse relato de como que uma adoção pode ser pragmática e efetiva. Conheça também a estratégia que ele usou para planejar essa mudança, comunicar a alta gerência, treinar a equipe, para “conviver” estrategicamente com o processo cascata existente e por fim, para gerar toda a adaptação necessária à criação de sinergia com o ambiente.
Reduzir o desperdício ou otimizar qualquer forma de trabalho é um grande desafio, pois não basta apenas eliminar tarefas julgadas como desnecessárias, mas sim, trata-se de uma grande mudança na mentalidade das pessoas para que seus comportamentos sejam melhores e também “mais enxutos”. É disso que trata o Pensamento Lean (Lean Thinking).
Revivendo uma antiga parceria, nesse mês de novembro está sendo publicado um artigo meu chamado “O Diferencial Scrum” na Revista JavaMagazine número 73, que em breve estará disponível nas bancas de revistas de todo o país.
Há cerca de um ano, iniciei um desafiador trabalho de coaching em Agile para uma instituição financeira/bancária. De forma que como é uma empresa relativamente grande, têm nos permitido usar ferramentas diferentes para resolver problemas específicos, um exemplo disso é que usamos Scrum para projetos desenvolvimento de software e algumas práticas da FDD(Feature Driven Development) para engenharia e gestão de requisitos.
Um das áreas com qual eu atuo, é uma equipe de sustentação de produtos (suporte) que atende a vários clientes internos diferentes, com demandas (novas funcionalidades e correções) totalmente diferentes e principalmente numa necessidade de ritmo totalmente independentes da outra.
Imagine ou lembre que você está solteiro e morando sozinho em sua casa… Conseguiu? Se sim, seja sincero comigo: Por quanto tempo você deixa sua casa bagunçada? Não saberei exatamente qual será sua resposta, mais de uma coisa estou certo: UM SOLTEIRO DEIXA A CASA BAGUNÇADA POR UM LONGO TEMPO.
Normalmente um solteiro só arruma a bagunça de sua casa, sempre que há uma necessidade iminente de receber uma visita qualquer (família, amigos, amigas, paqueras, etc.). Dessa forma, vamos refletir um pouco: Qual o motivo de um solteiro fazer isso somente estimulado pela visita de alguém? A resposta é pura é simples, O desejo de mostrar uma boa imagem para os outros.
Já falei um pouco sobre esse assunto no artigo Vencendo o estado de negação numa Sprint Retrospective, onde abordei algumas questões psicológicas referentes ao Ide, Ego e Superego, principalmente pela dimensão do superego, que é a instância da personalidade responsável pela projeção positiva de nossa imagem, orientada aos valores de certo e errado do universo social que estamos inseridos.
Ao participar do Agiles 2008 realizado em Buenos Aires(Argentina), nós da InfoQ Brasil, tivemos a oportunidade de realizar uma entrevista exclusiva com o simpático e bem humorado casal de gurus, criadores do Lean Software Development, Mary e Tom Poppendieck que foram Keynotes no evento.
Destaco aqui um fragmento da resposta de Tom Poppendieck, sobre os pilares do Lean:
O segundo é o respeito pelas pessoas e esse pilar é baseado no maior, no mais sério desperdício: o desperdício de talento, desperdício de esforço, desperdício intelectual de pessoas e seus aprendizados. Respeitar pessoas é uma coisa muito profunda. O principal trabalho de um líder numa empresa lean não é conseguir que o trabalho seja feito; seu principal trabalho é treinar seu pessoal, ajuda-los a melhorar, ajuda-los a tornarem o processo melhor.
Talvez uma das frases mais clichê das organizações seja: “Não é nada fácil ser um líder!”, não somente pela complexidade comum nas relações humanas, mas principalmente pela dificuldade que é compilar ao seu favor o imenso e variado arsenal de idéias existentes sobre o tema liderança.
Não pretendo com esse breve texto discorrer sobre alguma dessas idéias como solução matadora para uma melhor liderança, pois apenas vou compartilhar uma opinião pessoal de um elemento que ajuda significativamente qualquer tipo de líder, porém, antes de chegar nesse elemento, permita apenas me sustentar em dois singelos pensamentos de Peter Drucker:
O primeiro fragmento de pensamento de Drucker é “Baseie sua estratégia em situações, não em fórmulas”, o que me dá bastante conforto com idéias como Liderança Situacional e também com a abordagem da Inspeção e Adaptação (tão importantes nas metodologias ágeis), para mostrar que não existe uma única forma de trabalho adequada para todas as situações (o que reafirma ainda mais o primeiro parágrafo desse texto).
No título acima estou referenciando uma famosa música da banda de rock (heavy metal) Judas Priest para tentar explicar que na prática não existe uma ideia matadora de todos os problemas, mas sim evidenciar que a incerteza nossa de cada dia, é chave para nossa evolução e aprendizado mesmo que isso ocorra em pequenos passos.
É interessante refletir que esse singelo conceito está por trás da Agilidade, porém não o compreendemos ou simplesmente o esquecemos; Talvez isso ocorra devido ao fato desse conceito misterioso ir muito além da abrangência de Agile como metodologia, pois trata-se de uma forma de olhar e tratar os tormentos comuns à visão dialética e à inconstância própria da natureza humana.
Inicialmente o título dessa FAQ seria algo como “E o Prazo?”, porém, mudei para esse título cima (O que você prefere? Uma mentira ou software funcionando no início de um projeto?) que representa bem a minha opinião sobre esse assunto que é muito recorrente nas listas, nas palestras que faço e até mesmo em clientes, portanto, vamos discutir um pouco sobre como a famosa questão do “prazo” é tratada sob a ótica sugerida pelas Metodologias Ágeis de desenvolvimento de Software.
Após alguns bons anos de adoção e evangelização de Agile, tenho orgulho em dizer que tenho pouquíssimas certezas sobre o tema (pois a magia é inspecionar e adaptar o conhecimento continuamente). Porém, uma dessas poucas certezas é: Se você for preguiçoso, FUJA das metodologias ágeis.
Segue abaixo uma entrevista com Eduardo Cheng(ScrumMaster) realizada nesse mês de Maio (2009) em Brasília-DF, que narra algumas experiências (erros e acertos) na adoção de Scrum no ambiente Bancário/Financeiro do Sicoob Brasil.
Esse foi um dos primeiros projetos realizados através do Scrum na organização, onde inicialmente meu amigo Alexandre Magno desenvolveu uma consultoria espetacular para essa empresa, em seguida, euiniciei um trabalho bem intenso de Coaching junto às equipes, gerências e superintendências de toda a área de TI.
Portanto vale muito apena assistir esses 13 minutos de vídeo, que relatam um pouco dessa vivência através dos olhos de quem realmente usa o Scrum (aliado com FDD e Lean) para auxiliar no seu gerenciamento do trabalho de desenvolvimento de software.
Sabe aqueles momentos em que estamos profundamente mergulhados na resolução de um problema técnico dentro de um projeto? Muitos desses momentos são importantes em função de comumente nos oferecer grandes desafios intelectuais e que uma vez resolvidos, nos trazem grandes momentos de satisfação ao nosso sistema mental de recompensas.
Sendo que muitas vezes, principalmente quando se está num projeto solo, realmente não há outro jeito, temos que ter essa heróica atitude para sermos “matadores de problemas” no projeto, leve o tempo que for necessário (minutos, horas ou dias) e a qualquer custo, afinal senão as coisas realmente não caminham.
Porém, caso o cenário seja pertinente a uma equipe de trabalho, imagine qual o custo para o projeto quando ocorrem essas situações? E outro questionamento interessante, é que quando há uma resolução heróica e individual desses problemas, qual o prejuízo ao compartilhamento de conhecimento a essa organização?
Segue abaixo o material de minha palestra sobre Gestão de Requisitos Orientado ao Negócio, Através de Práticas Ágeis e Enxutas, realizada no último dia 16 de fevereiro na RSS (Recife Summer School) organizada pela CESAR.Edu.
Um dos primeiros desafios quando se implanta metodologias ágeis, é nivelar qual o entendimento necessário para iniciar um projeto de desenvolvimento de software e como prover uma gestão de requisitos alinhada com a necessidade de entregas e com a aderência necessária dentro de uma organização, portanto, nesse texto pretendo provocar uma reflexão através de alguns conceitos básicos, sobre como que através da filosofia incremental e iterativa das metodologias ágeis, podemos ter um escopo de um produto suficientemente informativo para iniciar e conduzir um projeto de desenvolvimento do mesmo.
Segundo as visões de Taiichi Ohno e Shingeo Shingo, que figuram como grandes pensadores do STP (Sistema Toyota de Produção ou TPS – Toyota Production System), um dos pontos chaves para a evolução desse sistema produtivo, é a prevenção às reincidências de problemas em qualquer nível do processo, para que seja possível alcançar um estado de melhoria contínua e efetiva sobre a forma de trabalho e acerca dos produtos desenvolvidos.
Para sustentar essa filosofia, o STP evidencia dois grandes elementos muito fortes da cultura oriental, que são o Hansei e Kaizen, que conforme mostro abaixo, apesar desses elementos serem benéficos isoladamente, sua sinergia quando juntos, torna-se essencial para a aplicação da melhoria contínua dentro do Pensamento Lean.
Dentro da TPS (Toyota Production System), Poka-Yoke é um dispositivo físico de controle que é acionado automaticamente quando há algum erro ou defeito no processo de produção, sendo que esse acionamento é feito normalmente por duas motivações:
Para controle, pois quando o mesmo é ativado, a linha de produção é interrompida automaticamente para que o problema detectado possa ser resolvido.
Para advertência, apenas usando algum tipo de alarme visual para sinalizar às pessoas envolvidas, que algo precisa ser revisado para evitar um problema maior.
Veja que essa forma de controle de qualidade com base em inspeção, é um dos pilares do modelo produtivo baseado no Pensamento Lean e no ciclo PDCA (Plan, Do, Check e Action), por isso, como as metodologias ágeis fornecem um bom começo para a construção desse estado de pensamento Lean e para obtenção do ciclo PDCA nos projetos de desenvolvimento de software, é importante que possamos identificar quais práticas ágeis, podemos usar como formas de Poka-Yoke.
Portanto, vou elencar abaixo, algumas práticas e idéias que julgo serem alinhadas a esse conceito de Poka-Yoke, porém, acredito que essa conjectura é viva e, cada um pode observar a implementação mais válida para seu contexto.
TDD (Test-Driven Development) – Talvez essa seja a prática de maior aplicação como Poka-Yoke pela comunidade ágil mundial, pois na essência, com TDD podemos capturar quando ocorre um erro no código, parar o desenvolvimento, corrigir o erro e atualizar o teste unitário para que o mesmo possa prevenir futuras ocorrências daquele referido erro.
Inspeção de Código – Outra forma que também julgo ser uma importante implementação de Poka-Yoke, é a inspeção de código feita entre os membros da equipe, que apesar de ser baseada em atitudes, é uma interessante maneira de verificar, antes de promover uma funcionalidade ao Build que será entregue, se o código produzido, está dentro dos padrões escolhidos para o projeto, se está seguindo boas práticas, se está feito da maneira mais simples possível, ou se está em acordo com o teste desenhado previamente para aquela funcionalidade.
Gestão de Impedimentos através de KanBan – Talvez não seja um mecanismo com a finalidade de parar um Lead Time de um projeto, porém, a atitude de manifestar algum impedimento visualmente através do quadro informativo, têm um impacto psicológico muito forte na equipe, fazendo com que o mesmo sirva como uma forma de alerta de que algo precisa ser resolvido dentro do projeto, antes que se torne um problema mais grave.
Feedback Contínuo – Para concluir essa breve lista, acredito que através das cerimônias como Sprint Review ou a Sprint Retrospective, podemos ter fotografias muito nítidas de como está a qualidade do produto que está sendo desenvolvido e de quão eficiente e eficaz está o nosso processo de desenvolvimento, portanto, conforme o resultado dessa fotografia, podemos criar um Kaizen, que é outro conceito Toyota, que trabalha com a aplicação de pontos de melhoria contínua no produto ou no processo. Inclusive, através desse feedback contínuo, podemos exercitar também o Hansei, outra idéia muito importante da filosofia Japonesa (Aka Toyota), que consiste em fazer uma profunda auto-reflexão para identificar quais foram as falhas e os pontos de melhorias num processo ou num produto.
Termino esse texto lembrando que o mesmo não é um manual passo-a-passo da aplicação de um Poka-Yoke em seu processo, mas sim, uma pequena semente para provocar a reflexão de como você pode usar conceitos do Pensamento Lean, para melhorar sua forma de trabalho dentro do desenvolvimento de software e ter significativos ganhos de qualidade no produto desenvolvido. Portanto, muito obrigado e até a próxima.
Sobre o autor:
É Engenheiro de Software, com mais de 15 anos na área de TI, atualmente trabalha com como Coach em metodologias para importantes empresas do segmento de serviços, indústrias e bancário. É Diretor Editorial da Revista Visão Ágil, Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.
Contatos: manoel@visaoagil.com
Nas minhas leituras recentes sobre Lean, eu encontrei uma tabela bastante informativa, que tenta clarificar os mitos sobre o que é e o que não é Lean, e continha as seguintes informações (livre tradução):
Mito – O que não é TPS
Uma receita tangível para o sucesso
Um programa de gerência
Uma série de ferramentas para implementação
Realidade – O que é TPS
Uma maneira consistente de pensar
Uma filosofia de gerenciamento
Um ambiente de trabalho em equipe e melhoria
Uma busca sem fim por uma forma melhor
Apesar de Lean não ser um conjunto de ferramentas, tudo que se fala sobre o assunto na industria de TI é sobre uma série de … ferramentas. Tempo de ciclo, kanban, sistemas pull, flow, qualquer um desses conceitos já foi anunciado como a última solução para projetos de software.
Não quero dizer aqui que essas ferramentas não vão nos ajudar a desenvolver software, mas com certeza estaremos perdendo a principal parte do que Lean tem para nos ensinar se não começarmos a pensar sobre seus princípios, isto é, a segunda parte daquela lista, a filosofia e o pensamento.
E se você começar a pensar nos princípios Lean, verá que eles não são muito diferentes dos que norteiam o desenvolvimento ágil ( ao menos o que eu penso sobre agile:-) ). Se você le sobre um um ambiente de trabalho em equipe e melhoria, você pode dizer se estão falando sobre Lean ou Agile?
Mas o problema é que quando a a maioria das pessoas pensa sobre Agile, elas pensam sobre práticas e não príncipios. Ao invés de ser colaboração e comunicação, Agile para eles é programação em pares, iterações e retrospectivas. E é nesse ponto que eu acho que está a solução. Parar de pensar em qual é o próximo conjunto de práticas que nos farão melhorar e começar a pensar em quais são os princípios que estamos seguindo e como fazer para aplicá-los melhor no nosso contexto.
Um abraço.
Francisco
Ps: Esse post é uma tradução de um post originalmente publicado no meu blog: What is Lean? And Agile?
Sobre o autor:
Francisco Trindade é desenvolvedor e consultor da ThoughtWorks UK. Engenheiro de Computação e mestre em Engenharia de Software pela UFRGS, Francisco possui 5 anos de experiencia em desenvolvimento de software, alem de ser um entusiasta e praticante de metodologias ágeis.
Eu acredito que um dos pontos importantes em qualquer metodologia ágil é a possibilidade de melhoria oferecida ao time através do constante feedback recebido e também práticas como retrospectivas.
Apesar disso, não é difícil encontrar times que não estão acostumados a questionar seu próprio comportamento e acabam repetindo sempre os mesmos erros.
Esses dias, lendo o livro Toyota Way, eu obtive uma melhor compreensão desse fato, e como o mesmo é encarado na Toyota.
Segundo o autor (livre tradução):
Trabalho em equipe nunca encobre a responsabilidade individual na Toyota. Essa responsabilidade individual não é sobre culpa e punição, mas sim sobre aprendizado e crescimento.
E ainda mais importante, nas palavras de Andy Lund, que é um gerente de projeto na Toyota e cresceu no Japão (livre tradução):
Pessoas que não estiveram no Japão podem não entender que o objetivo não é prejudicar o indivíduo, mas ajudá-lo a melhorar – não é prejudicar o programa, mas sim mostrar falhas que possam ser resolvidas no próximo programa. Se você entende isso profundamente, você pode entender a crítica construtiva. Não importa o quão bom é um programa ou apresentação que alguém fez, sempre existe algo que pode ser melhorado, então nós consideramos isso uma obrigação. Não é um ponto negativo obrigatório, mas sim uma oportunidade de melhoria obrigatória — é o coração do kaizen.
E isso é exatamente o que acontece na prática. Pessoas interpretam sugestões e observações como críticas negativas, e não vêem que a única alternativa para um time manter um processo de melhoría contínua é continuamente questionar seu comportamento e enfrentar os seus pontos fracos.
Francisco Trindade é desenvolvedor e consultor da ThoughtWorks UK. Engenheiro de Computação e mestre em Engenharia de Software pela UFRGS, Francisco possui 5 anos de experiencia em desenvolvimento de software, alem de ser um entusiasta e praticante de metodologias ágeis.