Lean - Respect for people

Hoje li em Implementing Lean Software Development um comentário contundente sobre a importância deste princípio, colocando-o acima de todos os outros. Em um primeiro momento, achei estranha a argumentação, pois vejo muita importância, também, em identificação do valor, mapeamento do value stream e análise deste value stream para identificação e redução de desperdícios. Mas ao refletir cuidadosamente e conforme fui avançando na leitura do capítulo seis, percebi que concordo sem restrições com o que foi proposto pelos Poppendiecks. O objetivo deste post é repercutir esta idéia e, quaisquer dúvidas e/ou idéias para somar, fiquem a vontade para postar nos comentários.

Segue o trecho retirado da primeira página do capítulo:

“Year after year, Toyota has been able to get more out of its people than its competitors have been able to get out of theirs,”[1] according to Gary Hamel. “It took Detroit more than 20 years to ferret out the radical management principle at the heart of Toyota’s capacity for relentless improvement....Only after American carmakers had exhausted every other explanation for Toyota’s success—an undervalued yen, a docile workforce, Japanese culture, superior automation—were they finally able to admit that Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.”

[1] “Management Innovation,” by Gary Hamel, Harvard Business Review, February, 2006, p. 74.

Lean is a management system that creates engaged, thinking people at every level of the organization and most particularly at the front line. If you implement all of the lean principles save one—respect for people—you will reap only a shadow of the potential advantages that lean can bring. If you implement only one principle—respect for people—you will position the people in your organization to discover and implement the remaining lean principles.

Bom, that is it.

Agile - Carta semi aberta para um amigo

Considerei a carta semi aberta porque vou ocultar a identidade da pessoa. Basicamente esse meu amigo me comparou ao Hitler nesta montagem. Interessante, mas que pecou em um conceito: Waterfall é para projetos grandes e iterações e small batches para projetos pequenos.

Segue a minha resposta que, por abordar um assunto importante, resolvi postar aqui:

Cara, não pode ser eu... não pode ser eu mesmo!

Eu não falaria o absurdo que os métodos ágeis só servem pra pequenos projetos. =)

Em primeiro lugar, os métodos ágeis, na maioria, tentam lidar diretamente com a complexidade, isto é, com ambientes onde a incerteza reina. Lembra da metáfora dos sistemas complexos? "O bater de asas de uma borboleta na China pode causar um tsunami nos EUA".

Com pequenas iterações (e pequenos lotes), os métodos ágeis tentam reduzir as previsões e o ciclo, tentando diminuir a imprevisibilidade e as incertezas. Eles te dizem para aprender com o seu ambiente e com a sua experiência.

O waterfall não existe. Esta péssima interpretação do paper do Winston Royce ( http://www.youtube.com/watch?v=X1c2--sP3o0), mesmo que tivesse embasamentos teóricos (quero ver se alguém acha um livro do tipo: "Faça waterfall e entregue mais valor" ou "Feedbacks longos são mais importantes"), se fosse metrificado, todos veriam que não funciona. O problema é que mascaram. E o fornecedor (ou consultoria) ataca as causas erradas e os clientes reclamam da coisa errada. A análise é superficial e ninguém aplica os 5 Whys do Pensamento Lean (http://en.wikipedia.org/wiki/5_Whys).

Todas as demandas estouram custo e/ou prazo e/ou qualidade. Normalmente os três. Fazem isso em benefício de um escopo fixo e assinado em contrato. Simplesmente não funciona e está provado.

Você provavelmente já voou em um avião montado sob o Pensamento Lean - http://www.youtube.com/watch?v=nhtdXOjoctI

Então small batches não é para small projects. Uma coisa não tem nada a ver com a outra.

Princípios ágeis funcionam muito bem em grandes projetos. Os princípios do Lean funcionam muito bem em grandes projetos.

Este livro fala muito de sistemas complexos e da nova escola de gerenciamento de projetos. Recomendo muito: http://www.amazon.com/Management-3-0-Developers-Developing-Addison-Wesley/dp/0321712471/ref=sr_1_1?s=books&ie=UTF8&qid=1337650739&sr=1-1

Para quem quer ter uma ideia do livro e da abordagem do Jurgen quanto aos Sistemas Complexos, aqui está o blog: http://www.management30.com/

Divirta-se!

5 Whys - Comunicação e Confiança

Vou começar a colocar aqui no blog algumas experiencias de exemplos práticos de como utilizar os "5 whys" do pensamento Lean para investigar a(s) verdadeira(s) causa(s) raiz dos problemas que possam aparecer no dia a dia.

Vamos começar com uma suposta falha de comunicação entre desenvolvedor e gerencia/liderança.

Cenário: Uma informação, necessária para uma reunião de status report, chegou até a gerencia via cliente enquanto ainda estava havendo a validação se o problema realmente era um problema. Isso aconteceu porque a reunião de status report aconteceria muito em breve.

1. Por que essa informação não foi passada pelo time? Porque ainda estava em validação.
2. Por que então foi antecipada? Porque era necessária para uma reunião inadiável de status report que aconteceria em breve e o cliente estava sendo cobrado por sua liderança/gerencia.
3. Por que uma reunião de status report, ainda mais inadiável? Porque falta confiança.
4. Por que falta confiança? Porque já aconteceram muitas releases com problemas.
5. Por que já aconteceram muitas releases com problemas? Pela ausencia de um processo mais eficiente de testes, UAT e deploy.

E assim chegamos no que realmente precisa ser repensado: processo de testes, UAT e deploy. Para que a confiança aumente e os status report com o tempo deixem de ser necessários, para que esse problema de comunicação específico não volte a ocorrer.

Os exemplos práticos que colocarei aqui são resultados da minha mente psicopata, portanto, não fazem parte do meu dia a dia. O recado é: não pare no primeiro "por que" ele pode te levar a um diagnóstico simplista demais. Medidas para remediar o primeiro "por que" podem não surtir o efeito desejado e, mesmo aplicando a inspeção, podemos estar agindo na causa errada. Errada pois por trás dela existem causas muito maiores que não estão sendo endereçadas. Daí pode estar vindo a sensação de "enxugar gelo" e de que, na verdade, as pessoas não estão se esforçando para realizar as "determinações de melhoria". Um conselho para você que acredita nisso: "Isso não é verdade! Você está tratando as causas erradas."

Pesquisa - Devo criar outro blog sobre processos, teorias, sistemas?

Desde que me posicionei definitivamente como um change agent na empresa onde trabalho, tem sido muito difícil voltar a ler livros com conteúdo técnico. Um livro sobre sistemas e processos puxa outro, que puxa outros sobre teorias (sistemas complexos, teoria das filas, teoria das restrições, etc) e meu backlog de livros técnicos vai ficando cada vez mais distante do meu momento atual.


Sei que o bom entendimento do ambiente em que vivemos é extremamente importante para um a criação de um software de qualidade. Sou contra a lei da causalidade que ainda é muito comum nas empresas: se uma aplicação tem baixa qualidade, a culpa é do desenvolvedor. O Yoshima escreveu sobre isso no blog Débito Técnico e uma de suas frases fala sobre a efemeridade deste pensamento:

Gestores dizendo que as coisas não fluem porque as pessoas não se esforçam é um diagnóstico simplista, preguiçoso e fora da realidade.

Esta frase faz parte, hoje em dia, da minha assinatura nos meus emails pessoal e profissional.

Ninguém aplica a lei dos "cinco por ques" do pensamento Lean. Normalmente param no primeiro. É mais fácil... é mais cômodo.

Assim, resolvi lançar uma pesquisa, que ficará no ar por 90 dias, para saber se vocês acham melhor eu criar outro blog para falar sobre estes assuntos (gestão moderna, sistemas de melhoria contínua, sistemas complexos, teorias, etc) ou se posso continuar escrevendo neste espaço, tendo em vista que estes assuntos também contribuem para melhorar um ambiente que é essencial para o desenvolvimento de uma aplicação de qualidade.

Votem!

Copie princípios não práticas

Práticas são dependentes de contexto. Princípios tem maior facilidade de ser transportado de um contexto para outro. Mary e Tom Poppendieck falam sobre isso em seu livro, Lean Software Development, além de ser uma questão comprovada por estudos e experiência.

Kanban - Envolvendo o cliente

Vamos continuar a série saga de como estamos trabalhando para implantar a cultura da melhoria contínua no nosso ambiente. Hoje vou mostrar como expliquei o sistema para o cliente e solicitei o seu envolvimento no nosso processo interno. Quem não quer arruma desculpa. Quem quer, procura a solução em vez de ficar de mimimi.