Every work environment has a well defined “work model”. It is common to hear people saying things like “- there is no process at all here! We just do it.”. Even in these cases, where there isn't an explicit “process”, a work model can be extracted and used as starting point for improvement. Your work model is just the way you do the work at certain point. It is dynamic, because it evolves positively or negatively along time regardless your will. However, it evolves slowly most of the time allowing you to extract a physycal representation that can help you to see how it looks like at certain point, what are possible improvement points to persue and, mainly, what are your current options for taking action and delivery not only things right, but also the right things. Identify and understand your work model, visualize it and talk about it frequently is a great way to increase awareness of the game you are playing. Visualization enhances your hability to analyze your options and choose the one considering the whole context, not only your current pressures. A good way to stabilize your work model is to create a physical representation that make those options explicit. Physycal and electronic kanban boards are just perfect for this job. Another important aspect of work models stabilization is the establishment of a regular cadence of value delivery. This cadence is essential not only to make explicit your ability to reach your purpose regularly, but also to make explicit if you are getting better or worst in this game as time goes on. When we talk about cadence, we need to talk about time. Time is always the dominant parameter for knowledge work or creative work. The question is never “What should be done to reach the goal?” but always “How much time do I have to reach the goal?”. For this type of work, the iron triangle is obsolete. We commit to an objective and use the time we have to generate a scope whose purpose is to reach the goal. The scope is always output, never input. Frequency of value delivery (your process “heart beat”) is where you can evaluate the most important feedback loop of your work place. A known frequency of value delivery implies predictability and a predictable delivery process is an important indication of a healthy process. Every work process could be stabilized using these few concepts: visualize it, talk about it and persue cadence. Yes, it could be better by doing that, but you shouldn't do that only for the sake of just making it better, you should do it because you need to put your car on the right road. Few things are so wasteful as putting your car to move faster on the wrong road.

Posted by: alissonvale
Posted on: 10/14/2012 at 2:48 AM
Tags: , , , ,
Categories: Management | thoughts
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
Lean has a lot to teach for Agile practicioners. And Agile has a lot to contribute for who wants to apply Lean.Look at this enlightening post which makes this relation more clear:http://dnicolet1.tripod.com/agile/index.blog?entry_id=1874091 

Posted by: alisson.vale
Posted on: 1/16/2009 at 11:06 PM
Tags: , ,
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
Recentemente foi publicada a 3ª Edição da Revista Visão Ágil que contou com um artigo meu intitulado "Aperfeiçoamento de Projetos Ágeis - Uma Visão Sistêmica". O artigo foi dividido em duas partes. Nessa primeira parte, eu falo um pouco sobre os aspectos teóricos que circundam o processo de aperfeiçoamento contínuo que se estabelece em um projeto ágil. Na segunda parte, falarei sobre formas e modelos de aperfeiçoamento para uso na prática. Alguns trechos do artigo que acho serem importantes para discussões sobre o tema:     - Sobre o ciclo Especulação, Colaboração e Aprendizado do Jim HighSmith no contexto do auto-aperfeiçoamento.  "No contexto do aperfeiçoamento contínuo, a percepção adequada desse entendimento gira em torno de  saber que para ter um processo que seja melhor hoje do que ontem, é necessário (1) especular sobre algo que precisa ser melhorado  (2) colaborar para que tal melhoria seja alcançada e (3) aprender e incorporar a melhoria conquistada." - No fundo... "...o processo de melhoria contínua gira em torno de, dentre outras coisas, buscar melhores maneiras de (1) aumentar  a quantidade do tempo em que a equipe está envolvida com atividades que geram valor para o cliente por meio de software funcional; e (2) de aumentar a qualidade do tempo em que a equipe está envolvida com atividades que visem garantir as condições de segurança, estabilidade funcional, compreensibilidade e manutenibilidade do software que está sendo desenvolvido."      - O PDCA e seu padrão sistêmico "Em projetos ágeis, é o padrão sistêmico de adaptação e aperfeiçoamento que faz a equipe controlar o processo, evitando que o processo controle a equipe.  Entender o ciclo PDCA e identificar seu funcionamento dentro do projeto é fundamental, pois ele estabelece esse padrão sistêmico cujo resultado é a incorporação de pequenos elementos de controle sobre a complexidade do projeto. É o padrão que garantirá a sustentabilidade do projeto a longo prazo." - O entendimento da Toyota "A Toyota (...) enxerga o rendimento de um sistema (no nosso caso de um projeto) segundo uma rede complexa de influência dos chamados “elementos de avaliação primários” (...) Em seu modelo de melhoria contínua (o kaizen), toda e qualquer ação de resolução de problemas é executada por meio do entendimento de suas influências nos elementos de avaliação primários."  - A relação entre qualidade e aperfeiçoamento contínuo "A qualidade é como um fluido que deve ser colocado para lubrificar cada engrenagem do processo. Uma engrenagem sem o fluido será um potencial ponto gerador de defeitos."   Ao fim do artigo, eu tento descrever um cenário real onde o entendimento sistêmico poderia criar um diferencial na hora de se colocar em prática questões de aperfeiçoamento. Mas aí é melhor ler o artigo para saber exatamente do que esse exemplo trata.  A idéia da segunda parte desse artigo é entrar nos modelos utilizados para auto-aperfeiçoamento atualmente. Descrever práticas de retrospectiva e as práticas utilizadas pela Toyota para fazer essa roda de melhoria contínua girar a favor do projeto.   Espero que seja útil para aqueles que querem implantar um poderoso ciclo de melhoria contínua em seus projetos. 

Posted by: alisson.vale
Posted on: 1/28/2008 at 7:03 PM
Tags: , , ,
Categories: Projetos Ágeis
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
Em desenvolvimento ágil, é muito comum as equipes estabelecerem uma espécie de "comprometimento de sangue" com seus clientes em se entregar tudo que foi planejado no início de uma iteração. Pode haver muita boa vontade nisso, mas certamente é uma prática pouco eficiente. Mas porquê é ruim criar um compromisso para entregar o que foi planejado? Quando um compromisso é estabelecido, não cumpri-lo pode resultar em frustração tanto do cliente quando da equipe e de sua liderança. O que ocorre na prática é que não há garantia de que os requisitos planejados no início de uma iteração realmente poderão ser concluídos até o seu final.  Se a liderança do projeto, ou o cliente, estabelecerem uma relação de cobrança para com a equipe no que diz respeito a entrega ao fim de uma iteração dos requisitos planejados e acordados no seu início, fatores indesejáveis poderão atuar negativamente no processo, entre eles: (1) o aumento de trabalho over-time e do stress no dia-a-dia de trabalho; (2) a equipe começa a super-estimar as features com medo de assumir compromissos irreais (3) a  qualidade pode começar a ser sacrificada; (3) relaxamento na execução das práticas e (4) em um atraso iminente, a equipe começa a evitar o acionamento do cliente para obtenção de feedback (pois isso pode significar mais trabalho para ser entregue no mesmo tempo). O que fazer então? Sem metas rígidas, como gerar ritmo e obter alguma previsibilidade no projeto? O segredo é não tentar impor controle sobre o processo, mas estudá-lo e observá-lo com o intuito de se ganhar a capacidade de aperfeiçoá-lo sistemicamente. O objetivo é conquistar (e não controlar) o ritmo e a previsibilidade desejada. Se as metas de implementações para a iteração continuamente não são alcançadas, pode ser que: As metas estão sendo mal-definidas (consciente ou inconscientemente). Normalmente devido ao desconhecimento da capacidade real de produção da equipe. Às vezes tenta-se impor metas mais arrojadas para tentar puxar o ritmo da equipe, mas o resultado acaba sendo pior; Os requisitos foram insuficientemente explorados durante a reunião de planejamento. Apesar de não ser uma boa prática detalhar em excesso o que será desenvolvido, é importante conhecer o suficiente sobre o que será desenvolvido, de modo a diminuir a margem de erro nas estimativas. Isso pode ocorrer quando as reuniões de planejamento são rápidas de mais ou muito superficiais; Eventos não planejados (veja "variações especiais" mais a frente no texto) ocorreram durante a iteração diminuindo a capacidade de produção da equipe. Em todos os 3 casos, a culpa não é da equipe. Não adiantará, portanto, pressioná-la ou influenciá-la para produzir mais. Todo o projeto é um sistema. Sistemas que produzem abaixo do esperado, o fazem devido a causas sistêmicas, não pela existência de um ou mais "culpados".  Todo o sistema tem um rendimento e esse rendimento, segundo Deming, sofrerá de variações causadas por causas comuns ou por causas especiais. Especialmente quando falamos em projetos de software, há variações inerentes ao sistema e há variações especiais  que tornam seu rendimento imprevisível, mas controlável. O ato de medir esse rendimento continuamente gera o controle estatístico necessário para nos dar a condição de prever resultados com muito mais acuracidade do que os planejamentos adivinhatórios e impositivos que estamos acostumados a  ver. Assim, as expectativas devem ser trabalhadas com base em medições e não com base em compromissos irreais.    Durante o estudo e a observação do sistema da qual faz parte o projeto, será possível detectar variações especiais, removê-las e, assim, otimizar seu rendimento. Quando todas as variações especiais forem removidas, o sistema poderá ser otimizado como um todo e, aí sim, haverá uma melhoria substancial na sua capacidade de avançar com mais velocidade, mantendo o alto nível de qualidade desejado.  Um projeto observado e aperfeiçoado com uma visão sistêmica pode oferecer muito mais controle e previsibilidade do que um projeto gerenciado com metas impostas de cima para baixo. 

Posted by: alisson.vale
Posted on: 10/26/2007 at 1:42 AM
Tags: , , , , ,
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (2) | Post RSSRSS comment feed