Transição - A cultura da liberdade

Todos os times, absolutamente todos, onde eu trabalhei a transição do modelo tradicional para o modelo ágil, se prenderam bastante na tal liberdade que os métodos ágeis prega para os trabalhadores do conhecimento. É comum você ouvir: não quero trabalhar neste work item, prefiro este. Estamos atrasados, mas isso não é problema meu.

Outra base para a teoria contrária a relação Lei de Little x Limited WiP

Analisando os contextos onde estou inserido nos dias atuais e onde trabalhei no passado tentando a transição para o modelo ágil, falhando, tendo sucesso, me deparei com mais um fato que justifica a teoria de que a lei de Little não serve como embasamento para a relação WiP limitado X Lead Time. Já disse isso outras vezes, mas não custa repetir: Eu não tenho dúvidas que manter o WiP limitado e uma política rígida coibindo o estouro deste limite e fomentando a colaboração vai reduzir o seu lead time. Mas mais uma vez: não vejo lógica em usar uma equação matemática que foi provada por negação usada como base para essa verdade.

A Little's Law, O Kanban e os Sistemas Complexos

Já venho discutindo e analisando esse assunto a pelo menos dois meses. Quando eu me detive um pouco mais para entender a Lei de Little percebi pelo menos duas coisas: é perigoso nos basearmos tanto em algo que foi provado por negação - não ser verificado nenhum caso onde a lei não se aplica; e sua adoção em sistemas complexos e, consequentemente, para justificar algumas práticas do Kanban, é questionável. Pelo menos eu estou questionando.

Rapidinha - Será que você sabe o que é um silo?

Hoje vi algo que me deixou preocupado. Em uma comunidade que fala de agilidade, vi o assunto silo surgir de uma forma estranha. Silos em nada se parece com divisão de frentes de trabalho. Silos não se comunicam, silos são isolados. Divisão em frentes de trabalho é uma forma de lidar com a complexidade: descentralização.

Quando estamos lidando com sistemas complexos, quanto mais centralizamos decisões e ações, caminhamos a passos largos para o caos. Da mesma forma, se você acredita que ser multidisciplinar é ter um bolo de atividades e um bolo de pessoas "puxando", você também me parece caminhar a passos largos para o caos.

Multidisciplinaridade pode (e deve) acontecer com frentes de trabalho. Trazendo um pouco dos conceitos do Kanban para este post, se temos um limite ideal do work-in-progress, alguém ficou ocioso e não pode puxar mais nenhuma atividade, esse alguém vai ajudar na etapa do processo onde o gargalo apareceu. Essa técnica também tem um pé na teoria das restrições:

1. Identify the system's constraint(s) (that which prevents the organization from obtaining more of the goal in a unit of time)
2. Decide how to exploit the system's constraint(s) (how to get the most out of the constraint)
3. Subordinate everything else to the above decision (align the whole system or organization to support the decision made above)
4. Elevate the system's constraint(s) (make other major changes needed to increase the constraint's capacity)
5. Warning! If in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system's constraint.

Descentralizar, atuando em várias frentes, é uma forma de lidar com a complexidade e não de formar silos. Os silos são "entidades" isoladas. Cuidado com as crenças limitantes. O conceito depende de contexto. Cuidado com os sempres e nuncas, mesmo implícitos.

Como eu prometi, esse post seria uma rapidinha. Discussões serão muito bem vindas nos comentários.

Até a próxima.

O Poder da Iteração

Depois de um pouco mais de um ano com o meu cliente que trabalha com gerenciamento de risco, rastreamento de frotas por GPS, estou aos poucos conseguindo demonstrar o poder do desenvolvimento iterativo. Neste sistema estamos, gradualmente, aumentando o nosso amadurecimento nos processos ágeis. Sim, não adianta apenas uma pessoa ser experiente em determinado assunto. O que importa é o time. O todo não é a soma das partes, mas a soma da interação entre elas.

[Resenha] Using Kanban to Turn Around Distressed Projects

O autor deste artigo, Steve Andrews, abordou um assunto que me interessa bastante: transição ágil. Neste post vou colocar os meus comentários sobre os pontos que achei interessante e vou terminar com uma observação que julgo importante, mas que aparentemente foi excluida pelo autor do artigo, depois que fiz o comentário no site.

Consultoria Ágil

Amanhã nossa empresa iniciará mais um trabalho de consultoria ágil em um cliente. Durante o contato inicial, o cliente informou que pretende tocar um projeto novo observando os princípios da XP. Isso foi uma boa notícia. Adicionalmente, vou sugerir o Kanban como sistema de melhoria contínua do processo da empresa.

A idéia central deste trabalho é:

1. Coach com um dos donos, alinhando expectativas. A principio esta pessoa será o gerente deste projeto (Gestão 3.0);
2. Explicar o que é e como aplicar o Gerenciamento 3.0;
3. Mentoring em XP;
4. Mentoring em Kanban e Lean;
5. Auxilizar na análise e acompanhamento do lead time;
6. Respeito as pessoas;
7. Oberservação e ação nos estágios de Tuckman para formação de times ágeis;
8. Mentoring na formação dos times, com possível aplicação de técnicas AgileMMA;
9. Análise do valor;
10. Análise e mapeamento do fluxo de valor;
11. Mentoring em definição de metas;
12. Motivação intrinseca;
13. Débito técnico;
14. Princípios importantes do desenvolvimento de software, principalmente SOLID e DDD (possivel treinamento);

Conforme esse trabalho caminhar, vou colocando aqui o que for relevante.

E a Analise de Pontos de Função?

Como eu repito normalmente, APF para mim é uma forma pseudo-científica que tenta uma conciliação entre os envolvidos para algo incerto parecer que pode ser certo.

Resumindo: para mim, falha ao tentar resolver um problema, o da metrificação. Em vez de lidar com a incerteza da complexidade, tentar simplificar o que é complexo.

E a definição de pronto?

Vamos relembrar alguns conceitos básicos do desenvolvimento de software? Na verdade o conceito mais básico.

A definição de pronto está estritamente ligada, em sua maior parte, ao que significa pronto para o cliente. Ter ou não alguns artefatos, documentação, evidencias, robustez, etc. Esta definição está relacionada ao contexto. Só existe um princípio que é obrigatório para qualquer definição de pronto e, por ele estar normalmente subentendido pela lógica, as pessoas normalmente nem o colocam em discussão: é o princípio da correção. Eu nunca pensei que pudesse ter problemas com isso, mas fui surpreendido.

Bem, como meu objetivo nunca é a caça às bruxas e trabalho simultaneamente em alguns projetos pessoais, além do meu emprego, contar isso aqui não vai revelar a identidade das pessoas. Só os envolvidos saberão que estou me referindo a eles.

Vamos dizer que eu tenho um projeto onde eu tenho um backlog atual de 30 funcionalidades. Estas funcionalidades estão, em sua maioria, divididas em 3 tarefas: recuperar dados, gravar dados e gerar um arquivo CSV.

É necessário entender que, para atingir o princípio básico (higiênico) da correção, precisamos garantir a correção das 3 subtarefas. Se existe um problema na geração dos arquivos CSV, a funcionalidade não está pronta. Não interessa se você chama a funcionalidade de tarefa, estoria, papelzinho ou de qualquer outro nome. Para mover de building para built é necessário que o princípio da correção tenha sido atendido. É o mínimo.

Percebi que o board estava com muitas funcionalidades na coluna "built". Fui tentar entender o que estava acontecendo e lembrei que estávamos trabalhando com one piece flow e que precisávamos fazer fluir aquela coluna. Grande foi a minha surpresa quando descobri que as funcionalidades estavam em built, mas que ainda havia um "probleminha" na geração do CSV. Tentei explicar por alguns minutos que isso não existe, pois para estar em built a funcionalidade precisa estar errrrrr built.

Sem sucesso. Como sou responsável pela revisão do código, falei que começaria a revisão e que, como estávamos com um "probleminha" na geração do CSV, eu rejeitaria e devolveria as funcionalidades. Recebi como resposta: não não, você não pode revisar agora (!?). Eu já sabia que surgiria uma pérola dessa.

Então para provocar ainda mais, falei que iria pular a revisão e liberar as funcionalidades para o tester verificar se estava OK. Também recebi um "não não, só pode envolver o tester na semana que vem" (!!??). Tentei por mais um tempo mostrar que os princípios estavam errados, que estavam usando o quadro para controlar funcionalidades, mas ainda com a cultura waterfall. Em built tem uma "represa". Sem sucesso. Fui descobrir como tratarão este erro no futuro e descobri que criaram uma atividade chamada "Acertar arquivo CSV" (!!!???).

Isso é débito técnico, e dos piores, pois não diz respeito "apenas" a qualidade da funciolidade, mas diz respeito a um princípio higiênico, o da correção. Enfim, recebi seguidos "não concordo", com argumentos que, para mim, não fizeram o menor sentido.

Na maior observação que já tive que fazer do princípio do Lean "Respect for People", resolvi então deixar correr. Posso estar errado, mas decidi deixar o barco tentar navegar e ver o que vai acontecer. Vou rastrear quaisquer problemas para essa decisão duvidosa do time. Chamei o tester e expliquei a situação (ele também achou um absurdo algo estar em "construido" sem estar de fato construido) e pedi para esperar um pouco.

EDIT:
Como sou chato, devo voltar nesse assunto mais algumas vezes nos próximos dias.

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.

Kanban - O que é o WiP e por que limita-lo?

As pessoas que trabalham comigo já conhecem este texto, pois enviei em um email para o time. Como não falei nada específico da empresa e do cliente e, na verdade, o que fiz foi apresentar conceitos, decidi extender para a comunidade.

Como ser ágil em um ambiente cascata?

Em primeiro lugar, gostaria de pedir desculpas aos meus leitores, pois há muito não coloco um conteúdo mais técnico e tenho falado muito em processos, sistemas, gerenciamento e assuntos nessa linha.Vou me redimir, uma dia.

Neste post, vou informar como estamos transformando uma equipe para observar os valores da agilidade, dentro de um ambiente, até certa forma, hostil ao movimento ágil. Como os leitores mais antigos já devem desconfiar, o sistema principal escolhido foi o Kanban. Entretanto, neste contexto complexo, decidimos aplicar um conceito mais amplo, o AgileMMA, termo cunhado pelo grande pensador Manoel Pimentel.

Fevereiro de 2012 - Um marco na historia do Kanban

De fato, na minha visão, o mês de fevereiro transformou-se em um marco na vida do sistema Kanban. Infelizmente, também na minha visão, este é um marco negativo e vou contar aqui porque.

Kanban - De olho no seu processo

Demos início ao mapeamento/análise do nosso processo utilizando o sistema Kanban. Vou mostrar aqui como foi a mudança de processo e de cultura, assim como esse sistema nos ajudou a mapear e melhorar nosso processo de desenvolvimento.

Experimentando o Kanban

Nesta semana, comecei a praticar Kanban, que venho estudando há uns três/quatro meses. Meu primeiro contato com os métodos ágeis foi com a XP, e como sou muito ligado à codificação, foi amor a primeira vista. Depois da XP, tive contatos interessantes com o Scrum, comprando livros, lendo artigos e assistindo a muitas palestras por todo o país. Naturalmente, fui levado ao Lean, e li o livro Lean Thinking, de Womack e Jones, o que sacudiu a minha forma de pensar.