Agilidade é um termo bastante abrangente. No mundo do software, graças ao Movimento Ágil, a palavra virou sinônimo de aplicação de métodos de gestão que estão de acordo com o Manifesto Ágil.
O problema dos chamados métodos ágeis são a limitação da sua aplicação em contexto de times. Muitos modos de tentar escalar a agilidade foram criados nos últimos anos onde a principal reclamação dos gestores é o engessamento dos processos, se tornando o oposto a real agilidade.
Num contexto de negócios, agilidade é a capacidade de uma organização de se adaptar a mudanças no mercado. Para essa adaptação, é essencial que toda a organização consiga responder rapidamente às novas tendências e ameaças que rondam esse novo mundo VUCA (Sigla da moda, que traduzindo é: Volátil, Incerto, Complexo e Ambíguo)
O modelo tradicional de fazer negócios, com grandes planejamentos de 5 anos, é o oposto da agilidade pois dificulta mudanças na estratégia para adaptação. Isso, somado a uma camada de gerentes médios mais preocupados em atingir metas do que com o sucesso da empresa, fragiliza o negócio e é responsável pela redução da expectativa de vida das enterprises.
Agilidade depende de fluxo. Bruce lee falava: seja a água. A água se adapta ao recipiente onde ela se encontra. Esse é o nível de adaptação necessário e para isso o trabalho precisa fluir. E para fluir, é preciso desesperadamente reduzir o tamanho dos lotes de planejamento. Reduzir o lote de trabalho significa poder mudar de direção mais rápido, reduzindo filas e consequentemente o tempo que esse trabalho vai do pedido a entrega. Reduzir lead time de negócios nos permite reduzir o time to market, validar mais cedo e evita o desperdício de fazer certo (ou não) a coisa errada.
Para evitar desperdícios, precisamos fazer a coisa certa mais do que fazer certo alguma coisa. O problema do planejamento nas empresas é que se gasta muito tempo planejando algo sem ter a menor ideia se pode funcionar ou não. Meses de planejamento para descobrir que as premissas estavam erradas levam a uma grande fricção, como bloqueios no desenvolvimento devidos a erros de especificação, evitando o fluxo de trabalho contínuo.
Fluxo enterprise
O fluxo end-to-end no Kanban também é conhecido como Kanban de Clientes (Customer Kanban). Ele é divido em duas principais partes:
- Upstream Kanban: Entender as necessidades dos clientes, antecipar problemas, modelar e criar opções de trabalho.
- System Kanban: Melhorar a capacidade do sistema para melhor atender as demandas dos clientes.
O grande segredo para o Kanban de clientes é conseguir alinhar a suspeita de uma ideia à sua entrega em produção. O sucesso é muito baseado na redução do tempo de resposta para uma rápida adaptação.
O Upstream Kanban reduz o tempo de resposta testando algumas opções que serão selecionadas para o Downstream, evitando que problemas ocorram tarde demais no processo. A criação de opções e o contínuo melhoramento ajudam a garantir que demandas de alto risco ou com alta incerteza não cheguem até o downstream diretamente. Isso evita bloqueios onde o desperdício custa muito mais caro.
Já o System Kanban faz isso reduzindo a quantidade de coisas feitas ao mesmo tempo (Work in Progress – WIP). Reduzir o WIP é fundamental para redução do lead time e aumento da vazão pois paramos de começar muitas coisas e começamos a terminar. A palavra chave é a entrega, não empurrar muitas coisas para a equipe fazer ao mesmo tempo achando que isso vai fazer as coisas andarem mais rápido.
Pensando em demandas de ponta a ponta, é preciso entrar em um estado de fluxo entre a criação das demandas e seu desenvolvimento, evitando assim que seja preciso ter todo o projeto planejado para que o desenvolvimento já possa acontecer. Assim, o Upstream Kanban nasce como uma forma de mapear esse fluxo de criação e entrega de valor.
Podemos perceber claramente, principalmente nas apresentações do Patrick Steyaert, criador do método, que o upstream kanban está em constante evolução. Porém, já existe uma direção de como esse fluxo pode acontecer no seu produto. A ideia é mapear o modelo que sua organização já usa para criação e com isso, fazer com que as evoluções fluam, primeiro como opções (upstream) e depois como demandas (downstream), através do sistema até sua entrega.
No próximo artigo irei mostrar como fazemos o mapeamento e como usamos o Upstream Kanban na Taller, mostrando exemplos de boards, cadências e métricas que usamos no dia a dia.
Abraço e até lá.
Saiba mais no nosso post: Upstream Kanban: gestão do fluxo de criação de demandas