Scrum, Lean, Agile, Kanban: como eles estão relacionados?

Com frequência recebo perguntas de pessoas sobre como o Agile, Lean, Scrum e Kanban estão relacionados entre si. Para aqueles que não gastaram tempo lendo as histórias de origem, estes termos são apenas palavras soltas. Recentemente me deparei com esta imagem que conta muito bem a história e as relações existentes.

Aqui está com eu interpreto essa figura.

Na área de software, na década de 90 eles estavam buscando novas formas para se trabalhar. Os mais conhecidos são o Scrum e a Extreme Programming. Em 2001, 17 pessoas se reuniram para debater as questões que tinham em comum e foi assinado o Manifesto Ágil, momento em que foi cunhado o termo desenvolvimento ágil de software.

Antes, a indústria de transformação no Japão, fortemente influenciada por Edwards Deming, começou a enxergar diferentes formas de se trabalhar. Isto levou ao Sistema Toyota de Produção (TPS), e depois ao Lean Manufacturing.

O sistema de produção do Japão inspirou o artigo “New New Product Development Game”. Este artigo é considerado o ponto de partida do desenvolvimento do framework Scrum, influenciando fortemente os trabalhos de Jeff Sutherland e Ken Schwaber.

O Desenvolvimento Enxuto de Software é exaustivamente escrito por Poppendiecks. Ele utiliza princípios do Lean da indústria da transformação e aplica no desenvolvimento de software. O resultado desta junção influenciou também o desenvolvimento ágil de softwares.

Kanban tem raízes no Lean, no entanto ele também é influenciado pelo Ágil.

Então o que tudo isso significa? Muitas vezes as pessoas querem saber se você trabalha com Ágil, Lean ou kanban? A partir da imagem acima você pode perceber que não há apenas uma resposta. Estas ideias surgiram basicamente ao mesmo tempo com uma grande movimentação de pessoas, o que, sem dúvida, nos levaram a ideias comuns.

Pessoalmente eu acho que vale a pena ler amplamente sobre Lean e Ágil (bem como as outras ferramentas, a inspiração pode vir de qualquer lugar), e em seguida aplicar o que funciona para você.

Basta manter o básico da inspeção e adaptação:

• Mudar uma coisa de cada vez;
• Dê a mudança uma chance (as vezes às coisas pioram antes de melhorar);
• Meça as coisas importantes para verificar se a mudança ajudou ou não;
• Repita

Autora:

Artigo originalmente escrito por Karen Greaves. Tradução: Rodrigo Zambon

Link original do post: http://www.growingagile.co.za/2013/12/scrum-lean-kanban/?utm_source=ReviveOldPost&utm_medium=social&utm_campaign=ReviveOldPost

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

O que é ser ágil?

o-que-e-ser-agil-rodrigo-zambon-mundo-agilRecebo frequentemente algumas dúvidas dos meus alunos e de outros colegas na organização me perguntando o que é ser ágil. E é interessante porque na mesma organização temos culturas locais diferentes que tentam se sobressair frente a cultura geral, aquela adotada pela maioria e já internalizada pelo público externo e sociedade. É claro, estas boas práticas setorizadas aos poucos vão aparecendo e sendo compartilhadas com os demais.

Ágil não é uma prática, em que você vai empregar algumas técnicas e esperar que as coisas aconteçam. Implantar o kanban ou fazer as reuniões diárias ou mesmo de retrospectiva ajudam, e podem sim melhorar o processo, porém não nos tornamos ágeis de uma hora para a outra, aliais essa expressão “tornar ágil” é extremamente perigosa.

Uma organização precisa constantemente rever seus processos, e renovar o ciclo de aprendizado com certa frequência. Os indivíduos precisam se adaptar as mudanças de trabalho e dos cenários. Ser ágil é um processo evolutivo, de continuo aprendizado.

Ao contrário do que muitos pensam, ágil não é entregar rápido, ou que a execução estará livre de defeitos e que a qualidade do produto será alta. Se não gerenciarmos estas variáveis, nosso projeto terá os mesmos problemas se comparado a outros métodos.

Sendo ágil você vai responder a mudanças, ou melhor, não se apegar aos planos como se fossem o certo a se fazer. É se adaptar mais rapidamente as necessidades do cliente. Entender que você, sua equipe são um meio para que o cliente possa crescer e obter valor no investimento que está fazendo. Você e sua equipe foram a melhor escolha que aquele cliente poderia fazer e tinha disponível no momento da contratação. É fundamental a parceria e principalmente entregar o que de fato ele precisa.

Uma outra questão associada a mudança é o custo. Não vamos aprovar ou descartar sem se fazer uma análise ou negociar com o cliente. Se nosso foco é entregar cedo o que representa maior valor, será que as mudanças que vão aparecendo no decorrer do projeto compensam ser entregues? Se o que tem mais valor é entregue no início, o que vem depois teoricamente trará menos benefício. Pode ser que em determinada fase do seu projeto, o cliente alcance o valor pretendido e tudo que venha depois agregue pouco ou nada ao negócio.

Sendo ágil você vai entregar valor continuamente, mas o mais importante desta afirmação é o como você entregará e como seu time está integrado com o cliente e com a organização a que ele pertence. A velha concepção de comando e controle também não irá funcionar aqui. A administração, o cliente e a sociedade precisam acreditar na equipe que está trabalhando no projeto. A autonomia do time na tomada de decisões é fundamental para manter a motivação e o engajamento.

Por último, sendo ágil você trará as lições aprendidas para dentro do projeto. Conforme descrito no manifesto ágil “Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.” Isso vai ajudar seu time a melhorar continuamente, sendo de fato um grupo unido, e qual o lugar deste grupo dentro da organização.

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Iterações: qual o tamanho?

iteracoes-qual-o-tamanho-rodrigo-zambon-mundo-agilAntes de falar de iterações, vou falar um pouco de escopo e começar com um dado publicado pela Standish Group que diz respeito ao uso das funcionalidades em softwares. Apenas 20% das funcionalidades são utilizadas com frequência, sendo que 80% foram poucas ou nenhuma vez utilizadas1.

A pergunta aqui é: por que isso acontece?

Não só em software, mas em diversos projetos, percebemos que entregamos coisas desnecessárias para o cliente, itens que agregam tão pouco valor que se não estivessem ali, ninguém sentiria falta.

A definição do escopo na abordagem tradicional é feita no início do projeto, e procura-se esgotar o processo. Muitos stakeholders, classificados em uma longa planilha, são ouvidos. As expectativas são levantadas e muitos imaginam que fazendo uma boa definição de escopo o projeto será um sucesso.

Porém na prática isto é um pouco diferente, ou seja, o mapa não é o território2. O quanto antes você encarar a sua realidade melhor. Por isso, no início do projeto, determinar o tamanho das suas iterações pode ser crucial para o sucesso de todo projeto. Pense sempre em primeiro lugar no retorno sobre o investimento do cliente e em segundo, na mitigação dos riscos.

Abraçar cegamente o plano e só ter contato com o cliente no final do projeto certamente é uma estratégia ultrapassada por vários motivos, e como exemplo posso citar os dois principais: só entregar o produto no final e ainda correr o risco de entregar um produto obsoleto.

As iterações mais curtas permitem a equipe do projeto obter feedback mais cedo e consequentemente revisões periódicas com os clientes. Isso irá permitir, primeiro saber se estamos indo para o lugar certo e em segundo se estamos de fato atendendo às necessidades de nossos clientes. A abordagem tradicional atrasa esse tipo de vantagem, até quase sempre, serem irreversíveis. E mais fácil mudar no início onde os custos são mais baratos.

Uma outra vantagem de se ter iterações curtas e adaptadas a realidade do seu projeto é aumentar o foco da equipe. Na abordagem tradicional, faz-se um esforço imenso para se definir é documentar todo o escopo do projeto. Produz-se uma extensa documentação, muitas vezes em processos alucinatórios. Já participei de times que tentavam planejar prazos 5, 6 anos depois da data atual. Acredite 5 ou 6 anos do momento presente em que estamos. Sem dúvida um exercício de futurologia.

Tentar definir todo o escopo antes de se quer iniciar o projeto é um erro. Precisamos levar em consideração no mínimo a premissa que o mundo dos negócios está em constante transformação, muda-se muito rápido. Os cenários que temos hoje, certamente não serão os mesmos que teremos daqui a 5 anos. As necessidades poderão ser outras, mas nós ainda esperamos que os planos não mudem, ou que mudem pouco.

Por isso, empenhe-se nas duas ou três primeiras iterações a estabelecer um período adequado para as iterações restantes. Lembre-se de seguir com o período estabelecido até o final do projeto. Uma boa dica é reservar um tempo para o não planejando e ir ajustando esse tempo com o time. A tendência é que este tempo diminua com a evolução do projeto e com a maturidade do time.

1. Para saber mais sobre este dado leia o post publicado pelo Mike Cohn em https://www.mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used

2. O Mapa não é o território é um dos 5 principais pressupostos da Programação Neurolinguística. O Mapa que no caso é o nosso plano de projetos dificilmente corresponderá ao campo em que vamos executar nosso projeto. O cenário é incerto. Contém riscos, cultura organizacional, mudanças tardias e outras causas que podem tirar o projeto do trilho. Para Robert Dilts os melhores mapas são aqueles que nos oferecem mais escolhas.

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.