Scrum e/ou Kanban – Por onde começar?

Desde 2009, quando acrescentei Kanban a minha caixa de ferramentas para auxiliar empresas e equipes em boas práticas de gestão e engenharia em TI, uma dúvida se tornou muito frequente: Scrum ou Kanban? Scrum é uma das ferramentas que uso desde 2007 e ainda apresenta um franco crescimento no mercado, surfando a onda Agile. Kanban também tem apresentado um crescimento extraordinário no mundo e no Brasil, mas ainda com mercado pequeno comparado ao Scrum. O objetivo desse post é desmistificar qual método é mais indicado para sua empresa ou equipe, e como base para este artigo, conto com a experiência da Aspercom usando ambos os métodos em mais de 140 equipes em empresas como SulAmerica Seguros, Buscapé Company, SPC Brasil, 7Prods, AIX, Localiza Rent-a-Car, Oppa, TJPE, Central Nacional Unimed entre outras.

 

 

Scrum e/ou Kanban: Foque-se na transição!

Como disse anteriormente, Scrum atualmente é o método mais buscado pelo mercado, impulsionado principalmente pelo marketing das certificações. Projetos de implantação pipocam aqui e ali e o movimento ágil, cujo maior precursor é o Scrum, cresce em outsourcing, ISVs e dentro de departamentos de tecnologia de grandes companhias, inclusive no Governo. Eu concordo que o Scrum melhora o ambiente dessas equipes e empresas com resultados melhores, mais rápidos, principalmente pelo mecanismo de feedback e adaptabilidade que os valores, práticas e papéis do Scrum pregam. Olhando a estrutura do processo Scrum não há dúvidas que ele é desejável para a maioria dos ambientes, porém, quando uma empresa diz que quer usar Scrum geralmente ela é uma obesa mórbida, que tem mentalidade de gordo, gritando para si mesma que quer correr uma maratona. O Scrum é muito bom, mas o fato do framework Scrum ser simples, isso não torna a implantação deste processo simples. Antes de optar pelo Scrum, pense como será a transição para o Scrum e também uma estratégia de saída caso as coisas não saiam como você esperava.

Quais são as resistências naturais ao Scrum?

O Scrum é um framework ágil de gestão e desenvolvimento de software baseado em transparência, inspeção e adaptação. Um líder servidor, o ScrumMaster, é o guardião do processo e fomenta a inovação e a auto-gestão de uma equipe multi-disciplinar que desenvolve um produto ou projeto guiado por um Product Owner. O processo de produção ocorre dentro de ciclos iterativos e incrementais curtos chamados de “Sprints” que geralmente duram de 1 a 4 semanas. Cada Sprint entrega um conjunto de funcionalidades prontas para consumo – potencialmente implantáveis. Pergunte a qualquer CIO e ele vai achar isso espetacular, porém, ele deslumbra um maratonista treinado, e não a estrutura obesa mórbida que ele tem. Um mito que sem se espalhado no mercado é que o Scrum por si só é capaz de tornar uma estrutura obesa mórbida num maratonista num curto espaço de tempo. Infelizmente, isso não é verdade. A transição para o Scrum, se sua empresa é obesa mórbida, é uma Via Crúcis. Não tem almoço grátis.

Uma das características do Scrum é o realismo trazido por ciclos de feedback curtos. Essa característica é importante para que o mecanismo de inspeção e adaptação do Scrum funcione promovido principalmente por retrospectivas a cada ciclo. O problema desse realismo é que ele mostra a obesidade mórbida da maioria dos ambientes empresariais. Para iniciar a transição para o Scrum a maioria das empresas que tive contato demonstram um otimismo incomum – elas pensam: “Vamos treinar as pessoas, escolher um projeto piloto, juntar programadores, analistas e testers em uma única equipe, eleger o ScrumMaster, o Product Owner e começar a rodar Sprints”. Esse pensamento simplista tem algumas armadilhas escondidas.

Como citei, o Scrum é ótimo no papel, porém, para o Scrum funcionar de forma eficaz a organização, seus gestores e as equipes devem concordar e suportar algumas premissas iniciais para que o processo entregue aquilo que ele promete. Se você pretende usar Scrum pergunte a si próprio as seguintes questões:

 

A – Sua empresa concorda em mudar o ciclo de vida dos projetos para timeboxes de 1-4 semanas?

B – Sua organização concorda sem problemas em juntar divisões funcionais clássicas como analistas, programadores, testers, arquitetos em um único time?

C – Sua empresa concorda em abrir mão de hierarquias rígidas tradicionais para uma estrutura mais horizontal?

D – A liderança concorda em abrir mão do comando e controle, empoderando essa equipe multi-disciplinar a se auto-organizar e auto-gerenciar o trabalho?

E – Escolher um líder-servidor para atuar como ScrumMaster é algo fácil na sua organização ou vai gerar muita discussão?

F – O papel de Product Owner é facilmente identificável na sua organização? O cliente está “próximo”?

G – Sua empresa está disposta a uma queda inicial de produtividade devida a curva de aprendizado e a inspeção e adaptação?

H – Sua empresa está disposta a abrir mão dos atuais mecanismos de controle (custos, prazo, escopo) para adotar a forma ágil de controlar um projeto?

 

Se você respondeu “Sim” a todas essas questões eu diria que sua empresa está próxima do Scrum, e a transição será suave. Se você respondeu alguns “Não”, eu diria que a sua transição é mais arriscada, pois a maioria das perguntas seria o mínimo necessário que eu enxergo para que o Scrum seja implantado.

Mais uma vez, o Scrum é ótimo, e tendo trabalhado com esse método há mais de 7 anos digo que as equipes que o implantaram estão muito melhores que no paradigma anterior (geralmente cascata, sem ciclos de feedback), porém, esse pequeno questionário eu montei para demonstrar que as restrições que a organização tem que concordar para começar a usar o Scrum são duras. O Scrum precisa de uma revolução ou mudança disruptiva no pensamento (Kaikaku) para ser implantado. Quanto mais “Nãos” você respondeu no questionário maior será a resistência das pessoas a utilizar o Scrum. O foco dessa resistência pode ser tanto gestores quanto membros das equipes ou qualquer outro “orgão regulador” que a empresa possua (como Comitês de Mudança/Segurança/Arquitetura, Departamento de Processos, PMO ou outros).

Neste momento podemos afirmar que o Calcanhar de Aquiles dos Métodos Ágeis é exatamente o problema descrito no parágrafo anterior. Trocando em miúdos: Métodos Ágeis não possuem um modelo de transição convincente. O desafio que temos em mãos quando falamos a respeito de processos é melhorar um ambiente EXISTENTE, que atualmente pode ser disfuncional, dispendioso e insustentável. Muitas vezes fundamentalistas no trabalho de implantar Agile – podendo ser uma iniciativa interna na empresa ou externa via uma consultoria – pura e simplesmente dizem que o que a empresa faz hoje é “errado” e os métodos ágeis são o “certo”. Com essa mentalidade a norma da implantação Agile é “fazer uma transição na porrada” (sim, eu já ouvi isso de um consultor). A falta de um modelo de transição consistente no Agile o faz refém do modelo “não Agile” é errado e “Agile” é o certo, levando o assunto para uma questão moral e não racional. O problema dessa abordagem é que dizer para as pessoas que elas são “erradas” traz um grande impacto emocional e resistência a mudanças. Faça um teste com sua esposa(o) ou namorada(o) e diga que ela(e) está errada(o) em algum ponto. Pergunta: com isso você ganha empatia ou resistência dela(e)? Geralmente as pessoas resistem ou racionalizam quando são apontados os seus “erros” ou diferenças. Idealizar um processo no papel, longe da realidade do que acontece no dia-a-dia das equipes, mesmo que seja um processo largamente utilizado e com vasta literatura, é um exercício fútil.

Um ponto que as pessoas precisam entender é que os autores do Manifesto Ágil – a julgar pelas suas publicações da época – não são especialistas em transições de processos, mudança organizacional ou gestão de mudanças. Kent Beck, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Ron Jeffries, Robert C. Martin, Ken Schwaber, Jeff Sutherland e outros – sem dúvidas – são desenvolvedores de software e produtos brilhantes. Todos ali criaram métodos e processos dentro de seus contextos, mas, a falta de um modelo de transição nos métodos ágeis – um caminho viável e gerenciável para sua implantação – aponta para a falta de conhecimento dos autores nos assuntos citados. Não questiono que dentro da tecnologia atual o Agile é o que temos de mais avançado em processos de software, porém, a pergunta não é “O que é o certo?” mas sim “Como melhorar meu ambiente?”.

Kanban – o caminho alternativo para agilidade

O maior entrave que existe para a adoção de Métodos Ágeis é o ativismo quase religioso que se criou em torno dessa aura mística que é o Agile. Por grande influência da comunidade Kanban, graças a Deus, esse ativismo tem diminuído muito. Concordo com David Anderson (o criador da abordagem Kanban para TI) quando ele mencionou que o Movimento Agile teve uma profunda influência anarco-comunista utópica que não só julga o que é “certo” e o que é “errado” como também favorece uma luta de classes onde todo e qualquer gestor é um sinal de “opressão” ou disfuncionalidade do processo, entre outras coisas. O impacto negativo que isso trouxe foi resistência às ideias ágeis, principalmente por parte dos gestores de organizações mais conservadoras.

A pesquisa “State of Agile” da Version One em 2013 questionou mais de 4.000 pessoas de mais de 500 empresas sobre quais são as principais barreiras para uma maior adoção Agile. As 3 principais barreiras foram:

1. Habilidade em mudar a cultura organizacional

2. Resistência generalizada a mudanças

3. Tentar encaixar elementos “não Agile” à um framework Agile

Creio que essa pesquisa dá um grande suporte ao que escrevo aqui. Empresas resistem mudar, pessoas resistem mudar. Uma abordagem revolucionária, fundamentalista e drástica para mudança é pouco atrativa para a maioria dos gestores. A revolução nasce de uma ideia simples “tudo está errado, vamos mudar TUDO”. A revolução é um conceito sedutor, mas temos poucos casos documentados em empresas e na História de revoluções que atingiram seus ideais iniciais. Grandes gestores e autores da história da Administração foram líderes evolucionários e não revolucionários, destacando Taiichi Ohno, Eliyahu Goldratt, Peter Druker, Bill Gates, Lee Iacocca, Louis Gerstner, Donald Reinertsen, Edward Deming, John Seddon entre outros – alguns desses são grandes influenciadores do pensamento Lean-Kanban.

Pessoas naturalmente resistem a mudanças. Ou melhor, citando Peter Senge, “pessoas não resistem mudar, elas resistem serem mudadas”. Historicamente, se você estudar a Evolução, o que aconteceu com o ser humano há 10.000 anos atrás foi a transição do homem nômade para o homem sedentário através do início da agricultura. O homem começou a lavrar a terra e criar animais principalmente para reduzir a variabilidade que ele enfrentava na vida nômade. Pessoas buscam um estado de homeostase (equilíbrio de circunstancias) e isso não é diferente no homem moderno. Essa necessidade de não mudar as coisas drasticamente ainda é mais presente em gestores brasileiros, um país essencialmente conservador.

Kanban é um modelo de transição de processos. Kanban foi criado por David J. Anderson tendo por base dois problemas fundamentais no trabalho do conhecimento do século XXI: como ter um método sustentável de trabalho e como lidar com a resistência natural a mudanças que existe no ser humano. Para o objetivo deste artigo, me foquei nesse segundo problema. A maioria dos gestores que tenho contato resistem a revolução promovida pelos Métodos Ágeis caso suas organizações estejam longes dos valores ágeis. Eles temem o risco de falhar na implementação, pois entendem que serão necessárias muitas mudanças. Tendo isso em mente, o Kanban é um método EVOLUCIONÁRIO de mudanças e não REVOLUCIONÁRIO. Kanban tenta substituir o senso comum pela ciência e a razão para promover mudanças. O objetivo do Kanban é “colar” no processo atual da empresa, trazer visibilidade aos problemas atuais e assim engajar as pessoas envolvidas na mudança, porém, de forma evolucionária. Uma mudança por vez. Um questionário para começar com Kanban parecido com o apresentado anteriormente seria:

 

A’ – Sua empresa está disposta a melhorar o processo a partir do que ela já faz hoje?

B’ – Sua empresa está disposta a buscar uma abordagem evolucionária para mudança?

C’ – Sua empresa está disposta a inicialmente respeitar papéis, cargos e o processo estabelecido?

 

Se sua organização responde “Sim” a essas perguntas, sua empresa está pronta para iniciar com Kanban! Note que a maior diferença entre Scrum e Kanban não tem relação com a estrutura dos dois processos (como papéis, ciclo de vida, rituais e etc…), mas sim com relação ao modelo de transição. Para iniciar com Scrum as restrições iniciais (as premissas que todos devem concordar) são maiores – vide o primeiro questionário. No Kanban essas restrições iniciais são suaves e convidativas mesmo para gestores e equipes mais resistentes.

Kanban hoje tem sido confundido com um quadro na parede lotado de post-its (Gestão Visual), porém, o método Kanban idealizado por David Anderson é um conjunto de práticas simples que promovem o DNA evolucionário dentro de uma organização. “A realidade é o que ela é, comece com o que você faz hoje e melhore sempre” – esse é o mantra Kanban. Baseado em sólidos fundamentos propostos pelo Lean e profundamente influenciado pelo TPS (Sistema Toyota de Produção) e a TOC (Teoria das Restrições), Kanban atualmente tem sido usado em diversas empresas do mundo com um destaque especial para o Brasil, onde temos implementações interessantes em diversas empresas que chamam a atenção dos especialistas em Kanban do mundo todo, inclusive o próprio David Anderson.

Kanban é um método sem metodologia. Ele não impõe práticas, papéis ou ciclo de vida, mas oferece uma forma sistemática de melhorar aquilo que já existe na organização, fazendo mudanças gradativas. Com isso o processo de mudança (transição) é mais suave, favorece o engajamento das pessoas e os riscos são muito mais baixos que uma mudança brusca revolucionária. O que Kanban faz em uma organização é tornar a realidade clara, com suas qualidades e problemas, para líderes e liderados. Pense na realidade da sua empresa hoje: se seu processo tem muito trabalho em andamento no sistema (WIP – Work-in-progress), Kanban irá mostrar o impacto que ter WIP alto tem sobre os prazos, a qualidade e as entregas. Talvez na sua empresa times de desenvolvimento e testes não colaboram da forma de deveriam. Sem promover revoluções confusas ou mudanças drásticas iniciais, Kanban pode mostrar como essa falta de colaboração aumenta os custos, piora a qualidade e aumenta os prazos. Sua realidade hoje pode ser que o produto tenha muitos defeitos. Kanban irá quantificar esse problema e poderá mostrar a melhor alternativa econômica para lidar com essa questão. Lide com poucos problemas por vez, os mais importantes primeiros. Você não ganha dinheiro dizendo que usa um método ágil, você ganha dinheiro tendo um processo sob medida que atenda seus clientes e seja economicamente sustentável.

Scrum ou Kanban? Não é uma escolha mutuamente exclusiva!

Agile e Lean tem origens diferentes, mas muitas vezes tratam do mesmo assunto com abordagens diferentes. Sem dúvidas há semelhanças entre Scrum e Kanban. Como exemplo, ambos se beneficiam das importantes reuniões diárias para melhorar a comunicação e aumentar a colaboração dentro de um grupo de trabalho. Quando escrevi este artigo tomei o cuidado de colocar “Scrum e/ou Kanban” no seu título para reforçar que não é uma escolha entre Scrum ou Kanban. Um processo utilizando Kanban como modelo de melhoria pode se beneficiar de práticas Scrum. No meu trabalho como consultor também é bastante comum empresas que já utilizavam Scrum há anos adotarem o Kanban para melhorar seus Sprints. Neste segundo caso a insatisfação mais comum são equipes que levaram a eficiência dentro da Sprint ao limite e precisaram aumentar a abrangência das melhorias para fora da equipe Scrum ou da própria TI.

Essa flexibilidade com Kanban é possível porque como citado Kanban em si não é um processo, mas sim uma explicação do seu processo atual, e este pode ser Scrum, RUP, Extreme Programming, DSDM, Crystal, XPTO ou simplesmente a forma que a sua empresa já trabalha hoje, não importando o rótulo. Concluindo, a escolha entre Scrum ou Kanban não é simplesmente optar entre a estrutura dos dois processos, mas sim o que é possível e recomendado levando-se em consideração as características únicas e restrições da sua organização. Kanban geralmente tenta compreender e explicar o Status Quo, Agile geralmente o renega. Se sua empresa está longe do Scrum uma revolução será necessária, e há riscos indesejáveis envolvidos. Se sua empresa não liga tanto para o rótulo Agile, mas quer melhorar continuamente um processo já existente, de forma eficiente, gradativa e com menores riscos é recomendado Kanban. Não há processo perfeito. Tudo pode ser melhorado!

Leia também:
Gestão Moderna
Sistema Puxado
Kaikaku – Kaizen
Dizer sim ao Lean torna o resto irrelevante
O mito da Cultura Ágil