Durante a conferência Lean Kanban Central Europe, Alexander Gerber e Martin Engel falaram sobre suas experiências de mais de dois anos aplicando Kanban na SAP. Eles mostraram como suportaram o departamento de desenvolvimento de uma empresa de software de grande porte com a implantação de lean e de processos ágeis. Esse é um dos casos de estudo sobre lean e kanban da Central Europe sobre o qual foi reportado pela InfoQ.com no começo do ano.
O InfoQ.com entrevistou Alexander Gerber e Martin Engel sobre como o Kanban foi introduzido e recebido dentro da SAP, sobre as abordagens de seus treinamentos e as experiências das equipes com as práticas de Kanban.
InfoQ.com: Nas apresentações iniciais do Lean Kanban Central Europe 2011 sobre Kanban software vocês falaram sobre como começaram a iniciativa do Kanban na SAP. Vocês citaram David Anderson: "A essência de iniciar com Kanban é fazer as menores mudanças possíveis". Várias organizações de grande porte costumam fazer extensos programas de mudanças. Como o Kanban foi recebido pela SAP?
Alexander Gerber e Martin Engel: Enquanto não tínhamos um grande programa de mudança para introdução do Kanban na SAP, nós tivemos nosso "Big Bang" bem antes disso: nossa introdução ao Pensamento Lean e aos métodos de Desenvolvimento Ágil, incluindo Scrum, iniciou em 2008. Essa foi uma importante base para a introdução ao Kanban - que nós começamos 3 anos mais tarde, por volta de 2011.
Alinhados com os princípios "inicie com o que você faz agora", "mude o mínimo possível" e "comprometa-se com a evolução, faça mudanças incrementais" nós não fizemos nenhum lançamento em grande escala, propondo Kanban em todas as equipes da nossa organização, mas oferecemos o Kanban como uma abordagem alternativa para certos tipos de times - aqueles concentrados em manutenção ou operação, por exemplo. Para a maioria dos times da nossa organização, concentrada no desenvolvimento, nós continuamos a propor Scrum como o framework padrão de processos.
No geral, nossa proposta de adoção do Kanban foi bem recebida pelas equipes. Nós já treinamos aproximadamente 50 times, e vemos um fluxo contínuo de novos pedidos por treinamentos de Kanban. A propósito, nosso "Lean and Agile Core Team" não tem sido o único caminho para o Kanban dentro da SAP: em nosso grande ecossistema existe um número relevante de times que encontraram seu caminho para Kanban por eles mesmos e aprenderam sobre Kanban de outras fontes, como por exemplo em conferências. Um fator de sucesso tem sido as regulares trocas de experiência do Kanban que nós estamos organizando para todos aqueles na SAP que estão se interessando pelo Kanban.
InfoQ: Vocês usaram Kanban para começar a melhorar a partir de onde vocês estavam. Equipes em organizações maiores podem diferir nas práticas que elas usam, e muitas vezes há diferenças nos níveis de experiência, cultura etc. Como o programa Kanban de vocês lidou com isso?
Alexander Gerber e Martin Engel: Isso toca em um aspecto importante de nossa abordagem de treinamento: de um lado, promovemos informação sobre o Kanban da maneira como ele foi padronizado por David Anderson; então aqui nós estamos capacitando um "Kanban by the book", usando os mesmos princípios e práticas para todos. Por outro lado, a arquitetura de três camadas que estamos oferecendo em nossos treinamentos, em particular nossos "Workshops de Kanban", libera espaço suficiente para necessidades especiais e interesses de cada time que nós estamos trabalhando. Então nós não estamos impondo a mesma solução para todos os times. Nós explicamos isso em maiores detalhes quando explicamos o treinamento de Kanban que oferecemos.
Como resultado, estamos propondo fortemente alguns fundamentos para as equipes, como a realização de Retrospectivas regularmente, encontros para curtos alinhamentos, ter um facilitador na equipe, e assim por diante. Mas também somos bastante liberais em relação aos detalhes de como essas coisas são implementadas. Por exemplo, a maioria das equipes vai iniciar a sua transição Kanban com o papel de um Scrum Master, que depois evolui gradualmente para o papel de um facilitador Kanban; a respeito de como essa evolução é feita em detalhes, vai depender da equipe e, freqüentemente, até mesmo as designações das funções originais (como Scrum Master) permanecem as mesmas. Da mesma forma, a representação do quadro de fluxo do trabalho, políticas de processos e assim por diante geralmente são muito específicas para cada equipe.
Deste modo, estamos tentando refletir os níveis de experiência e as diferentes culturas e práticas que se desenvolveram na nossa grande organização de desenvolvimento.
InfoQ: O objetivo da equipe de mudança era realizar uma "implementação estável e duradoura de Lean e métodos ágeis". Vocês alcançaram seus objetivos? O que vocês fizeram para alcançá-los?
Alexander Gerber e Martin Engel: Uma maneira de pensar sobre esta questão poderia ser: "O que os desenvolvedores em nossas equipes estão falando?" Pensando cerca de cinco anos atrás, quando começamos a introduzir o pensamento Lean e o Scrum, havia um grande número de preocupações manifestadas pelos integrantes da equipe, e custou algum esforço do lado de nossas equipes Ágeis e Lean (e as demais equipes) para responder às perguntas e para lidar com estas preocupações. O que tivemos de nos esforçar em épocas anteriores pode agora ser totalmente tido como certo: em muitas partes da nossa organização de desenvolvimento as pessoas partilham uma língua comum, e eles têm um conjunto de valores comuns, tanto quanto ao Lean como aos métodos ágeis.
Por exemplo, hoje em dia a maioria das pessoas vai concordar que é altamente desejável para uma equipe ter priorizado e estimado o product backlog como base do seu trabalho. Isso é algo que não será perdido a curto prazo ou mesmo a médio prazo, de modo que este pode ser visto como um indicador de mudança sustentada de fato. Após mais de cinco anos para a transformação Lean na SAP, as ideias e metodologias de Lean/Agile, incluindo Kanban, parecem estar firmemente ancoradas nas equipes de desenvolvimento, e, mais importante, nas mentes das pessoas: elas se tornaram "parte do nosso DNA". Há até mesmo uma atração cada vez maior por Kanban em equipes de não-desenvolvedores, tais como as equipes que lidam com o suporte ao produto, por exemplo.
Como conseguimos isso? Um fator certamente foi que nós "praticamos o que pregamos". Então, não apenas defendemos o Scrum e a Melhoria Contínua, também empregamos essas ações em nossa equipe. Fizemos o mesmo com relação ao Kanban, é claro.
Outro importante fator de sucesso foi que trabalhamos tanto com a gestão como com os membros da equipe ao mesmo tempo. Esta combinação de abordagens top-down e bottom-up certamente nos ajudaram no caminho; de um lado com a coleta de experiências e estabelecimento de ciclos de feedback sobre o que ensinamos em treinamentos, e do outro lado com a obtenção de um forte apoio de gestão que você também precisa de uma organização tão grande como a nossa.
InfoQ: Vocês poderiam explicar como usaram retrospectivas para melhorar o quadro Kanban?
Alexander Gerber e Martin Engel: Nós normalmente usamos uma abordagem baseada nas sugestões de Esther Derby/Diana Larsen em seu livro sobre retrospectivas ágeis (Agile Retrospectives). Normalmente, temos que fazer uma retrospectiva a cada duas semanas, mas não somos totalmente rigorosos sobre isso, por isso às vezes cancelamos ou então passamos ao ar livre desfrutando um sorvete. Nosso objetivo nas retrospectivas sempre foi de identificar pequenos pontos de melhoria e definir os itens claros para ações e boas decisões.
Às vezes, nós preparávamos nossas reuniões de retrospectiva de modo especial (por exemplo, fornecendo dados específicos do nosso gráfico de Kanban em execução), às vezes nós apenas coletávamos de uma forma "sarcástica" o que há na cabeça de todos. Nós então agrupamos e priorizamos itens.
Às vezes, as ações de melhoria eram facilmente encontradas, às vezes usávamos técnicas como os "5 Porquês". Mas também usávamos as reuniões de retrospectiva como rodadas de discussão aberta (não mais de 60 minutos), onde todo mundo podia levantar preocupações, sem chegar a tarefas a serem acompanhadas. Pelo "estado de espírito da equipe", essas reuniões não estruturadas vez ou outra também se mostraram muito benéficas.
InfoQ: Como foi que vocês abordaram o treinamento Kanban? Por que vocês fizeram desta forma?
Alexander Gerber e Martin Engel: Lançamos o treinamento Kanban como uma oferta para as equipes que buscavam uma alternativa ao Scrum (por exemplo, as equipes com uma alta carga de manutenção, administrativa ou outras equipes não constituídas por desenvolvedores). Então, nós não fizemos - como fizemos para o treinamento de Scrum - o lançamento de uma implementação estruturada com plano de treinamento detalhado e tudo mais. Nós confiamos na propagação boca-a-boca, e por outro lado, o treinamento Kanban estava acessível em nossos canais de treinamentos convencionais. Então foi assim que as pessoas descobriram mais sobre nossos treinamentos de Kanban.
O treinamento em si tem um triplo objetivo: como ponto de partida, oferecemos duas horas de uma sessão de informação (como nós chamamos esta fase) onde lidamos com os tópicos básicos sobre Kanban como sua história (de onde ele vem, quem foi seu "inventor"), as práticas básicas bem como os princípios para a introdução do Kanban. Usamos um formato de treinamento interativo, que se baseia no que Sharon Bowman escreveu em seu livro "Training from the BACK of the room!".
O objetivo da sessão de informação é dar às equipes a base para decidir se querem começar a aplicar Kanban ou não. Caso queiram, oferecemos um workshop de um dia, onde passamos a maior parte do tempo trabalhando nos artefatos específicos para o time em particular (como aparentemente é o seu fluxo de trabalho, como ele pode ser modelado com um quadro Kanban, como é que uma versão inicial de suas tarefas devem ser, quais métricas utilizar etc...) Neste workshop, o objetivo é apoiá-los em direção a um ponto onde eles sejam capazes de começar a aplicar Kanban imediatamente após o workshop.
Ao final, oferecemos alguma mentoria após o workshop, para ajudá-los a superar os primeiros obstáculos. Isto pode significar participar de suas reuniões, moderar retrospectivas, atuar como ponto de contato para facilitadores das equipes e assim por diante. Em suma, este "triplo objetivo" parece ser útil, uma vez que dá às equipes uma abordagem de baixo investimento para descobrir se o Kanban iria ajudá-los no seu contexto específico ou não.
InfoQ: No final da sessão que vocês apresentaram várias práticas comprovadas. Quais são essas práticas, e como elas ajudaram vocês?
Alexander Gerber e Martin Engel: Como já mencionado, retrospectivas eram uma das práticas mais importantes e úteis. Além disso, utilizamos um estatuto da equipe para a descrição de regras, normas e acordos transparentemente e que fica sempre visível (o estatuto foi impresso e colocado na parede da sala de cada equipe). Isso nos ajudou a mantermos nossos acordos e decisões, embora, isso de alguma forma sempre pareça um desafio (fazer realmente o que você decidiu...). De vez em quando, passávamos algum tempo em um local externo para fazer workshops que exigem um maior aprofundamento, por exemplo, quando precisamos decidir nossos objetivos e estratégia para o próximo semestre. Depois combinamos isso com o que chamamos de uma "retrospectiva de grande escala": o que significa que não só olhamos para trás para o que aconteceu durante as últimas duas semanas, mas quais foram os eventos mais importantes, questões e destaques no último ano.
Outra coisa que nós tentamos recentemente (e repetimos duas vezes) foi uma prática recomendada pelo consultor de gestão Fredmund Malik, que ele chama de "redução sistemática dos resíduos" ("Systematische Müllabfuhr", em alemão). A ideia é: para que um organismo sobreviva, livrar-se do "lixo" é extremamente importante. Isso vale também para as equipes e outras unidades organizacionais.
Assim, poderíamos olhar para cada atividade que estávamos buscando e nos questionar: quais dessas atividades não precisaríamos começar a fazer novamente? Portanto, não é sobre a descoberta de erros do passado, mas criticamente julgar o que você faz atualmente usando o seu conhecimento atual. Nós fizemos isso uma vez no início de 2013 em uma reunião de 3 horas, como parte do processo de planejamento. Isso provou ser realmente um desafio! É extremamente difícil parar deliberadamente de fazer as coisas, por muitas razões. Mas, novamente, é a base para toda priorização séria.
Além de tudo isso, nós também aplicamos algumas das práticas usuais do Kanban como rastreamento do WIP com um gráfico de Cumulative Flow ou de Lead Time para os nossos itens de trabalho com um gráfico de execução, apenas para citar alguns exemplos.