Toda empresa, equipe ou departamento tem uma determinada capacidade. Esta capacidade é regida pelo principal gargalo do processo. Uma montadora faz 150 carros por dia, uma gráfica faz 300 revistas por hora, um cabelereiro atende 7 pessoas em uma manhã e uma usina nuclear produz 500 MWh por hora. Dentro de cada um desses processos há um gargalo que governa essas limitações. Isso é o básico da Teoria das Restrições, que prega que para melhorar um sistema você precisa identificar a principal restrição, e após isso subordinar TODO o sistema a essa restrição até que ela seja vencida. Com isso a restrição (ou gargalo) migrará para outro ponto no processo, e todo o sistema mais uma vez se subordinará a ela. Gestores na maioria das áreas citadas neste parágrafo sabem bem essas restrições, pois elas são explicitas. Vou dar um exemplo…

Quando visitei a CVALE no ano passado, eles tinham uma planta com capacidade de abater e processar 500 mil frangos por dia. Conversando um pouco com um dos gestores da fábrica eles disseram que era uma restrição em uma parte do processo que limitava toda a fábrica nesta capacidade. Vamos montar uma situação hipotética: Um dia o presidente diz que a demanda global por frango aumentou e que amanhã a produção será 650 mil frangos. Os gestores discutem e tentam convencer o presidente que isso é impossível. O presidente irredutível sai da sala dizendo: “- Olha, já está tudo acertado. Os caminhões saem das granjas amanhã trazendo 650 mil frangos pra cá. Se preparem!”. O que vocês imaginam que iria acontecer? Eu vejo uma fila interminável de caminhões no pátio, bagunça no descarregamento, pessoas estressadas, problemas com máquinas trabalhando acima da capacidade e o gargalo rindo de tudo isso. Em 2 ou 3 dias de caos e muito prejuízo o presidente volta atrás (ou perde o cargo) e o sistema retorna ao estado anterior, dentro de suas restrições, produzindo no máximo 500 mil frangos por dia.

O parágrafo acima demonstra um presidente tentando EMPURRAR um sistema. Isso pode ocorrer em todos os tipos de negócios – de montadoras a marcenarias, de shopping centers a presídios. No trabalho do conhecimento o sistema também pode ser empurrado, E GERALMENTE É. Todas as vezes que você vê um gerente/coordenador/capataz passando trabalho para uma equipe ou pessoa, definindo um determinado escopo e PRAZO, ele está tentando empurrar o sistema. No Trabalho do Conhecimento (qualquer atividade cujo insumo maior é o raciocínio, a pesquisa ou a criatividade) é mais difícil identificar que pessoas estão trabalhando acima da sua capacidade, pois o processo todo é mental. Um engenheiro projetanto um avião não está fazendo um desenho no CAD – ele está pensando sobre aerodinâmica, peso, resistência – o desenho é a MANIFESTAÇÃO do projeto. Um romancista escrevendo uma obra não está fazendo um livro – ele está pensando na história, nos personagens, nos diálogos – o texto é a MANIFESTAÇÃO disso. Um publicitário projetando a identidade visual de uma empresa não está fazendo um logotipo – ele está pensando no conceito, na plasticidade, nas cores e no movimento – o arquivo no Photoshop é a MANIFESTAÇÃO desse design mental. Um desenvolvedor não escreve código – ele pensa em como elementos dentro do computador resolverão um problema dos usuários – o software é a MANIFESTAÇÃO do que ele pensou. No trabalho do conhecimento tudo acontece na cabeça do indivíduo. Como não é algo explícito facilmente “pessoas pensando” são interpretadas por gestores como “vagabundeando”. Por isso gestores cobram constantemente para que as tarefas sejam entregues no prazo. Isso configura um sistema empurrado no trabalho do conhecimento.

Um parêntese que preciso destacar aqui é o inóspito ambiente das Agências On-line, aquelas que geralmente criam sites institucionais, hotsites e campanhas de mídia digital além de outras coisas. Começei a ter contato com elas em 2008 (início da febre Scrum) e muitas me pediram processos que dobrassem a capacidade de entrega de projetos. Nesses ambientes é incrível como há uma completa falta de conhecimento em gestão. É comum Agências On-line terem 20, 30 ou 40 projetos simultâneos mesmo que a equipe tenha só 10 ou 15 pessoas. Horas extras, trabalho aos sábados, domingos e feriados fazem parte do dia-a-dia. Esses trabalhadores falam até com certo orgulho que “eles ralam pra cacete”. Insensatos. O diagnóstico desses ambientes é um claro problema de gestão: ELES NÃO PARAM DE VENDER mesmo sabendo que o sistema está completamente caótico e desorganizado. Eles continuam a colocar mais projetos nas equipes, afinal, “as pessoas aguentam… o mercado é assim mesmo”. Proprietários e gestores de Agências On-line e outras agências relacionadas a Marketing e Publicidade comumente possuem uma mentalidade completamente insana: eles acreditam piamente que suas empresas possuem uma capacidade infinita de produção, e assim, congestionam o sistema de trabalho, empurrando. Infelizmente esses gestores estão em um total comodismo e ironicamente se questionando porque há uma alta-rotatividade e seus clientes estão insatisfeitos. É um grande sonho meu conseguir implantar um sistema puxado nesse ambiente. É possível tornar uma Agência On-line mais produtiva, previsível e controlada através de um sistema puxado.

Pensamento Lean

É extremamente difícil falar sobre sistemas puxados sem falar um pouco sobre a base do Pensamento Lean. É ainda mais difícil falar sobre Lean em dois parágrafos. Muitas pessoas me questionam porque em 2009 me apaixonei pela cultura Lean em detrimento de outras abordagens. É bem simples: Lean não tem frescura. Lean parte dos fundamentos que toda organização deve seguir: Saber o que é VALOR para os clientes, voltar toda a empresa para produzir VALOR respeitando suas capacidades e buscar a perfeição através de melhoria contínua.

Resumindo: Uma empresa poderá perpetuar a sua existência quando resolver a formula de atender exatamente o que o cliente quer mas sempre respeitando sua capacidade de produção. O que é bem lógico, concorda? Neste aspecto um sistema puxado tem dois lados da moeda: Primeiro o cliente puxa VALOR (um produto na hora, quantidade, qualidade e preço que ele quer), e para atender isso, trabalhadores respondem a essa necessidade de acordo com a capacidade para lidar com ela. Isso é essencialmente importante para a organização de uma equipe de trabalhadores do conhecimento. Porém, precisamos saber o que é capacidade e variabilidade.

Variabilidade

O trabalho do conhecimento depende de pessoas. Pessoas são complexas. Pessoas tem seus próprios valores, suas emoções, sua mentalidade, sua experiência, seus problemas pessoais, seus interesses, seu conhecimento, suas limitações, suas baladas na noite anterior, a TPM e muitas outras coisas. Para tornar ainda mais complexo, o trabalho do conhecimento é uma atividade em equipe, então, são várias pessoas com seus valores, emoções, mentalidade, experiências… Numa equipe, em uma quarta-feira qualquer, Pedro está chateado porque o Corinthians perdeu o jogo, Joana está com uma leve enxaqueca, Luiz está super motivado querendo resolver tudo, Renata está preocupada com algumas coisas do projeto e o Júlio, o gerente dessa equipe, não sabe de nada disso, só quer que as coisas se cumpram conforme o planejado. Pessoas são inconstantes, imprevisíveis, diferentes, e na maioria das vezes, agem mais na emoção que na razão.

Além disso, temos outras variáveis que governam um sistema no trabalho do conhecimento: o processo da empresa, a complexidade do trabalho, as necessidades dos clientes, o ambiente, tudo é MUITO variado. Sempre estamos fazendo trabalhos diferentes, para mercados diferentes e problemas diferentes. É exatamente o contrário de gerenciar uma fábrica de processamento de frangos, onde a variabilidade é baixa e há uma relação conhecida entre os problemas e suas causas. Isso traz uma característica para o trabalho do conhecimento que é muito indesejada para o mundo dos negócios hoje: A IMPREVISIBILIDADE gerada pela VARIABILIDADE. Uma mesma equipe para um mesmo projeto pode ter uma produtividade MUITO variada, como exemplo, veja o quadro abaixo:

Essa é a realidade: pessoas no trabalho do conhecimento não produzem como máquinas. Essa é uma das razões do trabalho do conhecimento geralmente se categorizar como um sistema complexo no Cynefin Model. Entender variabilidade e complexidade trará uma grande epifania para gestores do trabalho do conhecimento. Suas falhas começarão a fazer sentido e eles poderão parar de se preocupar em gerenciar tarefas para se focarem em gerenciar o sistema.

É importante destacar também que o que torna as coisas interessantes no trabalho do conhecimento é exatamente a variabilidade. Ao mesmo tempo que é ruim gerenciar e planejar dentro de um sistema tão imprevisível, essa variabilidade traz algumas surpresas boas. Produtos digitais como Twitter, Facebook, Peixe Urbano entre outras são iniciativas onde o desenvolvimento de uma ideia num curto espaço de tempo geram sucessos instantâneos multi-milhonários. As relações entre capital, investimento, trabalho e ROI são completamente diferentes no trabalho do conhecimento no século XXI comparando com a mentalidade industrial do século XX.

Capacidade

Um dos experimentos que você pode fazer para entender sobre variabilidade e o impacto dela na capacidade é abrir 3 jogos de xadrez ao mesmo tempo contra o computador e o objetivo é ganhar os 3 – pense no xeque-mate como a entrega de valor a um cliente. Agora, imagine um “gerente de jogos” perguntando para você a cada 5 minutos quanto tempo demorará para cumprir a tarefa. Você acha que esta cobrança melhorará sua performance? É assim que um trabalhador do conhecimento se sente quando lhe perguntam quando um programa de computador, uma produção visual ou um projeto de design vão ficar prontos. Isso é empurrar o trabalho. E sistemicamente falando, quanto mais você empurra o trabalho MAIS eles “fazem”, porém, com menor qualidade, menor motivação e facilmente perdem o senso de objetivo (ganhar o jogo!).

O pior que pode acontecer a uma equipe tentando gerar valor é ela perder a motivação. A falta de motivação deixará as pessoas acomodadas e reativas. Elas deixarão de explorar todo seu potencial. Elas farão designs feios, campanhas ruins e programas que travam. A maior lição que temos da gestão moderna para equipes do trabalho do conhecimento é exatamente aquela mais difícil dos gestores desses ambientes engolir: pressionar a equipe tem um efeito completamente contrário ao que se espera – empurrar o trabalho fará a equipe ir mais devagar e não mais rápido. Colocar a equipe para fazer muitas coisas ao mesmo tempo também fará ela ir mais devagar. Isso também é empurrar. Um dos primeiros conselhos que dou para uma empresa é ela trabalhar com menos projetos ao mesmo tempo, com isso o foco e a fluidez na entrega de valor serão maiores. Qualquer coisa que faça o trabalho se acumular dentro do sistema configura um sistema empurrado.

Uma pergunta deve estar na sua cabeça: “Se há tanta imprevisibilidade no trabalho do conhecimento, como podemos definir a capacidade da equipe para que o sistema não se sobrecarregue?” – simples, deixe a própria equipe definir sua capacidade. Você deve estar pensando: “E se a equipe definir uma capacidade baixa por preguiça?” – bem, capacidade é uma soma de coisas que envolte também a motivação do grupo. Se as pessoas estão sem motivação o gestor deve investigar o porque disso, e não forçar elas a trabalhar. A motivação faz parte do pacote “capacidade”.

Há muitas outras coisas envolvidas na produtividade de uma equipe. Somente individuos motivados não são suficientes. Motivação sem conhecimento, sem bons relacionamentos e sem um bom processo colaborativo é completamente inútil. Temos que ter uma visão holística para gerenciar da forma correta.

Um mito comum que passa na mente de gestores no trabalho do conhecimento é que as pessoas não trabalham se não tiver alguém cobrando elas. Cobrar pode até funcionar algumas vezes, porém, não torna os trabalhadores responsáveis e não é sustentável no longo prazo. Já no sistema puxado, o trabalho está a disposição da equipe, mas as pessoas só puxam esses trabalhos para dentro do sistema quando tem capacidade para lidar com ele, com isso, a fluidez do processo é real, com todas as suas disfunções, gargalos, problemas de comunicação, falta de skills e problemas de motivação. Isso pode mostrar um retrato feio, porém, essa é a realidade. 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. Na minha experiência, na maioria das vezes o problema não é motivação. Penso que se os trabalhadores foram para a empresa pela manhã pelo salário que está sendo pago, eles possuem alguma motivação para fazer o trabalho – basta mudar o sistema. Enquanto o sistema estiver empurrado os reais problemas estarão escondidos, então, não culpe os trabalhadores! Somente permitindo o sistema trabalhar dentro da sua capacidade é que é possível aumentá-la. Geralmente vejo que problemas antes tomados como problemas de motivação das pessoas eram na verdade um gargalo fácil de solucionar. Empresas sofrem por besteiras.

Ao implementar um sistema puxado as reais falhas aparecem, gargalos ficam explícitos e essa revelação dá aos gestores condições para entender os problemas no sistema de trabalho. Com liderança participativa é possivel melhorar o sistema de forma holística – essa é a função da gestão nesses ambientes. Você gestor não gerenciará mais pessoas – seu trabalho essencialmente será liderar e não mais cobrar pelo cumprimento de tarefas. A sua habilidade para formar pessoas, melhorar a comunicação, tirar bloqueios, redesenhar processos irá melhorar continuamente a capacidade. Essa é a maneira inteligente de gerenciar o trabalho do conhecimento.

Kanban, a manifestação do sistema puxado

Para demonstrar um pouco de como isso poderia ser na prática, demonstrarei um exemplo fictício e que não é de TI (o ambiente que tenho mais experiência). Uma agência publicitária pode ter seu macro-processo composto por Atendimento, Criação e Arte Final. Meu irmão que trabalha nessa área forneceu algumas dessas informações. O que flui nesse sistema são campanhas, panfletos, anúncios, logotipos e outras coisas. Se o sistema estiver desorganizado e empurrado o Atendimento poderá estar vendendo acima da capacidade de produção da Criação, ou a Criação sobrecarregando a Arte Final. Lembre-se que sempre há um gargalo, discutir a culpa disso é bem pouco produtivo. Para normalizar o fluxo, descobrir a capacidade e implementar trabalho puxado um sistema kanban poderia ser usado:

Para brincar com esse design acesse: http://kanbansket.ch/play/MP

Essa representação é um quadro na parede com post-its representando as demandas. O mecanismo é bastante simples e visual para toda essa corrente de valor: a fila de Próximas Demandas é uma priorização de itens que ainda não estão dentro do sistema. O Atendimento “puxa” as demandas dessa fila, faz seu trabalho e deixa disponível para a Criação. A Criação “puxa” o trabalho do “Atendimento” na coluna “Pronto”, faz seu trabalho, aprova com o cliente e deixa pronto para a arte final, que “puxa”… e assim o VALOR flue nesse sistema de trabalho até o “Faturamento”.

Para manter o sistema de trabalho regulado conforme a capacidade do sistema, note tem um limite (um número no cabeçalho) em cada etapa, mostrando quantas demandas podem estar dentro dessa área do Kanban. Isso é um mecanismo para que o trabalho não se acumule dentro do sistema, evitando trabalho empurrado ou filas de demandas paradas. Eles delimitam a capacidade. Os limites vão impor que o sistema seja puxado, fazendo com que o trabalho só entre no sistema quando cada etapa tenha capacidade para lidar com ele.

A transparência do “trabalho em um quadro na parede”, com um sistema puxado e limitado pela sua capacidade tem solucionado muitos problemas de vários ambientes como o do Alberto citado no início do artigo. É bastante empolgante no meu trabalho de consultor ver equipes, antes desmotivadas, conseguindo um ganho de qualidade e capacidade logo após 2 ou 3 semanas após a implementação do sistema puxado. Juntamente com outras técnicas Kanban empresas tem conseguido melhorar muito sua capacidade de entrega de VALOR.

O trabalho do conhecimento é pensar e tomar boas decisões. Boas decisões são tomadas com serenidade, conhecimento sobre nossas limitações e um sistema estável de trabalho. Situações caóticas geram decisões desastradas. Pense nisso, gestor!

O Treinamento

Treinamento sobre Kanban é um desafio interessante. Kanban é uma abordagem sem regras, sem dogmas, sem “isso é certo/errado”, tudo em Kanban é relacionado com a observação de um sistema de trabalho e como melhorá-lo. Não há boas práticas e receitinhas de bolo. Cada ambiente é único e Kanban é o método que mais respeita isso. Com 20 participantes de empresas como IBM, Petrobrás, Globo.com, Predicta, Microsoft, Banco Itaú, Emphasys entre outras, este treinamento com o David tirou muito ruído vindo do mercado sobre o que é Kanban. Eu particularmente aproveitei as percepções diferenciadas sobre empresas e equipes do David, e pude confirmar que muitos problemas de gestão daqui do Brasil não são tão diferentes no resto do mundo. Co-autorar este treinamento com o David foi uma das experiências mais legais deste ano.

David iniciou o treinamento citando Peter Senge:

As pessoas não resistem mudar, elas resistem serem mudadas.

E logo em seguida falou uma das frases que resume a cultura Kaizen e de mudanças do Kanban. Isso ecoou no Twitter:

Você não pode lutar contra resistência emocional com argumentos lógicos.

David desmistificou muito bem uma crítica comum dos líderes da comunidade Scrum: “Kanban não muda a empresa nunca”. Uma coisa legal que rolou no treinamento foi apresentar ao David “A hora Kanban”. Isso foi só o início do treinamento…

“A hora Kanban” ou “The Flow Hour” é uma atividade prática open source que criei na Aspercom para ensinar sobre Visualização, Fluxo, Limites, Tamanho de Lotes, Kaizen e Colaboração presentes no Kanban. “A hora Kanban” é um jogo intenso e colaborativo e pode abrir a mente da sua equipe sobre a natureza de um processo de design e como aplicar Kanban nestes ambientes. Já tive relatos de alguns instrutores no mundo que já adotaram a atividade nos seus treinamentos. Se quiser saber mais e colaborar, acesse meu Github:

https://github.com/rodrigoy/The-Flow-Hour/

O David gostou muito do “Flow Hour” e ficou impressionado como os alunos evoluem rápido no aprendizado sobre Kanban com este jogo. Mais uma vez o Rodolpho Ugolini da IBM Rational me ajudou como um cliente fictício na atividade. Obrigado Rodolpho!

No restante do treinamento tivemos outros jogos, atividades e muito conteúdo vindo da vasta experiência do David aplicando Kanban em diversas equipes do mundo. É empolgante ver como Kanban tem sido largamente adotado em todo o globo e como também tem crescido aqui no Brasil.

O evento KanbanBR

A Microsoft cedeu o espaço e a excelente infra para fazermos o evento de lançamento do livro Kanban do David em português, aliás, muito bem traduzido pela Andrea Pinto. Infelizmente tivemos problemas nos Correios e na Receita Federal para que 100 livros chegassem a tempo do evento. Atualmente os livros estão sendo impressos só nos Estados Unidos, mas a partir de Janeiro já teremos gráfica aqui no BR. A burocracia e ineficiência brasileira ajudou a me constranger fazendo o primeiro evento de lançamento de um livro que não tinha o livro. Formalmente, pedimos desculpas aos participantes mais uma vez. A boa notícia é que os livros chegaram na sexta-feira e vamos postá-los para quem participou do evento ainda nessa semana.

O encontro teve a participação de aproximadamente 50 pessoas e começou com apresentações rápidas de 30 minutos no formato “slideless” – só o palestrante com canetão e flipchart. Eu, Claudio Kerber e Jorge Diz apresentamos sobre “Kanban e a Dinâmica Social”, “Minhas experiências com Kanban” e “Systems Thinking”, respectivamente. Logo após o David falou sobre Kanban e Grandes Projetos – uma verdadeira aula de gestão e controle estatístico. Leiam sobre Deming.

Gostaria de mais uma vez agradecer o David e a Microsoft por essa parceria. Tive a oportunidade de falar um pouco com David sobre meus clientes e as perspectivas para o Kanban no Brasil. No Rio, com mais tempo, o David pode visitar outras grandes empresas que estão usando Kanban (como a Petrobrás e a Globo.com) e acompanhar o que os meus amigos Rodrigo de Toledo, Alisson Vale e Juan Bernabo estão fazendo por lá. Mais uma vez o David ficou bastante impressionado com nossa pequena comunidade, e os patamares para aonde estamos levando o Kanban. Pelo Twitter, David colocou o Brazil como uma potência mundial em Kanban!

2012, o ano do Kanban no Brasil

Com todo o aprendizado que tivemos aplicando Kanban com sucesso em mais de 20 equipes de diferentes produtos e setores neste ano de 2011, a grande novidade da Aspercom para 2012 é o lançamento de turmas abertas do nosso Treinamento Kanban que rodará todo o Brasil, começando por São Paulo em Janeiro e passando por Porto Alegre, Curitiba, Rio de Janeiro, Belo Horizonte, Salvador, Campo Grande, Brasília, Recife, Manaus, Fortaleza e onde mais a comunidade quiser. Sigam a Aspercom no Twitter e fiquem ligados na nossa agenda no site para mais informações em breve!

Conheci o Roy Singham no Agile Brazil 2009 e desde então nos tornamos bons amigos e tenho auxiliado ele e outros lideres da TW sempre que posso quando o assunto é Brasil. No inicio desse mês o Roy me convidou para um café da manhã pois estaria em São Paulo, e nesse encontro tive a oportunidade de conhecer o Nathan, seu filho mais velho, pesquisador na área de sociologia, e que possui um projeto de pesquisa muito interessante sobre educação na Bolívia. O Roy me convidou para o ThoughtWorks Away Day que rolaria no final de semana, e mesmo em cima da hora, consegui liberar minha agenda. Foi uma decisão sábia aceitar esse convite.

O ThoughtWorks Away Day é um evento anual interno que acontece em cada um dos escritórios da TW no mundo. Um final de semana de bate papos, confraternização, palestras e diversão. Nessa ocasião especial aqui no Brasil teve um encontro da liderança da TW com a presença de vários diretores e CTOs, alem do Roy (chairman) e do Trevor Mather (presidente).

Logo na sexta-feira participei dessa reunião com grande parte dos lideres da TW. A reunião foi um painel sobre estratégias para a América Latina e outros assuntos sobre outros escritórios da TW no mundo. Foi a primeira vez na vida que vivenciei de perto os desafios que existem em se manter a cultura de uma grande empresa no mercado global. Sem muita preparação o Roy me pediu para passar um pouco do cenário no Brasil, e com canetão e flipchart, passei alguns números recentes do relatório da Abes, e vou confessar que alguns desses números eu mesmo desconhecia e deixaram muitos presentes surpresos:

• US$ 19 bilhões é o mercado brasileiro de software e serviços de TI
• O Governo responde por 25% do mercado
• Bancos e Indústrias somam 35%
• Desde 2004 o mercado cresce de 25% a 30% ao ano, exceto em 2009, ano que não teve crescimento algum por conta dos americanos não saberem avaliar o risco de contratos imobiliários.
• O mais interessante de tudo: Pequenas e Médias Empresas respondem por 94% do mercado.

Algumas discussões interessantes surgiram da minha breve apresentação. Guo Xiao, Managing Director da China, apontou que, por incrível que pareça, o mercado brasileiro de software e serviços é maior que o chinês (em aproximadamente 4 bilhões de dólares).

No restante da reunião foram discutidas questões fundamentais sobre o futuro da TW, tudo sempre baseado nos famosos três pilares da empresa: sustentabilidade do negocio, excelência técnica e preocupação social. Muitas empresas possuem sua visão e missão somente no papel, achei interessante como nesses dois dias os ThoughtWorkers realmente fundamentam a maioria das suas decisões nesses três pilares.

Foi um privilégio sem igual participar ativamente dessa reunião da liderança de uma empresa global de tecnologia como a TW. Tive um aprendizado enorme. Talvez muitos de vocês devem estar se questionando porque eles permitiriam que eu e mais três pessoas de fora da empresa (Ricardo da Abril, e Israel e Marcelo, lideres da comunidade Agile na Bolívia) participassem desse encontro onde tantos assuntos estratégicos foram discutidos. Foi constrangedor por alguma das partes? De jeito nenhum! Essa reunião foi um divisor de águas na minha visão sobre liderança, transparência e humildade. Mesmo entre tantos diretores, CTOs e toda a presidência da empresa todos estavam a vontade para falar, criticar e tinham todo interesse em ouvir, mesmo sendo um jovem micro-empresário latino americano como eu.

Após essa excelente e produtiva reunião tive a oportunidade de conhecer as equipes no escritório da TW no Tecnopuc. O ambiente é tudo aquilo que você pode esperar de uma empresa Agile de verdade: a sala é aberta, mesas são compartilhadas, pessoas pareando, kanbans e outros tipos de visualizações muito interessantes por todos os lados, alem de vários links diretos com os clientes nos EUA via grandes TVs LCD e Skype. Um violão, um XBox (sempre em uso!) e uma copa cheia de cuias de chimarrão complementam o pacote. Logicamente, nada disso faz a empresa ser Agile – não copiem a TW. O meu julgamento para dizer que a TW é uma empresa Agile de verdade é a dinâmica social que ví naquele lugar: o jeito que eles conversam e como rola essa interação. Tive até oportunidade de discutir tecnicamente algumas coisas e falar com as pessoas sobre os projetos – sempre em inglês – pois muitas pessoas nesse escritório são da Austrália, Alemanha, Índia, Bolívia entre outros. Particularmente fiquei muito contente quando vi que vários TWers brazucas, que vieram conversar, são ex-alunos da Aspercom ou leitores daqui do blog.

O ThoughtWorks Away Day aconteceu em Bento Gonçalves, onde pude ver um pouco mais de perto como funciona uma empresa grande e com um modelo de gestão realmente moderno. Como era de se esperar pelo pouco que conhecia da TW, lá não há hierarquias rígidas, eles prezam pela transparência, comunicação e uma forte liderança participativa. Qualquer pessoa acostumada com a gestão tradicional insana que rege a maioria das empresas do mundo pode se sentir completamente confuso nesse ambiente. Decisões são tomadas em conjunto, há muita abertura para conversa e você pode criticar livremente seus lideres. Olhando de fora e de forma rápida você se questiona se aquilo funciona. Olhando com um pouco mais de atenção você nota que na TW há uma forte motivação intrinsica no ar – a energia da inovação – são seus pares, os clientes, a diversidade cultural e o poder do ambiente formado por estar no meio de tantas pessoas criativas e livres do comando-controle. Isso é exatamente o que gostaria que meus clientes desenvolvessem.

O grande momento do Away Day aconteceu no almoço do sábado. Rae Abileah, uma ativista americana e responsável pelo movimento Code Pink, inspirou a todos nós palestrando sobre Justiça Social em todo mundo, desde o atual movimento Occupy Wall Street, passando pelas manifestações contra as Guerras do Iraque e Afeganistão (onde a exorbitância de 3 a 4 trilhões de dólares foram gastos) e os conflitos e revoluções no Oriente Médio. A Rae foi a grande estrela do encontro, com direito a uns 5 minutos de uma platéia perplexa aplaudindo de pé pelas suas apaixonadas exposições. Parabéns Rae pelo seu excelente trabalho. Se cada habitante desse planeta tivesse 1% da sua disposição teríamos cidades, estados, países e um Mundo mais igualitário.

Rae Abileah, nos trazendo de volta para o Mundo

Durante esses dois dias aprendi, troquei idéias, discuti e me inspirei em aproximadamente 120 pessoas dos Estados Unidos, Bolívia, Inglaterra, Canadá, Escócia, Índia, Austrália, Alemanha e logicamente muitos brasileiros. Talvez esse post não consiga traduzir sequer 10% das experiências que vivi ali. Definitivamente um grupo brilhante, que acredito ter a vontade e os meios para realmente revolucionar a TI no nosso mercado e no mundo.

Eu não tenho a pretensão com este post tentar explicar a ThoughtWorks, isso seria assunto para um livro. Como consultor eu visito de 3 a 6 empresas por mês analisando seus processos e sua cultura, e uma das características mais únicas que vi na TW é algo muito muito raro: CONSISTÊNCIA DE PROPÓSITO, a primeira qualidade a ser buscada no System of Profound Knowledge do Deming. Poucas empresas possuem uma visão clara, útil e empolgante. Poucas defenderiam essa visão com tanto afinco quanto a ThoughtWorks.

Campanha da Code Pink, Make ________ not War!

A Aspercom em parceria com a Microsoft traz ao Brasil com exclusividade David Anderson para o lançamento da edição em português do seu livro “Kanban – Mudanças evolucionárias de sucesso para seu negócio de tecnologia” (confira o livro em inglês na Amazon).

A melhor forma de iniciar a jornada de melhorar uma empresa é partir do processo já estabelecido, por pior que este seja! Kanban é um conjunto de práticas e técnicas oriundas do Lean e da Teoria das Restrições que levam sua empresa de TI do caos à um lugar muito melhor através da busca por mais agilidade. O objetivo do Kanban é aumentar o seu conhecimento sobre o seu ambiente de trabalho, criando um estado de melhoria contínua que transforma gradativamente seu processo sem mudanças traumáticas ou estresses desnecessários, acelerando a inovação.

Neste excelente treinamento de dois dias você irá aprender na prática e em profundidade novas abordagens de gestão e melhoria de processos que tenho escrito aqui no blog recentemente, destacando as propriedades de um Sistema Kanban como Visualizar o Processo, Limitar Trabalho em Andamento, Controlar o Fluxo, Estabelecer Políticas e Alavancar Melhorias. Se sua empresa tem dificuldades com Agile ou Scrum, este curso irá lhe oferecer novas ferramentas para lidar com ambientes complexos, na melhor forma Kaizen.

Datas: 21 e 22 de novembro das 9:00 às 18:00
Local: Hotel Quality Berrini‎ – Rua Heinrich Hertz, 14 – São Paulo (prox. D&D) – Mapa
Programa do treinamento: Acesse…
Preços e condições: contato@aspercom.com.br
Informações importantes: O treinamento será ministrado parte em português e parte em inglês. Todo participante ganhará uma cópia do livro “Kanban” em português. Desconto especial para clientes Aspercom. Vagas limitadas!

O objetivo deste artigo é falar um pouco sobre melhoria de processos e nasceu de um bate-papo muito bom com David Anderson no Twitter após a minha re-leitura recente do livro Lean Thinking de Womack e Jones.

No cenário acima, aonde você é o gerente a frente de um departamento de TI, muitas coisas estão em jogo quando você quer mudanças. Os orçamentos de TI atuais mesmo em empresas médias podem passar de milhões e cada vez mais a TI está no centro das decisões estratégicas dos negócios. Uma decisão de mudança errada pode acarretar em grandes prejuízos e quer queira quer não, as coisas da maneira que estão na TI atual “funcionam”, mas de forma traumática e com constante atrito entre todos os envolvidos.

Atualmente temos uma grande febre de empresas tentando adotar Scrum, e como o Scrum é um pacote fechado com papéis, cerimômias, artefatos, regras e até um curso de dois dias que te dá o status “master certified”, muitas empresas sonham em usar ele. O que me apavora é que para a maioria das empresas “usar Scrum” lhes parece incrivelmente fácil e assim serão “Agile”. Ledo engano. O Scrum requer profundas mudanças organizacionais, especialmente para empresas grandes. Auto-organizar um grupo multi-disciplinar de forma a entregar software funcionando em um curto espaço de tempo é totalmente diferente do que as empresas médias e grandes estão acostumadas a fazer. Geralmente o que temos nessas empresas são grandes projetos com feedback tardio, alto grau de comando-controle e grupos divididos por função entre negócio, desenvolvimento e testes. Implantar Scrum é uma excelente alternativa, porém, saiba que vai doer. Implantar Scrum significa a gestão abdicar de muitos instrumentos de controle, quebrar com a separação entre os grupos e mudar posições hierarquicas estabelecidas. Isso é Kaikaku.

Alguns autores e palestrantes atuais tem algum preconceito com palavras japonesas que vieram dos pensadores da Toyota, destacando Taiichi Ohno que batizou a grande maioria desses termos no TPS. Eu pelo contrário creio que devemos dar muito crédito à cultura Toyota. Kaikaku é uma palavra que define mudanças de processos classificadas como “melhoria radical”. Para exemplificar, como defendido por Womack e Jones na sua literatura:

“A abordagem Lean é criar verdadeiros times de produto dedicados com todo skill necessário para especificar o que é valor, definir o design, detalhar a engenharia, as compras, as ferramentas e o planejamento da produção em uma sala em um curto período de tempo usando técnicas para tomada de decisão…”

Logicamente, se sua empresa hoje não é organizada por times de produtos (como o Google, a Microsoft, a Globo.com entre outras), você terá que fazer grandes mudanças organizacionais para alcancar esse primeiro patamar de melhoria que te habilita a iniciar com o Scrum. São mudanças radicais – Kaikaku. Implantar o Scrum exige isso nesse cenário.

O Sprint do Scrum é um mecanismo interessante e bem pensado. Olhando sob as lentes Lean, o Sprint é uma janela de tempo (timebox) que um grupo unindo suas habilidades tem para gerar valor com um feedback forçado ao final (o Review). O que ocorre quando temos grupos especializados na corrente de valor (como exemplo: equipe de negócio, equipe de desenvolvimento, equipe de testes) é uma baixa inter-fertilização, geralmente causada pela procura dos culpados quando há falhas e falta de foco no objetivo. Quando você separa áreas por funções ou habilidades cada parte pensa no seu próprio umbigo e facilmente se esqueçem do objetivo maior da empresa ou do projeto.

Nesse ambiente cada área separada tem várias coisas a fazer, está fazendo várias coisas e entregou várias coisas recentemente. Há uma “passagem de bastão” entre todas as áreas, e assim, filas se formam. O negócio alimenta a fila do desenvolvimento que alimenta a fila do QA. Como nesse meio pode ter bloqueios, falhas e gargalos, hoje o QA está testando as demandas desenvolvidas na semana passada que foram levantados pelo negócio no mês passado, e tudo que entrar de novo em QA ou desenvolvimento terá que esperar. Para este artigo estou levando em consideração somente três áreas. Se sua empresa tem 4 ou 5 áreas funcionais o cenário das filas poderia ser este:

Na visão do Scrum filas e gargalos são resolvidos juntando as pessoas em um único grupo auto-organizado e usando Sprints para avaliar a saúde do sistema de tempos em tempos. Com isso o fluxo será melhorado profundamente, porém, o Scrum muda o sistema para gerar visualização dos problemas e isso exige um Kaikaku (melhoria/mudança radical). A questão não é se isso funciona ou não. A questão é se sua empresa quer e suporta isso ou não. Felizmente se ela não quiser fazer este Kaikaku há alternativas.

Kaizen é a palavra Lean para indicar mudanças de melhoria menores e contínuas. Ao contrário do Kaikaku, Kaizen não é tão traumático, é melhor aceito por todos (gerentes inclusive) e mais simples de implementar. Tudo a nossa volta está suscetível a um evento Kaizen. Kaizen simplesmente significa mudança para melhor.

Filas são um grande problema para a gestão, e acho realmente incrível na minha experiência de mercado, que são poucos os gestores que sabem ou ligam para o mal que elas representam. Gestores muitas vezes querem controlar as filas e não eliminá-las. Filas retardam mecanismos de feedback, aumentam o lead time, geram atrasos, pioram a comunicação, criam expectativas irracionais, tornam um sistema de trabalho imprevisível, causam alienação nos grupos e mais dezenas de outras coisas ruins. Se você quer que o trabalho flua mais rápido, com mais qualidade e entregando mais valor, inicialmente, aponte todas as suas armas para as filas e não para as hierarquias ou para a separação das áreas. É licito acabar com as filas usando Scrum, porém, em diversos cenários, isso não convém. Algumas empresas não estão dispostas a pagar o Kaikaku inicial do Scrum. Se quer melhorar sem Kaikaku, use Kaizen.

Na abordagem Kanban, a cultura é Kaizen: inicialmente focamos esforços em compreender o ambiente de trabalho antes de mudá-lo. Se filas, bloqueios, gargalos ou alienação entre áreas estão nos prejudicando, primeiro, vamos visualizar isso, convencer o grupo dos problemas e usar Kaizen para a melhoria do ambiente com pequenas mudanças incrementais e constantes. Isso irá fortalecer a cultura da empresa, pois ela compreenderá suas falhas com provas palpáveis que serão a motivação para as mudanças.

O primeiro passo em direção ao Kanban é usar um quadro físico que mapeia como os lotes fluem pela empresa, tornando a bagunça explícita usando uma prática Lean chamada gestão visual (também conhecida como transparência, algo também presente no Scrum). As melhorias que tenho experimentado com esse simples primeiro passo do Kanban em algumas empresas são muito interessantes. A partir do momento que os grupos mesmo que separados começam a visualizar as filas, a quantidade enorme de trabalho em progresso (iniciado mas não terminado), os bloqueios, os gargalos, os desperdícios e as enormes falhas de comunicação comuns nos nossos ambientes de TI, a auto-organização emerge e as mudanças começam a acontecem, mesmo que sejam pequenas melhorias. O fato dos problemas estarem no quadro e o fluxo ser buscado por todos, a tomada de decisões sobre os problemas se tornam impessoais e concentradas. Todos buscam o fluxo e a entrega de valor, e com isso, muitas discussões sobre a culpa das falhas caem por terra. Kaizen: mudança para melhor de forma constante.

O que tem me atraído muito ao Kanban é exatamente essa variedade de soluções práticas que florecem das equipes quando nenhum método específico lhes é imposto. Dentro do Kanban equipes criam do nada soluções sob medida para seus ambientes usando Kaizen, coisas que não constam em livros e lhes atendem perfeitamente. Ora, se sempre estamos por aí dizendo que cada ambiente de desenvolvimento de software é único, porque se limitar a uma única maneira de fazer as coisas ou aos livros? A transição para um lugar melhor é mais interessante que o lugar melhor em si. Acho que isso é o que falta ao Agile. Já vi equipes criando práticas exóticas de teste, estabelecendo mecanismos divertidos de auto-organização, criando gameficação, promovendo reunião diária de 25 minutos que substituem o planning e solucionando questões de comunicação e priorização para times compartilhados (como infra ou teste) que me fazem questionar se times multi-disciplinares são realmente economicamente viáveis para qualquer ambiente. Não ter um método com regras é exatamente o que faz essas equipes se adaptarem a qualquer ambiente ou problema. As simples práticas do Kanban favorecem isso.

Uma grande discussão começou entre as comunidades Scrum e Kanban sobre as diferenças e a eficácia dos dois métodos sempre pensando na estrutura dos dois processos, coisas sem muita importância como a presença ou não de time-boxes. Como tenho escrito aqui no blog experiências próprias em campo com o uso das duas abordagens, digo que o uso de uma ou de outra é ditada pela vontade da empresa e da gestão dela em usar Kaikaku ou Kaizen e não tem qualquer relação com o ambiente dela. Porém, o fato que tenho observado é que em grandes empresas Kaikaku e rupturas organizacionais estão muitas vezes fora de cogitação. Nesses ambientes teremos um crescimento grande da abordagem Kanban. Se há uma maneira hoje de levar agilidade a bancos, seguradoras, grandes indústrias, telecoms e o governo, minha aposta é Kaizen e Kanban.

Terça-feira

O evento começou para mim na terça-feira. Estavam rolando vários cursos de certificação Scrum e o curso sobre Lean Thinking com o Christopher Thompson. Assisti de penetra o curso do Thompson por uns 30 minutos e gostei muito do conteúdo e da abordagem dele. O livro com o mesmo nome do curso (de James P. Womack e Daniel T. Jones) é leitura obrigatória para praticantes Scrum e Kanban. Um pouco de conceitos (o porque) são importantes. Eventualmente você compreenderá que o papel do PO exige características de super-homem.

Ainda na terça um jantar num excelente restaurante uniu palestrantes e organizadores na maior mesa de refeição que já vi. Tive uma rica oportunidade de conversar por umas 2 horas com o Joshua Kerievsky sobre mercado, produtos e Lean Startup. Neste jantar também conversei com mais um autor do Manifesto Ágil: Jim Highsmith.

Quarta-feira

Na quarta-feira começou o evento principal com a palestra do Jim Highsmith. Agora contratado pela Thoughtworks, Jim está evangelizando Agile para CEOs, CIOs, Gerentes e etc em grandes empresas do mundo. Um trabalho realmente empolgante. No seu discurso Jim comentou sobre práticas e agilidade nos niveis do time, do middle-management e do top-management. A mensagem geral foi sobre líderes adaptativos e agilidade escalando para todo ambiente corporativo. A palestra dele confirmou alguns conceitos que falei na minha palestra sobre a participação importante dos gerentes numa transição Agile, algo que tenho experimentado nos meus trabalhos de consultoria.

Jim e o Agile Triangle

Logo após o Keynote participei do Workshop “Da visão a produção – Criando produtos e lançando ao mercado” com o Daniel Wild. O Daniel falou sobre diversos assuntos, mas, resumindo: Lean Startup. Ele nos desafiou durante o Workshop a montar um Canvas e colocar um MVP no ar até sexta. No nosso grupo formado por Paulo Fernandes, Hélio Medeiros, Rafael Carvalho, Diogo Santos, entre outros, discutimos sobre uma forma de avaliar a qualidade das ofertas de sites de compras coletivas: Nasceu o Peixe Puto. O que mais me chamou atenção dessa dinâmica foi a maturidade dos participantes do meu grupo com conceitos de Lean Startup. Como era um evento sobre Agile esperava que a conversa rodaria sobre Visão, Backlogs, Stories porém os termos foram Canvas, MVP, hipótese, monetização e etc…

Na tarde da quarta feira entreguei meu Lightning Talk sobre Systems Thinking (Pensamento Sistêmico) com uma presença grande do público. Lightning Talks são implacáveis: 10 minutos para expor um assunto e os que eu escolhi foram bem duros de timeboxear. Os pontos que cobri foram conceitos de sistemas complexos, o desperdício com otimizações locais e as relações com Lean.

O resto da tarde trabalhamos no Peixe Puto. Foi muito interessante e colaborativo. O local do evento tinha um espaço com poltronas, puffes e mesinhas para o pessoal parear. O lugar perfeito para o Gemba do Peixe Puto. Infelizmente o WIFI não estava aceitando de jeito nenhum computadores Linux e SSH/HTTPS. Isso atrapalhou e infelizmente não conseguimos colocar nada interessante no ar, mas o mais importante nós tivemos: aprendizado e aplicação prática dos conceitos Lean Startup. Melhor que ficar jogando Kinect nos breaks.

Equipe reunida e batendo papo

Quinta-feira

A manhã da quinta começou com o Keynote do Joshua “Prioritizing Happiness” onde ele falou bastante sobre a história da Industrial Logic e todo seu aprendizado no processo. Sugiro que você veja os interessantes “albuns” sobre práticas ágeis que existem no site deles para você e sua equipe. No seu talk ele falou sobre como tornar um ecosistema (você, seus desenvolvedores, seus clientes e o cliente do seu cliente) mais feliz. Mais uma palestra recheada de conceitos Lean Startup, incluindo Fake Features e Lean UX. Joshua declarou que uma grande evolução esté vindo sobre o Agile: Lean Startup e Lean UX.

Josha Ketrievski, Industrial Logic

Logo após assisti a palestra do Rodolpho Ugolini da IBM. Ele apresentou sobre “Design Up-front (na dose certa) pode fazer bem para o seu projeto”, um assunto difícil de falar em eventos de agilidade. Espero que ele possa liberar os slides em algum lugar, pois lá tem muito conteúdo legal (principalmente sobre a indicação de literaturas sobre o assunto desde 1960 até os dias atuais). A mensagem geral foi “não use o mesmo ferramental para toda e qualquer situação”. Assim como eu, o Rodolpho tem “Agilidade com viés de RUP/UML”, isso geralmente significa experiência além da web e apreço pela obras do Jacobson, Booch, Rumbaught e Kruchten. Acredite, geralmente os projetos de design mais complexos estão fora da web e o Rodolpho mostrou autoridade sobre o assunto.

Ainda na manhã assisti a palestra “O Grandiosismo dos Loucos” com o Guilherme Silveira e Cecília Fernandes ambos da Caelum. Na minha opinião foi uma das melhores do evento pois juntaram conteúdo, crítica, humor e a opinião dos participantes. Basicamente eles exploraram alguns blog posts “sem noção” de “celebridades” Agile como Robert Martin, Ken Schwaber e Michael Feathers. O talk foi especialmente relevante porque questionou pessoas que costumam ser inquestionáveis, principalmente quando tudo nessa vida parece ser movido por interesses econômicos e não ciência. Eu especialmente tenho questionado a comunidade Scrum (com direito a discussão ferrenha com Ron Jeffries e Alistair Cockburn no Twitter) se ela tem lido os livros sobre Lean/Kanban e tentado aplicar os conceitos antes de criticar.

Na tarde entreguei o LT “Números que importam: métricas Lean”. Infelizmente não gerenciei bem o tempo e tive que fazer o talk em duas parcelas com direito a muita trollagem do Bruno Pedroso, Daniel Wildt, Manoel Pimentel entre outros (vai ter volta). No talk falei sobre alguns conceitos não conhecidos pela comunidade ágil como cumulative flows, variabilidade, análise de lead-time e principalmente a postura da gestão sobre essas métricas. Um gestor deve questionar “O que eu devo fazer para melhorar o sistema?” e não colocar a responsabilidade toda para o time. Métricas observam o sistema, não controlam ele. “Quando uma métrica se torna uma meta ela deixa de ser uma boa métrica” (Marilyn Strathern).

Sexta-feira

A sexta-feira começou quente. Vinicius Teles, um dos pioneiros XP aqui no Brasil iniciou o último dia com a palestra “2012: o ano em que a Terra acabou, porque o software travou”. O Vinicius preparou muito bem a palestra que foi baseada numa captação de relatos de bugs embaraçosos de diversas empresas conhecidas. Com muito bom humor o Vinicius falou sobre como é complexo fazer software, bastante apoiado na literatura de Fred Brooks. Mais uma vez ele criticou duramente vendedores de certificação dizendo que o nome “Certified” e “Master” dão status de “Yoda” para quem carrega este selinho. Ele reforçou muito a mensagem de que se queremos ensinar e atuar como coach não podemos perder o hábito de programar e as dificuldades associadas a isso. Programar e ter bom código é importante para quem quer ter relevância na comunidade. Nesse ponto fiquei especialmente feliz pela menção honrosa do meu nome junto a outros grandes programadores como Klaus Wuestefeld, Henrique Bastos, Rafael Lima, Guilherme Chapiewski, Silvestre Mergulhão e muitos outros. A palestra foi o ponto alto do evento. Basicamente ele disse: “Quem realmente está fazendo, não está certificando.” A palestra do Vinicius deu o tom para as outras discussões que rolaram nos bate papos do evento, algo que se estendeu para o Empreenda-Framps.

[Será que alguem tem uma boa foto do Vinicius para colocar aqui?]

Antes do almoço, Christopher Thompson, um engenheiro naval com vasta experiência em Lean Manufactoring fez um excelente talk comentando e corrigindo alguns conceitos que tinha visto no evento até então. Lean Thinking como dito anteriormente é um livro de leitura obrigatória e Thompson reforçou princípios importantes contrapondo um mito comum da comunidade Scrum “que Lean serve só para construir carros”. Ele iniciou a palestra falando que as bases do Lean vieram de Ford e Taylor e que Taiichi Ohno dizia “Não ter problemas é o maior problema de todos”. As bases conceituais como o que é valor e o que é problema foram amplamente exemplificadas. Tenho tido contato e trocado ideias com o Christopher desde o treinamento com os Poppendicks no ano passado. Sempre com boas discussões.

Depois de comer mais uma refeição farta com frutos do mar, abri a tarde com a palestra “Lidando de forma eficaz com mentalidade legada”. Meu talk foi orientado a Lean/Kanban e mais uma vez compartilhei experiências de campo principalmente em transições Agile. Vendo a palestra do Vinicius onde ele citou sobre o “Programming, Motherfucker” de Zed Shaw fiz uma conexão direta com o resto do post do Zed onde ele diz sobre o “Management, Asshole”. Linkei minha palestra com a do Vinicius mostrando como é possível você melhorar qualquer processo existente criando visualização, impondo limites e permitindo que a organização toda (principalmente seu gerente) aprenda com o processo. Como disse no meu post anterior: Kanban é aumentar o conhecimento. Segue os slides:

O tom do meu discurso foi “deixe seu gerente errar, mas crie visualizações para o aprendizado”. Depois da minha palestra teve um swarming de pessoas ao meu redor com dúvidas. Isso nos levou a criar um Open Space com participação de figuras da comunidade Kanban como Alisson Vale e Clavius Tales numa discussão de excelente nível. Tivemos oportunidades de falar sobre vários estilos de Kanban e modelamos algumas visualizações para alguns participantes. Um dos pontos de discussão foi Kanban para gestão de portfolio, um assunto que tenho explorado em alguns clientes. Foi muito enriquecedor. Conversarmos sobre limites, swimlanes e a dinâmica social de um sistema Kanban. Infelizmente isso me fez perder o talk do Ale Gomes e do Matheus Haddad sobre Lean Startup.

O evento terminou com uma palestra conceitual e prática ao mesmo tempo: Alisson Vale é um cara que corriqueiramente tenho citado e veio correndo para Fortaleza do “Kanban Leadership Retreat” na Islândia (um evento fechado para os Kanban Thought Leaders do mundo que infelizmente não pude comparecer). Seu talk chamado: “Ciclos de Avaliação de Pressupostos: Entendendo Lean, Kanban e Agilidade sob uma nova perspectiva” explicou o “porque” de muitas práticas ágeis.

Uma das coisas que a comunidade Lean e Kanban mais estuda é “o porque” e o “como” das coisas (um dos focos da minha palestra). Infelizmente na comunidade Agile é mais comum se discutir o “o que” (o que é Scrum, o que é TDD, o que é Agile e etc…). A palestra do Alisson explicou sobre coisas do dia-a-dia e como o pressupostos são validados em ciclos que podem tomar mais ou menos tempo e o impacto disso. O Alisson escreveu praticamente tudo que falou em um artigo no blog dele:

http://alissonvale.com/englishblog/post/Cycles-of-Assumptions-Evaluation.aspx

O evento foi excelente e teve conteúdo muito muito muito variado. A organização está de parabéns e na minha opinião pelo clima, visual e pessoas o Agile Brazil deveria ser um evento fixo em Fortaleza. A próxima edição 2012 será em São Paulo e conforme o Dairton Bassi falou no encerramento do evento: “Será o maior evento de agilidade do hemisfério Sul”.

Após o Agile Brazil participei do III Empreenda-Framps em um hotel maravilhoso na Taíba com participação de Juan Bernabó, Alisson Vale, Paulo Fagiani, Ale Gomes, Renato Willi, Silvestre Mergulhão, Rafael Lima, Vinicius Teles, Patricia Figueira, Rodrigo de Toledo, Bruno Pedroso, Leonardo Antonialli, Marcelo Murad, Henrique Bastos, Clavius Tales e Saulo Arruda. Fraco, né? Infelizmente a primeira regra do Empreenda-Framps é “você não fala sobre o Empreenda-Framps”. Sorry.

Mais fotos:

Galera

Açaí em Mucuripe com direito a capotada de Hobie Cat

Joshua e Jim (Camiseta XGH dada pelo Rodolpho Ugolini)

Rosi e Raul (Buscapé) se matando no coffe-break

Conde Milfont, um dos locais, celebridade

Empreenda-friends

Este quadro foi sugerido a um cliente meu. Ele mostra o fluxo de módulos (que podem ter até 1000 horas de esforço) em um formato bem waterfall. O quadro possui limites altos de 5 módulos por etapa de projeto e desenvolvimento. Vocês devem estar tentando encaixar isso no seu mindset ágil. Não tentem fazer isso. Essa é uma implementação Kanban que não é Ágil. Nós podemos ter implementações Kanban não ágeis. Vocês devem estar se perguntando: “- Mas Rodrigo, como você sugeriu um Kanban cascata para o seu cliente?”. Eu respondo: antes de ter este quadro desse jeito o cliente trabalhava de uma maneira pior – o lote de trabalho era o projeto todo, não tinha qualquer visualização e sequer havia qualquer limite. Os primeiros eventos Kaizen que rolaram foram criar visualização, quebrar em lotes menores e limitar WIP. Não serão os únicos eventos Kaizen, mas foram os primeiros e o cliente aprendeu muito com isso.

O Cerne da filosofia Lean é muito simples: empresas existem para gerar valor para seus clientes. Uma grande motivação de escrever este post veio do livro “Gemba Walks” de James P. Womack. Este livro não é para a área de TI, então, se você não se interessou por Lean Manufacturing não o compre, pois ele é aplicação de Lean para indústrias. Eu particularmente gostei do livro pois me fez relembrar conceitos da época da minha gradução. Sou administrador de empresas por formação. Você trabalha no Gemba. Gemba é uma palavra japonesa que no contexto Lean significa o “local onde que as coisas acontecem”. É o local aonde há um grupo de pessoas ou equipes interessadas em gerar valor para alguém. Nós também chamamos isso de “Value Stream” ou corrente de valor. As práticas que você usa para “gerar valor” não interessam para o Lean. O importante é primeiramente gerar valor. Respeitar as pessoas, evitar desperdícios e melhorar continuamente são também muito importantes, mas o principal é atender o propósito da sua Value Stream, perpetuando a existência da organização.

Você deve usar alguns produtos de software, certo? Quero que você veja todos os produtos de software que você usa e procure na caixa do produto algo como “Feito com Scrum”, “TDD enabled” ou “We use Agile methods”. Encontrou? Questione a si mesmo porque isso não é um argumento de venda desses produtos. Simples: os clientes não dão a mínima se o produto foi feito da maneira X ou da maneira Y. Isso não lhes agrega valor. O que eles querem é ter seus problemas resolvidos de uma maneira simples e barata.

Lean é relevante porque Gembas são demasiadamente disfuncionais. Equipes tem dificuldades enormes em gerar valor. Os traumas de todas as suas falhas passadas geram a preocupação da preocupação da preocupação em não se gerar valor, e assim, muitas empresas estão entregues ao caos e sofrendo de toda forma de desperdício (muda, mura, muri). Algumas delas buscam soluções como RUP, PMBOK, Agile ou Scrum. Isso traz um questionamento: entender o método, aplicar o método e entender o porque do método são três coisas completamente diferentes.

Uma das maiores vantagens em ser consultor é a mobilidade que temos em uma organização. Bons consultores de processos podem discutir tecnicamente com desenvolvedores melhores estratégias de testes ou de build na manhã e à tarde conversar com o board de diretores sobre a estratégia do portfólio de produtos. No ínicio de 2009 desempenhava meu papel como Agile/Scrum Coach e aconteceu um episódio marcante: em uma das equipes de uma grande empresa um senhor de mais de 50 anos atuava como PO. Durante uma reunião diária ele ia dirigir uma pergunta para a equipe, mas antes ele me questionou se ele poderia fazer isso. Esse ato me chamou a atenção. Aquele PO estava preocupado se “no Scrum” ele estava com um comportamento adequado. Por alguma razão desconfiei que nisso tinha algo errado. MUITO ERRADO. O questionamento dele seria algo como “Isso é Scrum?”

Tenho visto a comunidade ágil não compreendendo o enfoque Lean do Kanban. Alguns da comunidade Scrum, especialmente os vendedores de certificação, não estão querendo se esforçar para compreender o Kanban. Muitos deles diminuem o Kanban ou espalham FUD. Kanban não se compara com Scrum, XP ou qualquer outro método. Kanban é um modelo de transição baseado em cultura Kaizen. Tirar este aspecto do Kanban é como tirar a Inspeção e Adaptação do Scrum. Kanban não tem receita de bolo. “Kanban não julga se você é Agile ou não” – essa é uma frase do Alisson Vale que ecoa na minha cabeça quase todos os dias. O maior objetivo do Kanban é melhorar um processo existente, por pior que ele seja. Na comunidade Scrum é comum o mito “começe com timeboxes e depois que estiver maduro, passe ao fluxo contínuo com Kanban”. Não! Kanban não é só isso. Como demonstrei no exemplo de Kanban acima mudamos um sistema estritamente waterfall para algo melhor e que pode melhorar continuamente até se tornar Agile e talvez até superar o Agile. Isso é a cultura Kaizen que o Kanban quer trazer a tona. Kaizen: hoje foi melhor do que ontem e amanhã será melhor do que hoje.

Kanban possui algumas propriedades. Atualmente o mercado tem se fixado muito em visualização do processo e fluxo contínuo. Poucas equipes estão indo além disso e chegando a impor limites (limitar WIP) e a gerir do fluxo (através de métricas). Kanban também sugere políticas explicitas e o uso de modelos para avaliar melhorias. “Modelos para avaliar melhorias” pode ser traduzido também como “use métodos científicos”. A falta de compreensão desta última propriedade é a causa raiz de toda má interpretação do Kanban. Ciência é conhecer. Kanban promove conhecimento. Se você analisar todo esse conjunto de propriedades juntas verá que o objetivo do Kanban é aumentar o entendimento da equipe e dos gestores sobre a natureza do trabalho que eles estão realizando. Com essas propriedades juntas uma equipe pode não somente “saber”, mas sim aplicar e observar que trabalhar com lotes menores entrega mais valor. Eles podem também não só saber mas aplicar e observar que quebrar os silos entre equipes pode melhorar a comunicação e entregar mais valor. Eles podem chegar a conclusão que colaborar com os usuários em ciclos mais rápidos gera mais valor. Kanban pode mostrar para eles a maneira mais eficiente deles trabalharem dadas as características únicas de seu ambiente, seu mercado e seu produto. Isso é entregar valor na abordagem Lean. Entendimento e experimentos geram melhoria. Melhoria gera mais valor. Isso é Kanban.

O que descreví no parágrafo anterior é muitas vezes diferente da abordagem Agile. Nós passamos os últimos 10 anos tentando explicar o que é o Agile e hoje muita gente “sabe” o que Agile é, mas não aplica e nem não sabe os porquês. Um médico na TV pode falar “pratique exercícios regularmente”. Todo mundo sabe que praticar exercícios é importante, mesmo assim poucos praticam! Isso é o que acontece com o Agile. No Kanban um médico fala “chequei que sua pressão arterial é altíssima, assim como o seu colesterol – assim, dado seu estilo de vida, 30 minutos de caminhada poderia melhorar suas condições, vamos observar os resultados…”. Pergunta: Qual dessas abordagens é mais convincente para sua equipe e seu gerente? Chega a ser hilário alguns praticantes de Scrum dizendo que “aqui é Scrum mas com testes automatizados” como se isso lhes dessem um selinho Agile. Pergunte para eles o porque do Scrum e dos testes e poucos deles darão uma resposta convincente além de citar seus autores preferidos.

As frases que poderiam resumir esse artigo são duas citações:

“Nunca ví uma empresa ter sucesso seguindo as melhores práticas”
Dave Snowden durante o LSSC11

“O segredo da Toyota é sua auto-suficiência. A Toyota tem seus próprios treinamentos, cria suas próprias práticas e suas ferramentas. Todas as vezes que vocês copiam a Toyota vocês se parecem menos com a Toyota.” W. Edward Deming para um grupo de empresários americanos

Usar Kanban é criar um ambiente (e visualizações) onde o entendimento seja aumentado e isso patrocine uma cultura Kaizen. Kanban não é somente fluxo contínuo ou um quadro na parede. Para o Kanban, não importa quais práticas você irá aplicar para melhorar o seu processo, mas para o Kanban é importante que você use argumentos científicos que expliquem o porquê dessas decisões. Kanban é um corpo de conhecimento aplicável a diversas áreas. Atualmente no meu trabalho de consultor tenho aplicado Kanban para equipes de desenvolvimento, equipes de manutenção, equipes Scrum, gestão de portfólio e muitos outros ambientes. Espero em breve contar mais histórias aqui sobre a versatilidade do Kanban.

Antes de mais nada quero deixar bem claro que desde a metade do ano passado passei a questionar muito a comunidade Agile, nossas técnicas, nossas abordagens, nossos dogmas e tudo que eu mesmo escreví no passado, inclusive aqui no Blog, e a maior razão de tudo isso é o que tem ocorrido no meu trabalho como consultor.

Contando um pouco de história a Aspercom começou trabalhos de transições ágeis no final de 2006. E a partir de 2007 as coisas começaram a esquentar bastante no mercado. Podemos chamar isso de “bolha do Scrum”. Em 2007, após entregar um importante projeto internacional para um cliente usando Scrum e XP, este cliente decidiu fazer um rollout do Scrum para outras áreas da empresa. Era uma consultoria grande que tinha uma área de produtos e para resumir, a grandiosidade da transição, com 5 equipes e mais de 40 pessoas envolvidas, foi equiparada com o seu monumental fracasso. Na época tentei mostrar os problemas usando todo arsenal ágil (transparência, conversa aberta, treinamento) para mudar o mindset do cliente mas de nada adiantou. A transição foi cancelada e por fim, aquela área da empresa fechou as portas mais tarde por eles não tratarem dos problemas que o Agile tentou mostrar.

A partir de 2008, analisando o mercado, tomei uma decisão totalmente na contra-mão do que meus concorrentes estavam tentando fazer. Quando você é uma empresa de consultoria a tendência natural é ir atrás do peixes grandes. E lá se foi muitos dos meus concorrentes levando arpão pro mar a fisgar Bancos, Telecoms, Governo e grandes consultorias. Não tenho parametros para julgar o sucesso deles nessas empreitadas, eu, porém, fui atrás das empresas menores, focando principalmente em pequenos ISVs, com até 40 desenvolvedores. O meu julgamento na época foi: ” – Esses lugares grandes não estão preparados para agilidade ainda”. O impacto positivo desta decisão é que a minha estratégia deu certo em atender os pequenos. O impacto negativo é que me afastei desses grandes clientes, muitos deles com sérios problemas, e tratei isso com sarcasmo. A maioria desses grandes está nas mãos de grandes consultorias ou Tool Vendors que prefiro nem comentar o que são.

Em 2009, ainda relutante com os grandes, entrei em negociação de um grande projeto de transição junto a SulAmérica Saúde. Fiquei surpreso em como a gestão, o PMO e todas as equipes da SulAmérica Saúde estavam realmente dispostas a mudar, e a sinergia entre eles e a Aspercom foi muito empolgante. Nós escolhemos o Scrum como modelo inicial, porém, devido a configuração dos projetos (como exemplo, a dependência de um fornecedor externo), usamos muitas práticas Lean e Kanban para fortalecer aonde o Scrum não ajudava. Fora isso, a SulAmérica também adotou práticas XP como Pair Programming, Test-First, Integração Contínua e Build Servers. Em novembro de 2010 todos os projetos foram entregues com grande sucesso. Parabéns a todas as equipes envolvidas. Neste trabalho as técnicas Lean foram determinantes para criar mecanismos visuais para que os gestores atuassem cirurgicamente nos problemas apontados pelo Kanban. Não há dúvidas que a cultura mudou, porém, não é mérito meu como consultor, e nem mesmo das minhas soft-skills. O que mudou a cultura foi o modelo de gestão.

Neste ano de 2011, mais uma vez fui chamado para uma grande transição. Comecei os trabalhos na holding Buscapé.com em janeiro com as equipes da plataforma de afiliados Lomadee e uma equipe da Central de Negócios Buscapé. Nestas equipes temos 3 implementações Kanban e uma Scrum. Após 2 meses de trabalho os resultados apresentados na Operations Review há duas semanas mostrou que as alterações foram efetivas e o processo mais otimizado e previsível. Mais uma vez, não há dúvidas que a cultura mudou, mas isso foi resultado do modelo de gestão e transição com práticas Lean, e não de qualquer atuação minha na “Cultura” da organização.

Algumas coisas mudaram muito minha forma de pensar sobre como lidar com grandes clientes, e isso pode te ajudar na sua empresa. Veja a figura abaixo:

Figura 1

A figura não acrescenta muito sem uma explicação. Toda empresa busca ser ágil e para tal, há um caminho a ser seguido. Esse caminho não é único, mas não foi retratado no desenho. É bastante comum empresas buscarem o Scrum como sendo este caminho, porém, é um risco grande e bastante comum acontecer o seguinte:

Figura 2

Muitas empresas querem “só ter processo”, e alguns cenários é tão difícil aplicar Scrum que o meio se confunde com o objetivo, e por fim, equipes declaram que “quando estivermos usando pontos e planning poker, estaremos bem” ou “este burndown precisa baixar”. Apesar do Scrum como modelo de transição funcionar muito bem nas empresas pequenas que trabalhei, em empresas grandes o Scrum não é um bom modelo de transição.

Voltando a figura 1, não tenho dúvidas que o modelo ágil para desenvolvimento de software é o melhor que temos. Práticas iterativas incrementais focadas em valor, associadas a alta qualidade e trabalho em equipe comprovadamente são a perfeição em desenvolvimento de software na tecnologia atual. Porém, como comunidade, passamos os últimos 10 anos explicando o que é Agile e porque ele é melhor comparado às besteiras que o mercado faz. Toda palestra, blog post, twittada ou discussão em fórum, aprendizes e mestres “pulam” de um extremo ao outro na figura 1, mostrando extrema dualidade, mas sem falar muito em como transitar dentro da seta azul, principalmente se o ambiente é complexo.

O pior de tudo é que se criou um mito nesse assunto chamado “Cultura Agile”. É bastante comum pessoas da comunidade ágil culpar a “Cultura” pelas dificuldades que há em transitar nessa seta azul. O discurso comum é “minha equipe não se comporta da maneira ágil”, “meu chefe é tradicional”, “nós não temos uma cultura TDD”, “ainda temos gerente de projeto”, “chamamos pessoas de recursos” e por isso, não dá para “ser ágil”. O mito, por fim, são as empresas e as pessoas acharem que para solucionar essas arestas uma boa dose de soft-skills de um consultor/coach resolvem com “um bom bate papo”. É exatamente isso que atualmente tenho questionado duramente e acredito que é uma falha o consultor tentar mudar a cultura empresarial, impondo-lhe uma própria, afinal, quem pode dizer se a cultura do consultor é melhor que da empresa? O que tenho experimentado na minha prática como consultor é que não adianta se focar na cultura por ela ser abstrata. Há caminhos melhores para trafegar nessa linha azul, e a isto estou chamando de “modelo de transição”.

O livro “Creating A Lean Culture: Tools To Sustain Lean Conversions” de David Mann tem um trecho muito interessante:

Relatórios de resultados anuais orgulhosamente se referem a cultura empresarial como o maior ativo da compania e etc… Assim, deve uma empresa focar na sua cultura os esforços de transformação dos seus processos produtivos e toda a hierarquia associada com ela? É tentador responder: Sim! Mas isso seria um erro.

Cultura é um alvo não muito diferente do ar que respiramos. Não é algo que devemos focar para a mudança. Cultura é uma ideia emergindo das experiências. … Dessa forma, a cultura de uma empresa é resultado do seu modelo de gestão.

A premissa deste livro é que a cultura é critica, e para mudá-la você deve mudar seu sistema de gestão. Então, foque-se no seu modelo de gestão, nos alvos que você pode ver como o comportamento dos líderes, expectativas, ferramentas e práticas rotineiras. Sistemas Lean de produção fazem isso mais fácil porque eles enfatizam processos definidos de forma explicitas e o uso de mecanismos de controle visuais.

Concluíndo, é muito fácil para um consultor esconder resultados pobres culpando “a Cultura” ou qualquer outro elemento não palpável. Um outro ponto importante é que um consultor em processos de TI não pode se ater a somente um único modelo, e nem só o Modelo Agile. Um consultor ou empresa que se foca somente em Scrum impõe sua cultura míope ao cliente, levando a resultados indesejados.

Decisões devem ser tomadas tendo como objetivo metas do negócio e não metas do consultor. Tudo deve ser baseado no sistema de gestão adotado. No meu trabalho as técnicas que tenho usado são Lean, Kanban, Systems Thinking e princípios do System of Profound Knowledge (Deming) para criar um sistema de gestão que permita melhoria contínua e com isso, muda-se a cultura indiretamente, e somente *se* necessário. Essa mudança cultural é alavancada sempre pela própria organização, que se adapta a cada ciclo na melhor forma Kaizen. Não são nas emoções e nos sentimentos que vem as melhorias. Mudanças nem sempre se traduzem em melhorias.

Mais sobre esse assunto em breve aqui no Débito Técnico.

Vejo que todos estão blogando menos. Vocês devem ter notado nos seus readers que anda tudo muito parado. O motivo disso é o Twitter. Quem me segue no Twitter sabe que estou muito ativo por lá.

Uma outra razão da minha falta de tempo é a participação em eventos. Tinha o costume de postar retrospectivas aqui e como as coisas acumularam vou montar tudo em um único post com aquilo que achei mais importante.

Qcon SP

A Qcon foi um evento único e marcante do ano. Todo o pessoal do InfoQ Brasil está de parabéns. Presença de muitos nomes internacionais e também foi o evento que mostrou a maturidade do desenvolvimento de software no Brasil.

Neste evento fui o host da track de Agile, e os convidados foram Alexandre Magno (Adaptworks), Márcio Duarte e Felipe Silva (Globo.com), Giovanni Bassi (Lamba3) e Paulo Caroli (Thoughtworks).

Minha apresentação foi na verdade uma manifestação. Hoje vivemos uma terceira ou quarta guerra dos métodos em TI e creio que devemos parar para pensar e (por favor) amadurecer. Estas brigas entre Scrum, XP, Kanban, RUP e outros não melhoram em nada nosso mercado. Os slides estão aqui:

Na minha apresentação despertei o fato que por 20 anos nós estamos tentando aproximar o cliente do projeto de TI. Atualmente vejo que a perfeição em desenvolvimento de software seria exatamente o contrário: A TI se aproximar do negócio e ser co-responsável por ele. Porém, isso implica em um grande impacto nas organizações: Não existiria mais TI. Com isso não existiria mais processos, papéis, hierarquias e burocracias. A aproximação da TI com o negócio, algo que TODO CIO sempre fala ao assumir o cargo, se fosse verdade, faria a TI sumir.

Nessa visão você seria um especialista de produto, um vendedor ou um contator que sabe programar. Interessante ver que tenho recebido relatos da comunidade de outras pessoas que pensam assim. No fundo usamos metodologias e processos para nos autorizar a fazer coisas que já deveríamos fazer. Tenho trabalhado numa idéia chamada “Extreme Business”, será polêmico, é assunto para outro post.

Alexandre Magno fez uma importante palestra mostrando como algumas grandes empresas implementaram Scrum. O pessoal da Globo.com e o Giovanni fizeram palestras mais técnicas e avançadas. O Paulo Caroli complementou muito bem com exemplos algumas coisas que falei sobre Kanban. E no caso dele, achei legal a maturidade da comunidade ouvir numa palestra de Agile algo como “linha de montagem de software” sem acender as tochas. Isso é maturidade.

Encontro Ágil (sem Palestras!)

O Encontro Ágil 2010 na USP foi também muito especial. Um evento sem palestras, somente Open Spaces sugeridos pelos próprios participantes. O evento deu muita liberdade de escolha para você aprender. Logo no início uma grande reunião entre todos definiu os temas. Sugeri um Release Planning de um produto real da Aspercom e participei do fórum para discussão de Scrum x Kanban sugerido pelo Giovanni Bassi.

Release Planning real num evento. Mapa Mental e Protótipos.

Neste ano de 2010 uma das polêmicas da Guerra dos Métodos é a briga Scrum x Kanban. Apesar do Henrik Kniberg tentar explicar isso no seu livro Scrum & Kanban, muitos da comunidade Scrum estão refutando Kanban. Para melhorar ainda mais, o Ken Schwaber, um dos criadores do Scrum, autor que tenho muito respeito, escreveu no seu blog um post criticando muito Kanban. Neste post, sinto muito, o Ken realmente escreveu besteira, apesar do texto tentar ser teórico. Para iniciar, Kanban não é um processo prescritivo. Para falar a verdade, ele é mais empírico que o próprio Scrum.

O fórum Scrum x Kanban teve a participação de aproximadamente 50 pessoas. O Giovanni, que tem contato com o Ken pela Scrum.org, defendeu o posicionamento dele, basicamente dizendo que Kanban é para processos definidos, como linhas de montagem, e assim, parafraseando a tecla que o Ken tem batido, “não serve para software”. A primeira impressão de pessoas que tem contato com Kanban é exatamente essa, e sendo sincero, em 2008 também refutei Kanban pelos mesmos questionamentos. O Alisson Vale, meu mentor em Kanban e talvez um dos nomes mais fortes em Kanban no mundo teve que gastar muito latim para explicar pra mim (e também para o Clavius Tales) os detalhes importantes desse modelo. É importante frisar que minha motivação para estudar Kanban foi exatamente o fracasso de algumas implementações Scrum.

No fórum tentei ter uma postura pacífica, que inclusive aprendi na comunidade Kanban. Muitas vezes escrevo ou falo coisas fortes, mas realmente tenho tentado mudar isso. Não adianta brigar, temos que ter paciência para ensinar. Achei até interessante que algumas pessoas pensaram que ia ter sangue, mas no fim até gostaram da minha postura.

O Encontro Ágil definitivamente foi diferente. Espero que repitam a dose várias vezes. Parabéns a todos da organização.

Maré de Agilidade Fortaleza

O Maré de Agilidade também seguiu a linha dos eventos do segundo semestre onde os assuntos foram mais aprofundados, mais técnicos e também mais práticos. Fico contente que a comunidade ágil tenha evoluido e a comunidade em Fortaleza é empolgante, sem dizer que é muito hospitaleira.

Para mim o ponto alto do evento foi o primeiro treinamento aberto de Kanban ministrado aqui no Brasil que tive o previlégio de ministrar junto com o Alisson Vale. O treinamento com 25 pessoas de várias organizações foi ministrado na Fortes. Este treinamento estará disponível para o público em Janeiro de 2011 no site da Aspercom.

A hora Kanban: dinâmica que criei para simular do caos à visibilidade com Kanban – aprovado pelo Alisson Vale

A avaliação dos alunos e os feedbacks no Twitter foram muito legais. Obrigado a todos que participaram.

No dia do evento assisti as palestras do Paulo Silveira (Caelum), Mauricio Linhares, e Alisson Vale. Os dois primeiros foram mais técnicos, e neste evento foi muito legal conhecer o Mauricio. Sua palestra sobre soluções para alta performance web mostrou muito sua experiência. A maioria das técnicas alí nem sabia que existia! Eu e o Alisson falamos sobre Kanban. Segue os slides:

Minha palestra mostrou como tenho usado Kanban para atuar junto de projetos e clientes com ou sem Scrum, tentando ensinar principalmente sobre o que é realmente importante no Kanban como Visualização, Process Design, Swarming entre outras coisas. Mas foi uma palestra básica. Agora, a palestra do Alisson, não se preocupe se você entender muito pouco. Uma das coisas que tenho achado muito interessante é que a comunidade Kanban é mais teórica, mais aprofundada e menos dogmática. A comunidade Kanban tem discutido hoje idéias muito mais avançadas, que transcende TI na empresa. Mesmo tendo estudado sobre processos a mais de 10 anos, tenho muitas vezes dificuldades de acompanhar o raciocínio do pessoal Kanban. Tem conteúdos muito interessantes como este vídeo:

Enquanto isso a comunidade Scrum discute técnicas exóticas de retrospectiva ou como misturar e tornar comercial a mistura Scrum + “Práticas Ágeis de Engenharia” (como CSD, ou PSD), perplexa com a crise na ScrumAlliance. Sou parte da comunidade Scrum, isso não é uma crítica externa.

Por fim, o Maré de Fortal foi o primeiro encontro de Agilidade nos últimos 3 anos que não teve palestras de Scrum. Acho importante essa maturidade e também o fim do Scrum-Hype.

AgileVale

Em São José dos Campos, em sua primeira edição, nas suntuosas instalações do renomado Instituto de Tecnologia da Aeronáutica (ITA), o AgileVale marcou o fim da minha agenda de eventos este ano e o início de uma comunidade de desenvolvimento de software que tem tudo para explodir no Vale do Paraíba. Foi espetacular e ví um grande potencial alí. Divido em duas tracks, mais uma vez renomados agilistas estiveram presentes como Fabiano Milani (AdaptIdeas), Paulo Caroli (Thoughtworks), Felipe Rodrigues (Lambda3), Eduardo Guerra (ITA), Fabio Akita (GoNow) e Cecília Fernandes (Caelum). A organização foi espetacular e foi um evento de 300 pessoas de São José e região.

Luiz Faias e André Faria

O destaque vai para Luiz Faias e André Faria. Na apresentação eles mostraram como uma cultura de aprendizado foi desenvolvida na BlueSoft mesmo sendo uma empresa pequena. Ideias muito inteligentes e inspiradoras.

Nos últimos tempos o Luiz e André tem mostrado muito esforço e empenho com a comunidade Agile através dos seus vídeos (inclusive minha aula sobre Kanban do Noite Ágil, que tem gerado ótimos feedbacks).

Kanban – Rodrigo Yoshima from Bluesoft on Vimeo.

Desculpe o post longo, mas ele conta o início do meu trabalho como evangelista Kanban. Esse artigo é um pontapé inicial da nossa estratégia na Aspercom de oferecer ao mercado brasileiro a filosofia Kanban, que é uma alternativa para quem tem dificuldades com Scrum e também atende outras áreas da TI como manutenção, infra-estrutura, operações, negócios, interligando isso tudo. O conteúdo Kanban é muito abrangente: busquei um mentor e demorei mais de 2 anos estudando, desafiando e tentando aplicar Kanban para ter minhas próprias conclusões. Isso tem melhorado até minha visão do Scrum, sabendo onde e como ele é melhor aplicado.

Alan Shalloway tem uma frase que tem também me influenciado: “Mudando o mercado, uma empresa de cada vez.”

Para complementar nosso portifólio de cases ISV, no mês de maio a Aurum, uma empresa direcionada para soluções no mercado jurídico com o seu produto Themis, nos contactou para trabalharmos juntos na transição Agile.

Além do treinamento para aproximadamente 15 pessoas na Aurum, tivemos excelentes sessões de coaching nos primeiros plannings, reviews e retrospectives. Em todas as nossas propostas incluímos entre 8 a 40 horas de consultoria para auxiliar as empresas nas suas implantações de processos ágeis. Com isso, acompanhamos as equipes nas primeiras Sprints, tirando dúvidas, mostrando técnicas e atuando como agente facilitador. Essa tem sido a nossa estratégia em muitos clientes e vemos que somente treinar pode deixar as equipes com muitas dúvidas que algumas horas de coaching eficiente resolvem facilmente.

No caso da Aurum foi bastante interessante como logo na primeira Sprint do projeto piloto a equipe assumiu um compromisso de melhorar também suas práticas de engenharia com uma arquitetura orientada a objetos em Delphi e testes automatizados. Pelo relato deles, a inspeção e adaptação foram determinantes para a entrega do primeiro release Agile que foi um grande sucesso.

Parabéns a todos da Aurum pela determinação e inovação. Muito sucesso!

Treinamento

Equipe no primeiro Planning do projeto piloto

Review & Retrospective Boards nas primeiras Sprints