Kanban: Porque agilidade é uma questão de práticas e não de mindset?

Ultimamente tenho notado que os agilistas estão se dando conta de que para gerir trabalho do  conhecimento não basta munir-se de metodologias prescritivas tradicionais, aquelas  que o mercado apresenta como eficientes, a priori. 

Cada vez mais, a “ovelha negra” da agilidade vem ganhando espaço entre os late adopters de Scrum que percebem a grande diferença entre gestão de mudanças revolucionária vs evolucionária: essa ovelha negra chama-se método Kanban, que considero um caminho alternativo para obter agilidade nas organizações que se preocupam em escalar de forma saudável.

Antes de apresentar o conceito, permita-me apresentar a origem dele: kanban é uma expressão japonesa que significa, literalmente, cartão. A simplicidade do significado, porém, esconde sua importância. Basicamente, é um sistema visual de controle e gestão de fluxo e estoque por meio de cartões, idealizado no auge do Toyotismo. A proposta é permitir que os profissionais consigam visualizar rapidamente o fluxo de todos os processos, identificando pontos que precisam de mais atenção ou, no caso da produção de automóveis, quais peças precisam ser repostas. 

Com o grande boom de projetos de software no final da década de 90, era questão de tempo até que essas boas práticas da manufatura lean fossem adaptadas ao contexto do trabalho do conhecimento. Foi em 2004, no departamento de TI da Microsoft que David J. Anderson começou a implementar e publicar os resultados dos seus experimentos aplicando seu método, que mais tarde seria chamado de Kanban.

É preciso deixar claro que o método Kanban não vai dizer como resolver problemas da empresa (ele não é prescritivo como a maioria das metodologias), seu objetivo é mostrar onde há disfunções no fluxo de trabalho, trazendo visibilidade sobre ele, mas sem prescrever uma solução. Neste ponto o Kanban é mais sutil: ele não assume que sabe quais são suas disfunções sem antes ajudá-lo a entender quais são. Dessa forma, ele se diferencia do Scrum, o favorito no setor de tecnologia: o scrum é uma metodologia que prescreve um modelo de funcionamento para times, aqui nasce o problema, a agilidade fica represada no silo dos times de tech, ao invés de ser praticada por toda a empresa, dando a impressão de que quanto mais times ágeis tiver, melhor a empresa será.

Em um mundo cada vez mais repetitivo e viciado em procurar “receitas prontas”, bastaria algum tempo praticando metodologias prescritivas que endossam otimizações de times, e teríamos ambientes tão enviesados na melhoria local que o próprio ponto de alavancagem para mudanças se tornaria os indivíduos da organização (se existe tobogã e piscina de bolinha na sua empresa, é bem possível que tenha sido vítima do “people -centrismo”).

Na Hash fazemos diferente, partimos da premissa de que a performance de um sistema não é a soma de suas partes, mas sim um produto da interação entre elas, por isso acreditamos que agilidade é uma característica sistêmica, que pode ser medida e sustentada por práticas que não são prescritivas, isto nos torna mais pragmáticos e voltados a resultados, ao contrário do pensamento purista que acredita que ser ágil é “ensinar as pessoas a forma correta de pensamento no trabalho”.

Para garantir que, na prática estamos gerenciando a interação entre as partes e não focando na otimização individual e local de cada uma, adotamos uma metáfora para guiar nossa visualização do trabalho. Chamamos essa metáfora de: níveis de voo.

Quando você sobrevoa baixo, próximo do solo, é possível observar grande quantidade de informações detalhadas, como carros, casas, pessoas e outras coisas. Conforme você sobe, elevando a altura do voo, perdemos granularidade de informação, porém conquistamos um campo de visão maior e que não existia antes, tornando possível observar bairros, cidades e até mesmo estados inteiros. 

Aqui na Hash nós utilizamos 3 níveis de voo diferentes: 

• Nível 1 – Fluxo de tecnologia: aqui correm tarefas, onde a granularidade é grande, contendo muita informação técnica detalhada.

• Nível 2 – Fluxo de funcionalidades: aqui passam funcionalidades inteiras com o objetivo de interagir constantemente com o cliente, cada interação gera mais informação para melhorar nossos produtos.

• Flight level 3 – Fluxo de projetos: aqui é o lugar onde os objetivos estratégicos e projetos da Hash são tangibilizados, dando uma visão de qual é o plano para o futuro da empresa e fornecendo informações estratégicas de como vamos executá-lo.

Grande parte do mercado contrata agilistas para focar em melhorias no nível 1, ou seja, na otimização individual das partes (times), algo que já entendemos que não contribui para melhoria sistêmica e portanto não é perceptível para nossos clientes, pois um único time sozinho não é capaz de entregar valor para o cliente, ele precisa interagir com outros times para que isso seja possível. Nesse ponto somos mais robustos, nossos esforços focam em otimizar os três níveis de voo, garantindo que exista fluidez nas interações entre todas as partes envolvidas na corrente de valor, garantindo que toda a fintech consiga responder com rapidez ao mercado. 

*Matheus Marzochi é Service Delivery Manager na Hash