Introdução a Upstream Kanban com base em experiências no LuizaLabs
Este texto tem o objetivo de ser uma introdução a abordagem Upstream Kanban e Customer Kanban, com base em experiências reais dentro do Luiza Labs. Trata-se de um assunto vasto que pode ainda ser complementado por outros conteúdos dessa natureza.
Imagine um time de desenvolvimento de software trabalhando com o método Kanban há alguns meses. O fluxo de trabalho estava customizado para o contexto do time, as políticas estavam explícitas, os tipos de demandas e classes de serviços foram determinados e o WiP limitado começava a mostrar benefícios, como:
- Melhor qualidade de entrega e redução do retrabalho;
- Menor tempo de reação a mudanças (agilidade);
- Gargalos do fluxo visíveis;
- Menor lead time (tempo entre o início do desenvolvimento e a entrega);
Porém, ainda não era suficiente. Apesar do WiP limitado, a lista de “backlog” se mantinha muito grande e nem sempre apresentava itens bem refinados. Esta longa lista de “backlog” poderia pressionar o time a dizer sim, ou seja, deixar de respeitar o WiP limitado e, se isso ocorresse colocaríamos em risco os benefícios mencionados acima.
Outras questões vieram à tona:
De todos estes vários itens no backlog, qual devemos trabalhar agora?
Será que todos estes itens vão gerar valor para o negócio?
Dado este cenário, o próximo passo era expandir o fluxo, dando mais visibilidade ao trabalho que vem antes do desenvolvimento da demanda, com o objetivo de proporcionar:
- Triagem — retirar do fluxo de trabalho itens que não geram valor para o negócio.
- Refinamento — assertividade no desenvolvimento, de maneira que os desenvolvedores não tenham dúvidas no momento da implementação.
- Fatiamento — para que um desenvolvedor não ficasse 35 dias na mesma história.
- Priorização — para que fique claro para os desenvolvedores quais itens do “backlog” puxar nos próximos dias.
- Planejamento — esclarecer para áreas, clientes e desenvolvedores, os status das demandas.
Além disso, assim como na comunidade de produto e agilidade, no Luiza Labs, utilizamos algumas técnicas de design de produto como Design Sprint, Lean Inception, User Story Mapping e Design Thinking. Tanto se discute sobre técnicas de priorização, escrita de histórias, INVEST, quebra de escopo, entre várias outras. Essa sopa de letrinhas parecia um monte de peças de quebra cabeça bagunçadas, imagine a vida do PO (product owner). Diante de tais desafios, a abordagem do Upstream Kanban surgiu como uma maneira produtiva de organizar em fluxo essas várias peças do quebra-cabeça.
Upstream Kanban é a gestão do fluxo estruturado de trabalho para avaliar, preparar e refinar ideias, oportunidades e opções, antes de chegar para o desenvolvimento. De maneira que as tarefas cheguem sem ruídos e na granularidade correta para os desenvolvedores, sem gerar sobrecarga. Assim, os compromissos de entregas são sustentáveis, com menor risco e menos incerteza.
Em Essential Upstream Kanban, Patrick Steyaert, o principal autor sobre o assunto, afirma: “The purpose of the Upstream Kanban was to manage the stream of incoming requests before being able to commit the work for execution downstream.”
Exemplo de board de Upstream Kanban:
Fluxo end-to-end
Mas e aquele fluxo kanban que temos na parede com as etapas de Desenvolvimento, Teste, Homologação e Deploy?
Para essas etapas relacionadas ao desenvolvimento da solução, vamos chamar de Downstream Kanban (Delivery).
Agora, imagine o fluxo completo da vida do desenvolvimento do software, desde a idealização da nova funcionalidade, até o momento mágico em que a ideia gera valor, de fato, para o cliente, o momento que ele pode usufruir da funcionalidade (no ambiente de produção). Este fluxo end-to-end é o Customer Kanban:
Cada uma dessas etapas significa um conjunto de ações a serem realizadas por uma ou várias pessoas. Com base na experiência de implementação e uso do Upstream Kanban em squads de backoffice no Luiza Labs, a seguir, exemplifico um fluxo e explico cada etapa.
Case de Upstream Kanban
Na imagem acima, há a relação de um para um, ou seja, um board Upstream para cada squad. Isso não é regra, é comum encontrar um board Upstream no qual um ou mais POs trabalham gerando demandas para um ou mais squads. Na imagem abaixo, dois POs trabalham nos itens gerando demandas para dois squads e essa foi a maneira mais organizada que eles encontraram.
As duas imagens mostram boards reais de Upstream Kanban (no Jira e no vidro) e o Trello também é comumente utilizado. Ou seja, a ferramenta não é a questão mais importante.
As características de boards Upstream variam muito de acordo com cada situação. Por exemplo, algumas etapas não citadas aqui podem surgir, ações descritas em uma etapa podem vir em sequências diferentes, entre outras possibilidades. O Upstream deve estar customizado a cada contexto.
Pool
É a porta de entrada para solicitações, ideias e oportunidades propostas pela área cliente, PO ou time de desenvolvimento. Não há restrições de quem ou quando pode colocar itens no Pool. Normalmente, esses itens surgem em interações entre os times de negócio e TI, ciclos kaizens, brainstormings, agendas de planejamento e reuniões com stakeholders. Nesse momento inicial, mesmo que os itens estejam em nível macro, obscuros e cercados por dúvidas, é essencial que sejam coerentes com a estratégia da empresa.
Discovery (entendimento, triagem e priorização)
O Discovery é a etapa mais importante no Upstream. Nesse case, o Discovery representa 3 grandes etapas: entendimento, triagem e priorização. Isso varia de acordo com o contexto, há boards de Upstream Kanban que contém uma etapa exclusiva para priorização, por exemplo.
Nessa etapa acontece todo entendimento, refinamento, levantamento de regras do negócio, processo (desenho do fluxo), restrições, possibilidades, entendimento com negócio, mapeamento com squads que tem intersecção no processo/produto, interação com fornecedores (aplicações externas), proposição das hipóteses, definição de métricas de sucesso, observações e prototipagem. Técnicas como Design Sprint, Blueprint, Lean Inception, Design Thinking, Jornada do Usuário e Product Backlog Building, são utilizadas neste momento.
Todas essas “descobertas” são importantes para embasar a triagem das demandas. Os itens que não gerarão valor ou não estão de acordo com os OKRs (Objectives and Key Results) na empresa deverão ser excluídos e não continuarão nas etapas seguintes do Upstream.
Para os itens que continuarão no Upstream, os POs devem definir a prioridade de acordo com urgência da demanda, impacto, alinhamento estratégico (Key Result), experiência do usuário, competitividade da empresa, etc. Esse processo é mais efetivo quando feito a quatro mãos (tecnologia e negócio). Alguns POs tomam esta decisão em conjunto com líderes do negócio em agendas regulares.
Durante o Discovery, surge muito conteúdo, então é a oportunidade para os POs começarem as documentações (como FAQ e Press Release).
Split (divisão do escopo)
Histórias de usuário bem escritas, detalhadas e na granularidade correta, são premissas para a boa fluidez em todo o processo de desenvolvimento, sem isso todas as etapas seguintes serão afetadas. A qualidade da entrega, a assertividade do desenvolvimento e o lead time estarão comprometidos quando uma história superficial, com espaço para dúvidas ou no tamanho errado (evitar big batches) transita no kanban do squad.
“If I can divide something big into lots of smaller parts, it makes it a little easier for my team to pick up and build parts concurrently. A good rule of thumb is to break down stories to something that takes a couple of days to build and test.” (Jeff Patton — User Story Mapping)
Até a etapa anterior, tínhamos épicos no Upstream Kanban. Nessa etapa, os POs escrevem as histórias (sugestão: utilizar o método INVEST) e definem os critérios de aceite.
Architecture (análise técnica)
Na análise técnica, TL (tech lead) e desenvolvedores:
- Propõem solução técnica de acordo com os princípios de arquitetura da organização (desenho da arquitetura).
- Levantam as tecnologias mais aderentes ao contexto.
- Levantam os riscos e ofensores técnicos.
- Levantam interfaces com outros sistemas.
- Estimam volumetria.
- Passam pelos checklists de infraestrutura e segurança (alinhamento sobre necessidade de hospedagem, por exemplo).
- Levantam os critérios de desempenho.
Esse trabalho técnico pode iniciar antes, quando o item ainda está em Discovery.
Estimate (estimativas e orçamento)
Neste momento, após ter todo o refinamento da demanda completado, ocorre as estimativas de esforço para desenvolvimento. Para produtos que envolvem desenvolvimentos externos com parceiros, os orçamentos devem ser levantados.
Ready to Start (pronto para iniciar o desenvolvimento)
Nem todos os itens que começaram no Pool chegarão ao Ready to Start. Só deverá chegar nessa etapa os itens que foram triados, refinados e já quebrados em histórias. A equipe de desenvolvimento vê essa etapa como o “Backlog”, assim precisa ter claro em ordem de prioridade as histórias a serem puxadas para desenvolvimento nos próximos dias. Nessa linha, sugiro que os itens cheguem ao Ready to Start com as características DEEP (detailed appropriately, estimated, emergent, and prioritized).
Relação do PO/PM com o Upstream Kanban
O board do Upstream Kanban, naturalmente, torna-se o principal artefato de trabalho do PO, onde todos seus itens de trabalho estão expressos. Ao conversar com os squads sobre o upstream e downstream, sempre entendemos que o responsável pelo upstream é o PO e os desenvolvedores são os responsáveis pelo downstream. Isso não significa que POs não têm participação em alguma etapa no downstream. É imprescindível que o PO tenha visibilidade do fluxo todo e fique à disposição para tirar eventuais dúvidas dos desenvolvedores. Além disso, é comum encontrar POs que participam de alguma etapa do downstream, como a Homologação.
Em contrapartida, desenvolvedores e TLs devem participar do processo de entendimento, análise técnica e da análise de viabilidade (Discovery e Architecture — análise técnica). Tais análises podem mudar totalmente os rumos de uma iniciativa.
Visibilidade e Comunicação
Um dos primeiros benefícios que notamos ao estabelecer o fluxo completo (Customer Kanban) foi em relação a melhoria de comunicação entre todos envolvidos. Para os desenvolvedores, fica claro quais serão os itens de trabalho nas próximas semanas. Para o negócio, fica mais claro quais os itens estão em refinamento, quais demandas não serão desenvolvidas, quais demandas estão em desenvolvimento, etc. Assim, as tomadas de decisão são tomadas em conjunto com maior frequência.
Nas squads citadas, notamos que o Upstream Kanban foi um passo importante na sinergia entre squads e áreas clientes. Vale reforçar que o Customer Kanban não substitui a visão de Portfólio, porém gera bons insumos para construir e manter atualizado uma visão gerencial dos status das iniciativas.
Métricas
Com o fluxo end-to-end do Customer Kanban estabelecido, conseguimos extrair um novo lead time. Até então tínhamos o lead time de desenvolvimento, isso já é uma ótima prática. Por exemplo, com base no histórico de entregas de histórias, é possível dizer que:
A média móvel de histórias (entregas de valor) do time é de 21 dias.
Ao dizer isso para a área cliente, há o risco de ouvir que aquela demanda foi “solicitada” à área de tecnologia há 4 meses! Ou seja, não faz sentido insistirmos que o time de desenvolvimento diminua o lead time de 21 dias para 10 dias, se o refinamento das demandas demoram 95 dias. Interessa mais ao cliente, o lead total do ciclo de vida da demanda, do momento que foi acordado (commitment point) que a demanda seria trabalhada até o momento que ela se tornou realidade, o momento que foi para a produção. Esse é o customer lead time, tempo entre o commitment point e o Done.
Exemplo de customer Lead Time:
Eficácia e Eficiência
Um dos principais benefícios da utilização de Upstream Kanban é a eficácia. Segundo Paulo Caroli, “Eficácia é fazer a coisa certa. É ir direto ao ponto e trabalhar na coisa certa, no produto certo, no MVP (Minimum Viable Product) certo. Criar um produto digital com eficiência, mas sem eficácia, não maximiza valor para sua empresa. É jogar dinheiro no lixo!”.
Ao trabalhar com o Kanban focado exclusivamente no desenvolvimento, estamos em busca de eficiência maior, ou seja, estamos em busca de fazer entregas mais rápidas e com mais qualidade. Contudo, um squad pode entregar novas funcionalidades quase sem nenhum bug em poucos dias, e não entregar o que de fato gera valor para o negócio. Em outras palavras, eficiência sem eficácia.
Essa assertividade no que desenvolver é possível pois o Upstream Kanban auxilia a:
- Evitar que itens não maduros cheguem no downstream
- Tratar ideias que são ambíguas e fragmentadas
- Descartar itens que não entregam muito valor para o negócio (triagem)
Com base nas experiências citadas, sugerimos que a triagem não fique restrita à uma etapa do Upstream. Durante o entendimento no Discovery, os POs podem chegar a conclusão que a aquela demanda discutida não vai impactar consideravelmente os Key Results da empresa. Ou o TL e Devs podem concluir que o esforço e complexidade técnica para desenvolvimento é proibitivo perante o valor gerado da demanda, por exemplo. Nesse contexto, triagem não significa somente descartar demandas, mas pode ser também postergar o desenvolvimento da demanda.
E as demandas de falhas?
Nas experiências referenciadas aqui, escolhemos não passar as demandas de falha pelo Upstream, pois o volume alto de bugs a serem analisados poderia gerar gargalo no PO. Como alguns bugs precisam de atendimento rápido, essa demora poderia gerar impactos negativos no negócio. Assim, as demandas de falha são analisadas e tratadas diretamente pelo bombeiro do squad (o conceito e o modus operandi do bombeiro poderá ser tratado em mais detalhes em outro texto). Dessa maneira, o Downstream do squad ficou com duas portas de entrada:
Próximos passos
Upstream Kanban não se trata de tentar transformar um processo criativo de Discovery em uma esteira de produção. Trata-se de uma maneira inteligente de trabalhar os itens através do fluxo, trata-se de deixar de enfatizar somente o Delivery Side e olhar também para o Discovery Side, evoluindo as práticas e técnicas de Discovery. Ou seja, não basta pressionar os desenvolvedores para trabalharem até tarde da noite como loucos, se as demandas não estão sendo refinadas da maneira correta no Discovery.
Há vários outros conceitos, como quantidade mínima de itens no WiP do Upstream, comportamentos de sobrecarga e escassez, e características que compõem a abordagem Upstream Kanban. Para não prolongar muito, vamos falar disso em outros textos aqui.
Referências
