Na Guiando, os times já possuem certa maturidade com Scrum. Agora, com a adoção progressiva de princípios de Kanban estamos percebendo que algumas práticas estão deixando de fazer sentido, outras estão sendo redesenhadas e algumas são complementares e, ao menos por enquanto, devem ser mantidas. Compartilho um pouco sobre esse tema nesse post.
NOTA DO ELEMAR: Como ocorreu com os anteriores, esse post é do Fernando Neiva, apenas editado por mim.
Kanban é menos prescritivo
Ao implementar Kanban, estamos aprendendo um bocado de conceitos novos. Alguns deles mais fáceis e naturais, outros ainda estranhos. Dentre as mudanças que mais agregaram valor (até aqui) estão a limitação das atividades em progresso (que iremos tratar em outros posts) e a explicitação do fluxo de trabalho (tema de posts anteriores)
O Kanban propõe princípios como limitação das atividades em progresso, visualização do fluxo de trabalho e melhoria contínua. Porém, não é tão prescritivo quanto a papéis ou cerimônias como o Scrum.
O que fazer com as práticas que já tinhamos?
Por ser pouco prescritivo, Kanban nos permitiu manter, pelo menos por um tempo, algumas das práticas que já estávamos habituados. Entretanto, algumas mudanças começaram a ocorrer naturalmente.
Nos times que migraram de um planejamento em sprints para um fluxo contínuo o burndown (que eu adorava) perdeu o sentido, pois, deixamos de adotar um escopo delimitado para ser feito em um tempo fixo. O acompanhamento do progresso do trabalho passou ser diretamente pelo quadro kanban.
Um dos nossos maiores receios ao migrar de um modelo baseado em planejamento de sprints para um fluxo contínuo era (tá bom, ainda é… um pouco) o medo de, ao não ter uma visão maior do horizonte de entregas, o time não conseguir se planejar e construir uma arquitetura baseada em puxadinhos (improvisos). Entretanto, a própria fila de prioridades no quadro está minimizando esse problema.
De fato, reconhecemos até que sprints, em nossa empresa, eram tão curtos (não mais do que quinze dias) que também não entregavam a tal “visão de futuro”. De certa forma, a fila priorizada (no quadro Kanban) está sendo até mais efetiva. Além disso, a adoção do Kanban intensificou consideravelmente o envolvimento e a interação com o pessoal do negócio.
[tweet]Arquitetura emergente não pode implicar em arquitetura Frankstein![/tweet] O segredo, para nós, está sendo realizar reuniões periódicas onde buscamos uma perspectiva mais ampla. Estamos focando em uma estratégia (como diria o Elemar, um padrão coerente para tomar decisões).
Reuniões, reuniões…
As reuniões diárias foram mantidas! Porém, como falamos, o artefato de acompanhamento se tornou o próprio quadro kanban e não mais o burndown para alguns times. Já as reuniões de planejamento estão sendo redefinidas. Estamos percebendo que elas, agora, tem mais o intuito de fazer uma alinhamento de negócio do que um planejamento de entregas de fato.
A periodicidade delas poderia ser sob demanda, porém optamos (a contragosto do Elemar) por realizá-las de maneira fixa neste início seguindo a recomendação do David Anderson em seu livro.
O que fazer com os papéis
O Scrum Master nos ajuda a remover os impedimentos que surgem no dia a dia dos desenvolvedores, fazer ajustes nos processos, monitorar a fluidez do trabalho e garantir que as práticas acordadas estão sendo seguidas. No nosso caso, ele também é um líder técnico e atua para apoiar o time nas dificuldades técnicas. De alguma forma, o papel será mantido (com um nome que ainda não identifiamos).
O Product Owner continua como o responsável pelo produto e representante de negócio dentro do time. Ele é responsável por explicitar para o time de desenvolvimento os desejos da área de negócio e garantir que seja feito com a qualidade esperada. Ele também é o responsável por detalhar os requisitos e criar seus critérios de aceitação. Este papel também será mantido.
Dado que os papéis representam atualmente uma forma eficiente de divisão de responsabilidades nos squads não encontramos motivos para mudar (muito).
Concluindo
Mudar é difícil. Nossos times estavam habituados com uma forma de trabalhar e estamos optando por fazer mudanças de forma incremental, sem traumas, e começando sempre por onde tínhamos mais dor e onde percebemos mais valor.
Graças ao fato do Kanban ser tão pouco prescritivo, estamos tendo sucesso em manter alguma “convivência”.
Adoraríamos saber um pouco mais de sua experiência. Também usava Scrum (ou outra metodologia ágil) e migrou para Kanban? Como foi seu processo?
