Mais uma vez a Aspercom em parceria com a Microsoft e a Lean-Kanban University trazem ao Brasil David Anderson, o criador da abordagem Kanban, para mais um treinamento.
Pequenas, médias e grandes empresas no Brasil e no mundo estão crescendo e tendo resultados espetaculares na aplicação de abordagens Lean e Kanban para o trabalho do conhecimento. Em novembro de 2011 tivemos um excelente treinamento e evento com David Anderson. O sucesso foi tão grande que rapidamente mais pessoas se interessaram e assim abrimos mais uma turma do treinamento “Kanban Systems for Software Engineering”. Veja o programa aqui.
Neste excelente treinamento de dois dias você irá aprender na prática e em profundidade novas abordagens de gestão e melhoria de processos, destacando as propriedades de um Sistema Kanban: Visualizar o Processo, Limitar Trabalho em Andamento, Controlar o Fluxo, Estabelecer Políticas e Alavancar Melhorias. Se sua empresa tem buscado mais agilidade, este curso irá lhe oferecer novas ferramentas para lidar com ambientes complexos, na melhor forma Kaizen.
Datas: 19 e 20 de julho das 9:00 às 18:00
Vagas: Somente 10 inscrições disponíveis
Local: Microsoft – Av. Nações Unidas, 12.495 – 17º andar – 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 (a maior parte será em inglês). Todo participante ganhará uma cópia do livro “Kanban” em português. Desconto especial para clientes Aspercom. Vagas limitadas!
É com grande prazer que anunciamos que neste mês de maio a Aspercom foi selecionada como a primeira empresa brasileira a integrar a Lean-Kanban University. A Lean-Kanban University (LKU) é uma organização mundial formada por grandes pensadores Kanban como David Anderson, Alan Shalloway, Yuval Yeret, Karl Scotland, Russell Healy e muitos outros.
O objetivo da LKU é agregar o conhecimento na aplicação e desenvolvimento da abordagem Lean e Kanban para todo trabalho do conhecimento. Uma dessas iniciativas é o programa “Accredited Kanban Training” cujo foco é garantir a qualidade dos treinamentos Kanban através de um curriculum definido, um material oficial e instrutores com experiência comprovada na aplicação e ensino na abordagem Kanban.
A motivação maior para este programa é a franca expansão do mercado Kanban e a necessidade de comprovação de qualidade junto às potenciais empresas e equipes usuárias. Para a Aspercom em particular é importante participar da LKU para estar próximo aos maiores mestres Kanban do mundo, e principalmente, fazer aquilo que é o melhor para fortalecer a comunidade Kanban brasileira.
Uma das coisas que mais me preocupam no mundo Agile atual são certas miopias. Implementações Scrum pipocam aqui e alí, e como já havia comentado aqui no blog, as empresas grandes estão acordando para Agilidade. Nas minhas andanças em clientes em São Paulo e outras cidades (fora o contato com mais de 30 clientes do mundo todo pelos produtos FlowKaizen e Wiphub.com, ambos da Aspercom) tenho escutado uma conversa bastante comum:
Aqui na XPTO Tech temos um projeto piloto que queremos que seja ágil. O escopo dele não irá mudar tanto, nós analizamos tudo muito bem e investimos um mês e meio na construção do backlog. Agora chegou a fase de começar a rodar Sprints…
Um dos maiores problemas do Agile é ele ter nascido na TI, ser um assunto de TI e defendido fervorosamente por “programadores”. Essa conversa acima é bastante comum. Nessa mentalidade o Agile é relegado a um assunto “técnico”. Várias vezes já discuti com CIOs, CTOs e Gerentes sobre essa visão equivocada. Uma das maiores armas para mudar essa forma de pensar é criar visualizações do problema (prática Kanban). Um Cumulative Flow Diagram (ou simplesmente CFD) pode auxiliar nesta visualização. Veja o gráfico a seguir:
Este gráfico é de um cliente real da Aspercom. O CFD é um gráfico bem simples. Ele demonstra a quantidade de trabalho acumulado demonstrando a saúde do fluxo do processo. No eixo X temos o tempo e no eixo Y temos o número de itens de trabalho que podem ser demandas, funcionalidades, stories, bugs, casos de uso e etc. Neste gráfico a camada amarela demonstra o escopo (ou backlog) do projeto. A camada vermelha é o trabalho em progresso (work-in-progress ou simplemente WIP – trabalhos iniciados mas não terminados). A camada azul demonstra as entregas (isto depende da sua definição de entregue, uma grande discussão que pode ficar para outro artigo).
Observando este gráfico acima você consegue advinhar o que aconteceu neste projeto? O CFD conta uma história clara: entre as semanas 1 e 6 a equipe puxava novos trabalhos mesmo sem terminar os trabalhos antigos. Isso congestionou o fluxo de trabalho até a semana 7, quando começamos a usar Kanban colocando uma meta de ter somente 10 itens no WIP. O Kanban mostrou gargalos e impedimentos organizacionais que foram resolvidos gradativamente. Da semana 7 até a semana 10 tivemos um período de adaptação, onde nenhum novo item foi puxado do escopo até conseguimos chegar na meta de 10 itens no WIP. A partir da semana 9, com o WIP limitado, note como a inclinação da camada azul se tornou mais estável e previsível. Este gráfico explica muito bem a razão do Kanban limitar WIP e os ganhos econômicos dessa prática: mais agilidade, menos filas, menor leadtime entre outras coisas. Como falei, este gráfico é real e tenho visto este padrão em diversas equipes usando Kanban (e/ou Scrum).
O Cumulative Flow Diagram – como outras métricas Lean – mostra a saúde do sistema sem alterá-lo. O CFD não é usado como meta ou objetivo como um Burndown Chart. O CFD cria uma visualização de “estoques” de trabalho a fazer e trabalho em progresso. Alguns CFDs possuem 4, 5 e até 10 camadas, separando o WIP em Análise, Desenvolvimento, Testes e etc… Assim ele pode evidenciar se o trabalho se acumula mais em alguma etapa específica do processo. Ultimamente tenho usado a prática “WIP é WIP”, isto é, se está em progresso é WIP, não importando qual o estado do trabalho. Isso facilita a construção do gráfico e torna o CFD uma ferramenta mais simples. Veja mais este exemplo.
Antes de continuar a leitura, tente analisar este processo. Se você compreendeu o conceito até aqui você deve ter chegado a conclusão que este é um processo cascata. Todo o escopo foi levantado prematuramente, todo trabalho foi feito como um grande lote único e a implantação foi “Big Bang”. Claramente esta equipe correu muitos riscos de qualidade em ter um WIP tão alto, pois não tinha os resultados palpáveis do trabalho (veja as entregas – a camada azul). Um processo cascata simplesmente não tem fluxo. É imprevisível.
Veja mais um exemplo:
O CFD idealmente deve começar a ser plotado assim que o projeto começou a ser discutido e não quando iniciou a implementação. A corrente de valor é muito mais que a construção e o CFD deve mostrar outras áreas da empresa que podem não ser ágeis (como exemplo uma área de produto ou marketing que fica cozinhando o escopo e depois pede urgência). Essa visão holística do CFD demonstrará o problema da XPTO Tech citada no inicio do artigo, oferecendo oportunidades de melhoria. A falta dessa visualização do nascimento e crescimento do escopo é uma falha que vejo na maioria dos Burndown Charts. Outra falha do Burndown Chart é ele não rastrear WIP.
Neste gráfico “pronto” (done) é software em produção, assim, vemos que esta equipe fez dois releases grandes. Este é um padrão que tenho observado em algumas equipes saindo do cascata e indo para o Scrum: o escopo cresce prematuramente e os releases são grandes. Verifique como se comportou o escopo (faixa amarela) – o gráfico mostra que um grande release planning de várias semanas aconteceu no início, seguido de mais um aumento de escopo (mais um release planning, talvez) a partir da 10a. semana. Isso nos leva a um questionamento: Rodar Sprints para vencer um backlog ou roadmap que demorou semanas para ser elaborado em outra área é ágil? Note o quanto de atraso o projeto teve nas semanas iniciais. Agilidade é uma estratégia para iterar sobre o problema e a solução. O CFD deixará claro se isso não é verdade na sua empresa.
Analisar a camada amarela de um CFD nos diz muita coisa: se ela estiver muito larga significa que a expectativa sobre o projeto está alta. Isto é um risco, pois pode demonstrar, como exemplo, que o Product Owner está especulando demais sobre o escopo sem entregar valor. O CFD também demonstra claramente para o PO que colocar mais coisas no Backlog não faz a equipe andar mais depressa.
O CFD é uma ferramenta que tem me auxiliado muito em diversos ambientes, pois é uma métrica independente do ciclo de vida do processo (cascata, timebox ou fluxo contínuo). Essa versatilidade é importante para mudanças incrementais de processos – os gestores e a equipe resistem muito a mudanças até compreenderem o real problema. Você pode pode passar a usar um CFD sem mudar seu processo atual e usar Kaizen para melhorá-lo incrementalmente. Visualizações e métricas ajudam uma empresa a tomar melhores decisões sobre os processos.
Muitas pessoas me perguntam o que seria o CFD “ideal”. A resposta é simples: Quanto menos estoques, mais Lean é. Se o processo está melhorando os estoques estão diminuindo e não aumentando. Veja este gráfico de um projeto interno real da Aspercom:
Este seria o gráfico típico de uma Lean Startup: o problema sendo “experimentado” junto ao desenvolvimento, sem longos backlogs, com baixo WIP e releases constantes. Mais uma vez, o CFD nos mostra a saúde do fluxo. Ele não deve ser usado como meta de entrega ou para pressionar a equipe, empurrando o sistema de trabalho. Uma citação que gosto muito é:
“When a measure becomes a target, it ceases to be a good measure.”
Goodhart’s law
Métricas observam um sistema de trabalho e idealmente não devem modificá-lo. Você pode usar as métricas Lean mesmo em um processo Scrum, deixando o fluxo mais solto sem depender de Sprints para ter métricas.
Todos os gráficos postados aqui foram plotados pelo Wiphub.com. Wiphub.com é um produto mundial da Aspercom que está em fase beta (gratuito). O Wiphub é uma ferramenta simples que oferece métricas Lean para Kanbans físicos (atualmente ele oferece o CFD, o Leadtime Control Chart e o Throughput / Velocidade). Experimentem! Estamos esperando seu feedback!
Certa vez estava conversando com um gestor de uma grande corporação. Eu havia treinado 3 equipes de desenvolvimento daquela empresa e estava iniciando os trabalhos de consultoria para um grupo de 45 pessoas focado em melhoria de processos usando Scrum e outras práticas Agile. Aquele departamento de TI tinha um orçamento de alguns milhões de reais. Nos meus treinamentos Scrum e Kanban tento focar ao máximo os porquês de cada prática e um dos pilares da agilidade que na minha opinião entrega mais resultados é a auto-organização da equipe. Enquanto falava com aquele gestor sobre Scrum e Agile em uma conversa informal ele com grande franqueza disse:
“Não é que eu não acredite em auto-organização e autonomia. O ponto é que a primeira vez que meu filho pediu para ir sozinho na padaria, eu deixei, porém, fiquei acompanhando de longe na rua, me escondendo nos postes, para garantir que ele não iria fazer nenhuma besteira…”
A metáfora desde gestor retrata exatamente o que passa pela cabeça da liderança de uma empresa fazendo uma transição ágil, e considero isso completamente normal. Mudanças em processos é como aprender a andar de bicicleta sem rodinha. Com rodinha você está estável, mas a eficácia é baixa. Sem rodinhas o medo de cair é maior, mas os benefícios pagam. Neste ano de 2012 eu tenho apresentado em treinamentos, palestras e apresentações em empresas um pequeno quadro explicativo sobre gestão e o que gestores acreditam. Não é nada elaborado e nem novidade, porém, acredito que isso possa te ajudar a entender melhor sobre pontos de resistência que provavelmente possam existir na sua equipe, departamento ou empresa.
Cada quadro possui um conceito no topo e um “mantra” no texto centralizado. Geralmente o “mantra” são frases de líderes e gestores que escuto por aí. Note que estes conceitos e mantras eu tenho observado em todo lugar, não somente nas empresas que visito – na Igreja, na fila do banco, num supermercado, na reunião de pais da escola, na sua família, em todos os locais você poderá identificar pessoas Teoria X, favorecendo Silos e Causalidade. Um ponto importante é que esta figura é uma simplificação proposital de tópicos altamente co-relacionados e que podem até se confundir entre si. Espero que com o pouco que eu apresentar aqui você tenha apetite para estudar mais esses intrigantes assuntos. Alguns deles vão clarear suas ideias sobre várias práticas ágeis. Vamos começar pelo básico.
Teoria X e Teoria Y
Infelizmente a maior razão para uma empresa contratar um gerente é para “controlar as pessoas”, cuidar para que projetos “não parem” e cobrar que tarefas sejam cumpridas no prazo. Muitas vezes um gerente é contratado deliberadamente para empurrar um sistema de trabalho. A visão de uma pessoa Teoria X é que pessoas precisam de subordinação, isto é, sem alguém passando tarefas, criando entendimento e cobrando prazos, o trabalho não flui. Um gerente X usará a pressão, o medo, a coerção e a punição para que as pessoas trabalhem. É comum um líder Teoria X dizer que sem ele nada daria certo. É a mentalidade básica de um sistema de trabalho escravista.
Há algumas semanas atrás participei de uma reunião na escola das minhas filhas. Uma delas está no 4o. ano (antiga 3a. série) e o assunto que a professora queria tratar com os pais era sobre a autonomia do aluno ao fazer a lição de casa e “a aprender a estudar sozinhos”. Achei o assunto muito interessante e alinhado com o que acredito para o ensino. Porém, antes de entrar neste assunto, a professora pediu que os pais falassem sobre as suas expectativas e suas características no trato com os filhos com relação aos estudos. Mais de 60% dos pais de alunos presentes se classificaram como exigentes e entre eles a maioria acreditava que seus filhos não fariam a lição de casa sem um acompanhamento intensivo. O que você acha sobre esses pais e qual é a mensagem que eles estão passando para os filhos? A Teoria X está presente em todos os locais, infelizmente.
Já a Teoria Y acredita que as pessoas tem o poder da auto-motivação, SE colocadas em um ambiente onde elas possam participar e ser co-responsabilizadas pelas metas e resultados com liberdade. Gerentes Y abdicaram o controle rígido sobre o processo em prol de melhores resultados que só a criatividade, a inovação e a participação ativa das pessoas nas decisões podem proporcionar. Gerentes Y jamais usam medo, pressão ou punições, ao invés disso, eles tentam continuamente aumentar o grau de liberdade, criando uma atmosfera de trabalho que favoreça as pessoas a correrem riscos e a errarem com segurança, tornando-as assim, responsáveis.
Motivação Extrinsica e Intrinsica
Uma vez estava no Sea World em Orlando vendo um show de golfinhos. Golfinhos são animais muito espertos. Eles faziam truques espetaculares, mergulhando, contracenando com os treinadores, dando piruetas a 3 metros de altura. Se você já viu um show desses notou que por todos os cantos há baldes com sardinhas. E cada manobra que o golfinho faz ele ganha uma recompensa. O golfinho não deve entender o que são aplausos, fotos e também não sabem diferenciar uma platéia cheia de uma vazia. O golfinho sequer deve gostar de fazer o espetáculo, mas ele sabe que fazendo as acrobacias ele ganha um peixe. Tem empresas e pessoas que acreditam que seres humanos tem o mesmo comportamento. É uma mentalidade do tipo “entregue o projeto X que eu te dou o bônus Y” no final do ano. Isso se chama motivação extrinsica, pois é um estimulo externo que fará o trabalhador cumprir objetivos e prazos.
Nos últimos 4 anos de meu trabalho não teve uma única empresa grande onde o fator “bônus” não estivesse presente, geralmente para atrapalhar. Para falar a verdade, em algumas equipes o foco da transição Agile era entregar mais projetos (e assim, mais bônus). Entre todas as idiotices empresariais que já ví, a empresa pensar “tenha o comportamento X que eu lhe darei o presente Y” é o mais estúpido de todos. Sei que a maioria de vocês – que recebem gordas gratificações e bônus no final do ano – não vão concordar, mas o problema maior da motivação extrinsica são os efeitos colaterais, muitas vezes ocultos, que ela traz a reboque. Vou dar um exemplo:
Uma certa empresa usava desenvolvimento cascata, alta departamentalização e bonus baseados em metas de entrega de projetos. Quando havia um projeto a TI e a área usuária iam a uma comissão pedir um caminhão de dinheiro, mostrando os benefícios e os objetivos. Com o dinheiro no bolso tinha-se uma meta e um bonus para cada profissional atrelado ao projeto. O que dava o projeto como entregue era um documento assinado pela área usuária que garantiria o bônus de todo mundo. O que geralmente acontecia era os projetos não serem entregues no prazo e na qualidade esperada pelo usuário (lógico, era cascata), porém, a TI e a área usuária entravam em conchavo para não perder os bônus: a área usuária assinava o documento de entrega do projeto e juntos iam mais uma vez à comissão pedir mais dinheiro para a fase 2 do projeto (que sorrateiramente era para consertar a “fase 1″). Nessa fase 2 mais bonus eram garantidos. Este é um entre muitos exemplos. Leia a opinião de Deming sobre o assunto.
Motivação Extrinsica também está presente nas nossas vidas desde a infância: respeite os mais velhos e te dou uma bicicleta, arrume seu quarto e te dou um video-game, faça a lição de casa e te dou uma estrelinha no caderno… Fatores motivadores externos ao objetivo principal tem o poder de mudar o foco das pessoas do que é importante para a recompensa. A bicicleta, o video-game e a estrelinha passam a ser o alvo, ao invés de ter boas maneiras, ser organizado e aprender. Quando vejo empresas dando bônus, presentes, soando sinos e dando promoções por metas me questiono: entregar valor para os clientes não motiva os trabalhadores o suficiente?
Já a Motivação Intrinseca é simplesmente gostar de fazer o trabalho pelo puro prazer na própria atividade sendo desempenhada. Essa motivação é interna – a pessoa faz o trabalho por simplesmente estar envolvida nele, achar ele importante ou por estar aprendendo coisas que julga interessantes. Motivação intrinsica é possível em um ambiente que as pessoas tenham liberdade para experimentar e explorar sua criatividade. Um video meio batido, mas que mostra isso claramente é o famoso TED de Dan Pink (on the surprising science of motivation):
Note que neste video Daniel Pink fala sobre a questão “salário” e diz também que recompensa funciona, mas não no trabalho do conhecimento. O ponto que defendo é que não é a presença ou ausência do bonus que fará o projeto ser entregue. Um vendedor motivado instrinsicamente não fará vendas para bater metas, ele buscará clientes pelo prazer de lhes vender o produto certo para o problema certo. Um gerente de projetos motivado instrinsicamente não liderará projetos motivado por bonus, ele terá prazer em entregar valor para seus stakeholders. Um aluno motivado intrinsicamente não irá estudar por notas ou pela pressão de passar de ano, mas sim, pela curiosidade do aprendizado.
Silos, Hierarquias e Multidisciplinaridade
Teve um cara na história da Administração chamado Frederick Taylor. Taylor era um cara brilhante. A principal mensagem dele era que empresas deveriam ser administradas de forma científica, fazer as tarefas de forma racionalizada e com o máximo de economia no esforço e tempo. Taylor inaugurou uma Era que deveria ter enterrado o “senso comum” ou o “feeling” na gestão. Infelizmente Taylor fazia uma certa divisão intelectual rígida entre gestores e trabalhadores, e isso fez com que seu nome fosse jogado na latrina. Muitos amam Henry Ford e odeiam Taylor, o que na minha opinião faz muito pouco sentido já que Ford é o maior case de sucesso de Taylor. Hoje a palavra Taylorismo é odiada em qualquer roda de discussão sobre gestão, e nessa mesma roda todos vão amar a Toyota. Irônico isso, pois a Toyota aplica o Taylorismo muito bem.
Que ninguém se engane, Taylor melhorou a ciência da administração consideravelmente. Sem Taylor eu acredito que não existiria o modelo Ford de produção em escala, que nos levaria ao TPS mais tarde. Tudo o que Taylor falou fazia sentido, NO CONTEXTO QUE ELE ESTAVA INSERIDO. Esse contexto era a MANUFATURA durante a expansão da Revolução Industrial pelo Mundo. Taylor pregava um conceito chamado “divisão e especialização do trabalho”. Dizia ele que se um trabalhador tem seu cargo atrelado à tarefa de apertar parafusos, ele irá apertar parafusos, e ficará cada vez melhor nisso.
Mais de 100 anos se passaram desde que Taylor publicou seu livro “Princípios de Administração Científica”. Neste período inventamos a lâmpada, o telefone, o automóvel e o avião. Sofremos duas Grandes Guerras e a Guerra Fria. Criamos a bomba-atômica, os antibióticos, os contraceptivos… Inventamos o consumo, o Marketing, a Informática, a Internet e as Mídias Sociais. O século XX foi uma explosão cambriana de ideias e valores.
Tudo muito legal e interessante neste mundo, porém, todas as vezes que você vê uma empresa de tecnologia que deveria viver de inovação e está segmentada em departamentos, áreas e hierarquias, basicamente você está seguindo o modelo de Taylor, que é direcionado para MANUFATURA de 100 anos atrás. James Womack no seu livro Lean Thinking, diz que “a mente humana infelizmente tende a agrupar tarefas correlatas. Se é parecido, vamos agrupar”. Na visão de Womack, somos cascateiros por natureza e infelizmente quando se diz “grade curricular numa escola” o pensamento é o mesmo.
Por que as coisas são assim? Na Teoria X é importante caçar os culpados caso alguma coisa esteja errada. A vida de um gestor X é encontrar e encaminhar problemas aos seus responsáveis. A Empresa não vende? Culpa do gerente de vendas. Temos defeitos? Culpa do gerente de desenvolvimento? O gerente de desenvolvimento não dá conta? Cria-se o departamento de testes (e sua gerência). Hoje, dentro de uma empresa de tecnologia temos analistas de negócio, analistas de sistemas, desenvolvedores (as vezes separando-se front-end/back-end), web designers, testers, arquitetos, gerentes de projetos… Cada um com sua função e responsabilidade. Palmas para Taylor.
O ponto que quero chegar não é contra qualquer tipo de especialização, mas sim, que a fronteiras se abram. Gosta de ser um web designer? Ótimo, saiba o impacto do seu trabalho junto com os desenvolvedores e o marketing, se precisar um dia você terá que testar o software. É um vendedor? Entenda como seu produto é feito e colabore com todas as outras equipes. É um gerente? Não crie silos entre as áreas. Favoreça a comunicação e a integração. Uma das maiores vitórias recentes que tive em trabalhos de consultoria é conseguir aproximar as áreas e abrir canais de comunição que antes eram trincheiras. Uma transição usando Kanban facilita neste aspecto.
A Multidisciplinaridade respeita a diferença entre as pessoas, seus gostos e suas capacidades. O objetivo maior é formar um grupo homogêneo que busca um objetivo compartilhado, geralmente, entregar valor para algum cliente ou mercado em particular. Essa é uma meta real, e não as metas parciais muitas vezes inúteis de um departamento isolado. Os objetivos compartilhados puxarão a organização de toda a empresa. A teoria do Scrum é baseada em um time multi-disciplinar. Cooperação entre áreas diferentes do conhecimento humano (matemática, física, biologia, informática) melhorou muito a Ciência nos últimos 50 anos.
Causualidade, Determinismo e Sistemas Complexos
Antes de falar sobre Causalidade e Determinismo quero que você responda as seguintes perguntas:
- Como solucionar o problema da corrupção no Brasil?
- O problema do transito nas grandes cidades é causado por ________.
- Qual é a causa do problema da miséria no mundo?
- As atuais crises financeiras são resultado da ação ou falta de ação de quem?
- Qual é o problema atual da sua empresa e qual é a causa disso?
Você tem resposta a todas essas perguntas? Causalidade e Determinismo também está presente neste pequeno exercício. Causalidade está presente em todos os lugares, nas conversas que você tem com sua família, numa roda de bar, nos telejornais… Causalidade é a simples ideia que “para todo problema X, existe uma solução Y”. Para todo e qualquer evento X existe a causa Y. Você pensa assim? Causalidade é a resposta pronta que vem nas nossas cabeças quando deparamos com um problema. Causalidade é a capacidade do ser humano em ter opinião sobre tudo. Causalidade é retratada pela busca de gestores por modelos X, Y e Z como receitas de bolo: “Funcionou na empresa tal? Ah! Então vai funcionar aqui também…”. Já participou de uma reunião onde havia uma discussão sobre o que era “certo” se fazer? Causalidade é uma corrente filosófica da ciência. Para a Causalidade, todo e qualquer evento/efeito teve seu evento/causa. Se o software tem bugs (efeito) deve existir uma explicação e um culpado (causa), comumente de forma linear. Causalidade é válida para alguns fenomenos simples observados na física ou até na biologia, porém, nem todos os acontecimentos podemos explicar por simples causa e efeito. Nos ultimos 50 anos cresceu uma forma diferente de pensar.
O Complexity Thinking é uma outra corrente filosófica da ciência que estuda basicamente sobre Sistemas Complexos. Sistemas Complexos é um assunto amplo, mas basicamente, esta corrente surgiu para auxiliar em situações onde a Causalidade e Determinismo não se encaixam. Existem áreas do conhecimento onde as relações entre causas e efeitos não são claras. É o comportamento que temos como exemplo no clima, na economia, em vários fenomenos biológicos, em redes sociais… A expressão “o futebol é uma caixinha de surpresas” é outro exemplo. Conhecimento sobre complexidade é raro. A mentalidade determinista domina a maioria das discussões que participo. O problema é que um grupo de pessoas trabalhando juntas, buscando um objetivo, como uma equipe de desenvolvimento de software, ou de qualquer outra área do trabalho do conhecimento, é um Sistema Complexo.
A principal característica de um Sistema Complexo é sua imprevisibilidade inerente. Os eventos que ocorrem num ambiente governado pela complexidade não possui relações claras entre causa e efeito, e nesta situação, qualquer tentativa de usar Causalidade gerará resultados desastrosos (assistiu Tropa de Elite I e II?). Um gerente X decide bonificar (ou castigar) para motivar e departamentalizar para achar o problema de forma determinista simplesmente porque desconhece Complexidade, e sonha em achar as relações entre causa e efeito dentro de um ambiente onde isso é impossível. Com isso ele definirá péssimas políticas para governar o comportamento do processo. Atônito ele mergulhará o sistema no caos. Um Sistema Complexo não aceita se encaixar nas suas percepções superficiais sobre ele. O sistema não respeita seus planos e suas metas. Esta é a razão de não tentarmos estimar prazos, esforços e a qualidade dentro do trabalho do conhecimento. “No Agile o projeto não tem data final” – já ouviu essa expressão? O fato é que o Agile reconhece a complexidade e lida com ela de forma a entregar mais valor, enquanto outros métodos tradicionais ainda estão na falácia da causalidade.
Para gerenciar um Sistema Complexo a causalidade não funciona. Isso é um ponto de resistência muito forte nas empresas. É um mito você pensar que gestão é fazer as pessoas terem o comportamento que você deseja. O mantra de quem conhece Complexidade é “você só saberá se está certo ou não depois de tentar”. Em um ambiente complexo é impossível saber se uma tentativa de mudança vai dar certo antes do fato. Essa é a razão do Scrum ser fundamentado em Transparência, Inspeção e Adaptação. Essa é a razão do Kanban sugerir Gestão do Fluxo, Políticas Explicitas e Modelos de Melhoria. Em uma equipe do trabalho do conhecimento não há boas práticas. Neste ambiente temos práticas emergentes. O modelo Cynefin pode te ajudar a compreender o domínio que você se encontra (se é simples, complicado, complexo ou caótico).
O objetivo deste artigo é chamar a refletir sobre fundamentos e explicar alguns porques da resistência natural a mudanças que temos em transições para processos ágeis em pequenas, médias e grandes empresas. É possível mudar a mentalidade e cultura de uma empresa? Sim, geralmente isso é feito passo a passo, com a equipe e a liderança. O meu primeiro passo tem sido convencer as pessoas a experimentarem os benefícios de um Sistema Puxado por algumas semanas. Quem tenta não se arrepende. Em algumas empresas a mudança pode acontecer em alguns meses. Em outras, em alguns anos.
Deixo algumas perguntas para você pensar: Quando você assiste o programa “O Aprendiz” qual mindset você vê? Quando filmes retratam um gerente como ele é? As promessas que um político faz em campanha demonstra seu conhecimento sobre Complexidade? O padrão da escola (ou da Igreja) onde um fala e muitos obedecem se parece com qual estilo de gestão? As certificações Scrum se aproximam da Gestão Moderna? Na sua empresa você vê Teoria Y, Motivação Instrinseca e Multi-disciplinaridade?
Está claro agora por que brasileiros gostam mais de cachorros do que de gatos?
Alberto é um gerente de sistemas de informação de uma empresa. Sob sua responsabilidade está um departamento de TI com 35 pessoas entre analistas de negócio, gerentes de projeto, desenvolvedores, testers e sysadmins. Alberto vive um problema muito comum: seus usuários estão completamente insatisfeitos com a TI, as soluções são sempre entregues com atraso, a qualidade do trabalho é sofrível e as equipes estão desmotivadas. Alberto tenta gerenciar um sistema caótico. Este geralmente é o cenário que costumo enfrentar quando inicio uma consultoria para melhoria de processos. No rápido passeio que faço para verificar como as equipes trabalham (Gemba Walk) arrisco dizer que em 95% das empresas que visitei a causa raiz de muitos desses problemas é que o sistema é EMPURRADO.
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:
Semana 1
Semana 2
Semana 3
Semana 4
Trabalhos concluídos
12
4
20
10
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:
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!
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 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:
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!
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.
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!
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:
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.
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.
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:
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)
É com grande prazer que anunciamos que neste mês de maio a Aspercom foi selecionada como a primeira empresa brasileira a integrar a 
