Restrospectiva: KanbanBR 2011 com David Anderson

Publicado em 1 de dezembro de 2011 por Rodrigo Yoshima

Nos dias 21 e 22 de novembro David Anderson, o criador da abordagem Kanban, esteve aqui em São Paulo ministrando um treinamento comigo pela Aspercom e também palestrando no evento KanbanBR para o lançamento do seu livro em português. Foram dois dias muito interessantes, com muito aprendizado e troca de experiências. Antes de mais nada gostaria agradecer a Microsoft pelo total apoio, fornecendo toda a infra-estrutura para que os dois eventos fossem um sucesso.

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

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…

rodrigoy rugolini

david flowhour

“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.

KanbanBR David

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!

Publicado em agilidade, eventos, gestores, kanban, liderança | 3 comentários

Dois dias com a ThoughtWorks

Publicado em 24 de outubro de 2011 por Rodrigo Yoshima

Há diversas maneiras de você explicar uma empresa. Alguns explicam uma empresa olhando seu faturamento, a quantidade de pessoas ou o valor da ação. Há quem explique a empresa olhando para seus donos. Poucos tentam compreender uma empresa olhando a sua cultura. Estou escrevendo este blog do Aeroporto Salgado Filho em Porto Alegre depois de dois dias muito intensos visitando a ThoughtWorks (TW). Muitas histórias para contar…

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!

Publicado em agilidade, eventos, gestores, liderança, mercado | 16 comentários

Treinamento Kanban com David Anderson em São Paulo

Publicado em 6 de outubro de 2011 por Rodrigo Yoshima

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!

Publicado em anúncios, kanban | 9 comentários

Kaikaku – Kaizen

Publicado em 9 de setembro de 2011 por Rodrigo Yoshima

Você é um gerente de uma grande empresa de software. Sua função é desenvolver projetos ou produtos e mantê-los funcionando 100%. Você “cuida” de mais ou menos 100 pessoas entre analistas, desenvolvedores e testers e seu desafio é deixar os usuários felizes com pouca encheção de saco. Recentemente você participou de um evento “de Agile” e algum consultor (ou outro gerente como você) relatou numa palestra as dificuldades e eventuais resistências que eles enfrentaram numa transição “pra Agile”. Até deu medo. Algumas palestras você deve ter ouvido falar coisas como acabar com as hierarquias, juntar as áreas de negócio com desenvolvimento e qualidade, demitir os gerentes… Você se sentiu confuso e atordoado com a veemência que o palestrante disse aquilo que é certo ou errado no Scrum, XP ou qualquer outra coisa. Você também teve dificuldade de entender como tudo aquilo caberia no seu ambiente, com certeza.

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:

timesfilas

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.

Publicado em agilidade, gestores, kanban, mercado, scrum | 13 comentários

Restrospectiva Agile Brazil 2011 Fortaleza

Publicado em 4 de julho de 2011 por Rodrigo Yoshima

Aproveitando as 2 horas de espera aqui no aeroporto de Brasília, estou retornando de Fortaleza dos eventos Agile Brazil e Empreenda-Framps. Antes de mais nada vou fortemente recomendar que você visite o Ceará nesta época do ano: o clima estava super agradável e amenizou um pouco o tempo chato que geralmente convivo em São Paulo.

fortal

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
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.

gembapeixeputo
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.

joshua
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.

thompson

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:

Lidando de forma eficaz com mentalidade legada
View more presentations from rodrigoy

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.

alisson

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:

2011 07 01 11 46 41 145 1
Galera

2011 06 28 16 48 32 8
Açaí em Mucuripe com direito a capotada de Hobie Cat

2011 06 29 18 19 45 35
Joshua e Jim (Camiseta XGH dada pelo Rodolpho Ugolini)

2011 06 30 10 27 40 825
Rosi e Raul (Buscapé) se matando no coffe-break

2011 07 01 11 27 17 400
Conde Milfont, um dos locais, celebridade

2011 07 02 12 29 50 332
Empreenda-friends

Publicado em agilidade, eventos | 10 comentários

Dizer sim ao Lean torna o resto irrelevante

Publicado em 22 de junho de 2011 por Rodrigo Yoshima

Escolher o título deste artigo não foi uma tarefa fácil. Ele poderia ser algo como “Mitos do Kanban” ou “Por que primeiro Scrum e depois Kanban?”. O objetivo principal deste artigo é falar sobre Kaizen, e é direcionado para a comunidade Agile e Scrum em geral. Antes de começar quero que você avalie atentamente o quadro Kanban abaixo:

kanban modulos

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.

Publicado em agilidade, gestores, kanban, scrum | 10 comentários

O mito da Cultura Ágil

Publicado em 3 de abril de 2011 por Rodrigo Yoshima

Infelizmente a minha falta de tempo está deixando o blog um pouco de lado, porém, tudo tem uma razão e pretendo agora começar aqui no Débito Técnico a contar histórias principalmente sobre modelos de transição ou melhoria em processos.

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:

Figura1
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:

Figura2
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.

Publicado em agilidade, gestores, kanban, liderança, mercado, scrum | 14 comentários

Kanban! Retrospectivas QconSP, Encontro Ágil, Maré Fortal e AgileVale

Publicado em 25 de novembro de 2010 por Rodrigo Yoshima

Mais uma vez desculpem a falta de postagens por aqui. Neste segundo semestre de 2010 estive bastante envolvido em alguns projetos, consultorias e treinamentos. Ainda tenho que postar aqui relatos de clientes como a SulAmérica (Scrum, XP e Kanban), a EPC Engenharia (Scrum fora de Software!), a Voice Tecnology (Scrum e XP), o Tribunal de Contas do Tocantins (Scrum e XP), a Interdual (Kanban) e mais uma vez a Aurum (Kanban).

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:

Apresentação e guerra dos métodos 2.0
View more presentations from rodrigoy.

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.

5159953357 6f4209dd1d
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.

191725730
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:

O que é Kanban e porque se importar com ele
View more presentations from rodrigoy.

Kanban Expandido: Usando visibilidade para transformar processos on Prezi

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.

195234019
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.”

Publicado em agilidade, eventos, gestores, kanban, mercado, scrum | 5 comentários

Agile de vento em popa na Aurum

Publicado em 21 de julho de 2010 por Rodrigo Yoshima

ISVs (empresas de produto) definitivamente é o ambiente que mais se beneficia das práticas ágeis. E o melhor de tudo isso é que a implantação é tranquila, simples e principalmente barata se comparada com outros ambientes.

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!

Imagem0572
Treinamento

Imagem0647
Equipe no primeiro Planning do projeto piloto

Imagem0662
Review & Retrospective Boards nas primeiras Sprints

Publicado em agilidade, cases, scrum | 1 comentário

Scrum/Agile na e-Deploy

Publicado em 21 de julho de 2010 por Rodrigo Yoshima

Essa é especial para os Applemaniacos. Em maio ministrei o treinamento Scrum para a equipe da e-Deploy. Com muitas boas discussões sobre projetos, esta turma foi especial por estarem num ramo altamente em foco: aplicações mobile para a plataforma iPhone, Android entre outras.

Fiquei impressionado com o direcionamento dos produtos da e-Deploy. Realmente eles estão alinhados com as idéias novas da Web e com certeza terão sucesso com práticas ágeis.

(ao pessoal da e-Deploy, temos a pendência daquele pairing em Objective-C)

Imagem0617
Atividades em Grupo

Imagem0628
Sprint Planning

Publicado em agilidade, cases, scrum | 1 comentário