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?
9 respostas
Ótimo relato! Parabéns!
Estamos aprenndendo, Rodrigo. Os livros que nos recomendou estão nos impactando bastante.
Muito bom! Estou nessa jornada também. Compartilha aí os livros recomendados.
Danny, obrigado! Espero que nosso relato tenha contribuído. O Yoshima nos indicou dois principais: “Kanban, Successful evolutionary change for your technology business” do David Anderson e “The principles of product development flow”.
Muito obrigado, Rodrigo.
Nos passamos por uma mudança parecida. O scrum, por ser tão prescritivo, é simples de seguir, mas ao mesmo tempo você corre o risco de seguir sem entender o porquê está fazendo as coisas. O Kanban, no nosso caso, obrigou a nos questionar o que fazer e porque. Isso provoca até hoje uma evolução contínua que no scrum corre perigo de ficar escondida nas cerimônias.
Bom, é só uma opinião!
Legal, Oriol. Obrigado por compartilhar sua experiência.
Bacana o artigo!!
Gostaria de agregar aos comentários, que atualmente minha equipe esta passando por este processo de transição Scrum-Kanban. Porém, temos uma problemática: somos uma fabrica de software que atende outra fábrica de software, em resumo somos Outsourcing.
Mais fatos da problemática: como fornecer temos um “escopo fechado” baseado em pontos de função, métrica utilizada pelo cliente para produtividade e custo.
*obs. Anteriormente era utilizado o SAFE.
Por estas características e cenário a equipe se sente muito insegura com o Kanban. Que não tem a visão do todo. Para se responsabilizarem por todas as funcionalidades prevista na cota de pontos de função.
Questão, como lidar com equipe que se sente assim. E o cliente que quer utilizar o Kanban,porem com uma definição de escopo baseada em uma métrica antiguada?
Bruno, nós começamos criando a visualização do fluxo de trabalho, pois nós tínhamos a mesma preocupação que você de não fazer uma mudança drástica. No nosso caso funcionou legal, pois não tivemos que logo de início abandonar a forma de trabalho que as pessoas estavam acostumadas. Acredito que isso contribuiu para as pessoas terem menos resistência às mudanças.
Aos poucos estamos adicionando outros princípios e a medida que evoluímos o próprio time começa perceber pontos no processo que não fazem mais sentido.
Uma leitura sobre esse assunto que talvez você goste está no capítulo 4 – From Worst to Best in Five Quarters – do livro do David Anderson. Ele conta um caso de um time que estava restrito a trabalhar em um modelo CMMI e como foi o processo de mudança.