Por que prefiro quadros físicos?

A pergunta é pertinente e me pego frequentemente explicando estes motivos. Então nada mais justo que surgir uma "curtinha" no blog. É óbvio que o quadro eletrônico tem suas vantagens, como facilidade para times distribuídos e geração automática de gráficos complicados, como um CFD, mas na minha experiência, sempre que possível, opte pelo físico. Por que?

1. Normalmente é mais barato. Até softwares gratuitos exigem um servidor, backup de dados, etc.;
2. Mais fácil de usar que um software, particularmente por pessoas menos técnicas e por aquelas que estão envolvidas esporadicamente;
3. Mais fácil de customizar. Escreva nele, adicione um post-it, adicione outros tipos de adesivos, etc. e pronto. A maioria dos pacotes de software são menos flexíveis ou necessitam de customização da empresa que fornece;
4. Mais visível. Um quadro em uma área comum é algo que as pessoas vêem todos os dias e o dia todo. Isso reforça as tarefas em andamento, comunica o processo e impressiona até quem está fora do time. Com isso, torna as dores mais visíveis e ajuda na argumentação para resolve-las. Age como um ponto focal - um campo de batalha do time, onde podem as pessoas podem se reunir e discutir possíveis problemas e riscos;
5. Um ponto menor, mas a maioria das pessoas gostam da satisfação do tato de mover o post-it de uma coluna para outra e da criatividade em desenhar figuras e símbolos para mostrar o status ou impedimentos, em vez de apenas olhar para colunas de texto;
6. Mesmo que optássemos por uma TV, para demonstrarmos toda as informações disponíveis em alguns quadros físicos, precisaríamos de pelo menos 4 TVs - uma para o fluxo principal, uma para o fluxo de issues da daily, uma para o fluxo das retrospectivas e uma para os gráficos.

Os quadros de vários projetos onde atuo como consultor são muito ricos e com a passagem destes quadros para o meio eletrônico perderíamos muita informação.

Bem, é isso. E você? Prefere o eletrônico? Por que?

Transição - Como buscar uma boa reunião diária?

Em uma transição, é natural esperarmos diversos níveis de maturidade nas cerimônias e modus operandi de times diferentes. Uns estão mais maduros, outros menos. Dessa forma, compilei aqui alguns pontos de atenção que identifiquei em times ágeis em transição, em vários níveis de maturidade.

Especialistas não servem para transição

O Kanban parece estar se direcionando para outra estrada que considero perigosa: os níveis de maturidade/profundidade no sistema. O perigo nessa abordagem reside, na minha visão, na facilitação para o aparecimento do xiitismo, além de ter pouca eficiencia. Mas isso é assunto para outro dia.

É interessante termos especialistas, como sempre foi interessante em todas as áreas e em todos os tempos. O problema é que esse tipo de mindset simplesmente não serve para uma transição. Disso estou convencido.

Vamos inicialmente deixar claro quem estou chamando de generalistas, especialistas e o que é essa transição.

• Generalistas: Pessoas que conhecem diversos métodos/sistemas/processos/frameworks para desenvolvimento de software ágil, saindo do waterfall que teve a sua importância na sua época, mas que hoje é reconhecidamente ultrapassado e ineficiente;
• Especialistas: Pessoas que conhecem apenas um método/sistema/processo/framework para desenvolvimento de software ágil;
• Transição: Processo onde uma empresa quer mudar do waterfall para outra forma mais eficiente de desenvolvimento de softwares, comumente próximo do Lean.

Quando começo um trabalho de change agent em uma empresa, um dos maiores princípios da abordagem dos sistemas complexos, norteia as minhas ações: observar como o sistema se comporta para então sugerir mudanças. Esse "detalhe" é tão importante que pode significar o sucesso ou o fracasso de uma transição. Precisamos entender que o sistema está acostumado a se comportar daquela forma. As pessoas estão acostumadas a se comportarem daquela forma. Uma ruptura imediata, vai gerar stress no sistema. Uma transição já gera stress demasiado e não precisamos de change agents gerando mais stress. Na verdade, o papel dessa figura é justamente aliviar a tensão que toda a mudança naturalmente gera. 

O sistema é elástico, está sofrendo tensão e está ansioso para voltar ao seu estado inicial. Se tentarmos gerar uma ruptura logo de início, vamos obter como resposta uma resistência (natural) e a tendencia é de tudo voltar a ser como era antes. Entretanto, se tentarmos a abordagem do sapo fervido, temos uma chance muito maior de que a ruptura aconteça sem o sistema perceber. E o melhor: com as pessoas que antes eram resistentes, vendendo as novas idéias como se fossem delas.

Isso quer dizer que não precisamos mais de especialistas no mundo? Não, precisamos de especialistas. Mas especialistas não podem atuar como change agents. Os especialistas não terão independência suficiente das suas especialidades para se afastar do sistema (como nos afastamos de um desenho ou quadro) e buscar a melhor opção. Em uma transição, os generalistas chegam primeiro e os especialistas depois.

Entretanto, neste contexto, os generalistas precisam ser especialistas em uma área de atuação: o pensamento sistêmico e sua derivação, os sistemas complexos. Esse cara precisa saber como analisar o comportamento do sistema e que tipo de mudança será mais eficiente e gerará menos impacto. A consolidação dessas pequenas mudanças e, principalmente, os seus resultados, serão responsáveis por fortalecer o processo de transição e dará aos responsáveis estratégicos da empresa a percepção de que esse processo está indo no caminho certo.

Estou convencido que esse mindset contribui sobremaneira para a implantação dos princípios do Lean, com uma cadência adequada ao contexto, sem rupturas bruscas que poderiam levar uma grande empresa a falência.

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.

Que tipo de profissionais de TI as empresas de sucesso contratam?

Esse texto é de autoria da minha amiga Annelise Gripp, ScrumMaster na globo.com, e fala sobre como as empresas 2.0 contratam. Ela escreveu tão bem sobre isso na RioAgile que pedi um texto para publicar:

"Estou no mundo de TI desde 1994, quando usavamos o famoso XT. Nessa época, me lembro bem, que as empresas não se preocupavam com o comportamento dos desenvolvedores. O importante era ser técnico, programar em alguma linguagem (cobol, basic) e entregar no prazo. Não era levado em consideração seus aspectos comportamentais ou seu conhecimento sobre o produto. As pessoas mau se olhavam e cumprimentavam. Pois bem, passamos decadas com esse tipo de profissional e acreditem, eles ainda existem na maioria das empresas....

Reparem se as empresas que mantem esse tipo de funcionário, obtem sucesso no mercado da tecnologia. Com certeza a sua resposta será NÃO!

Partindo dessa análise, posso confirmar pra vocês que o fator de sucesso de grandes empresas como a Globo.com estão nas pessoas. Pessoas que além de ter um vasto conhecimento técnico possuem aspectos comportamentais de grande valor como: boa comunicação, boa integração, trabalham bem em equipe, adquirem e repassam conhecimentos e experiências, participam de cursos e palestras, enfim, pessoas que se socializam, que compartilham para conquistar.

Logo, o processo de contratação de um novo desenvolvedor, que eu faço com o time, consiste em 3 etapas: na primeira etapa, fazemos uma entrevista por skype (voz e vídeo). Perguntamos sobre a vida profissional, conhecimentos e experiencias. Depois passamos uns exercícios de lógica que o desenvolvedor pode fazer em qualquer linguagem. Essa primeira etapa leva mais ou menos 1h e 30 minutos. O candidato só vai para a segunda etapa, caso tenha passado pela primeira. A segunda etapa consiste em avaliar o conhecimento do desenvolvedor para aquela vaga especifica. Um exemplo: se temos uma vaga para desenvolvedor client-side, enviamos para o candidato um exercício com foco em client. Se for uma vaga para server-side, enviamos para o candidato um exercício com foco em server. O candidato tem 24 horas para retornar por email os exercicios prontos. O próprio time constroi e avalia o exercício do candidato. Caso o candidato tenha passado nos exercícios, nós convidamos e pagamos a passagem do candidato para passar 1 dia conosco. Ele chega de manhã, participa do daily meeting, pega tarefas para fazer com o time e retorna para casa no fim do dia. Damos o resultado logo depois.

Profissionais que passam por esse processo com sucesso são contratados, pois eles trazem dinamismo e criatividade para a organização. O trabalho flui com naturalidade e o ambiente se torna seguro, colaborativo, para ele e para o time. Surgem novos produtos, novas propostas, novas tecnologias, satisfação e orgulho de fazer parte daquela empresa.

O trabalho de um lider coach ou de um scrum master é captar esses profissionais no mercado, desenvolver as pessoas que integram o seu time, nos dois aspectos, tecnico e comportamental. É fazer com que pessoas com personalidades diferentes, trabalhem juntas para alcançar uma única meta. Logo, se encontramos profissionais com potencial no mercado, contratamos imediatamente e integramos a equipe."

Obrigado Anne!

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.

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!

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.

Do que chamar o Scrum?

Hoje lendo o scrum-brasil fórum da scrum-brasil hoje, me deparei com uma mensagem que me chamou a atenção.

O assunto principal, é como chamar o Scrum. Eu respondi por lá, mas parece que moderaram a minha resposta. Fica difícil saber a verdade, mas como eu tenho meu espaço, vou colocar aqui a minha resposta, e quem quiser discutir de forma sadia, fique a vontade. Uma rapidinha sobre como chamar o Scrum.

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.

Maré de Agilidade - Pantanal - Meus 2 Cents

Neste post vou colocar meu ponto de vista sobre o Maré de Agilidade edição Pantanal. Vou abordar também todo o ecossistema deste evento que, graças ao pessoal da Jera Software Ágil, tive o prazer de olhar mais de perto. Obviamente, o objetivo deste post não é detalhar o conteúdo, mas mostrar como pode ser bom para vida pessoal e profissional participar de eventos deste tipo.

O PM-83 da Caelum com Mauricio Aniche

Neste post colocarei as minhas impressões sobre o excelente PM-83, ministrado pelo Mauricio Aniche na Caelum RJ, assim como o impacto nos meus colegas de trabalho que representou cerca de 50% da turma. No fim do post sugiro uma melhoria que considero importante.

What Killed Waterfall Could Kill Agile - Meus 2 cents

O Robert Martin, conhecido como Uncle Bob, escreveu um artigo interessante e  aderente ao momento que estamos vivendo, principalmente após a saída do Tobias Mayer da Scrum Alliance.

Guilherme Silveira: Deploy Contínuo

Nesta apresentação, o Guilherme Silveira mostrou como apenas a integração contínua não basta, sendo necessário também o deploy contínuo de valor para o cliente. Obviamente, existem tarefas complexas e que demandam tempo. O lema do Guilherme para estas situações é: "é manual, chato, repetitivo e sujeito a falha humana, então automatiza".

Leandro Ângelo: Ágil: Previsibilidade & CMMi, como ficam?

Pedro Valente: Product Owner na prática

Carlos Barbieri e Isabela Fonseca: MPS.BR com metodologias ágeis

Manoel Pimentel: Coaching e Facilitação de Equipes Ágeis