Agile

Negociando a implantação de métodos ágeis com o Capitão Kirk e o Mr. Spock

~ Marco Mendes ~ Deixe um comentário

Jornada nas Estrelas foi uma série fora do seu tempo. Lançada no meio dos anos 60, essa série discutia guerra e paz, lealdade, autoritarismo, imperialismo, economia, racismo, existencialismo, metafísica, religião, direitos humanos, sexismo, feminismo e o papel da tecnologia. E tudo isso contado de forma leve e épica dentro do propósito da frota estelar de “audaciosamente ir onde nenhum homem jamais esteve”.

Esse série apresentava dois icônicos personagens, o capitão da nave James Tiberius Kirk e seu oficial Spock (o segundo em comando).

Kirk é passional, emotivo, intuitivo e com uma incrível facilidade para improvisar. Já Spock, filho de mãe terráquea e pai Vulcano, é racional, analítico, dedutivo e busca sempre ponderar e analisar todas as possibilidades antes de tomar as suas decisões.

Na série, eles tem diálogos que mostram suas naturezas distintas tais como:

– “Algumas coisas são impossíveis até o momento onde elas não são mais”, James. T. Kirk

– “Isso é altamente ilógico”, Spock

Para alguns fãs de ficção científica, Star Trek foi maior e mais importante que Star Wars. Mas não vamos iniciar uma guerra interplanetária aqui.

O Cérebro Humano – Spock e Kirk Juntos

Durante séculos, filósofos, psicólogos e cientistas distinguiram entre raciocínio intuitivo e o consciente. Platão, por exemplo, já falava em seu livro Psyche entre o nosso cérebro consciente (Logos), do nosso cérebro emocional – aquele dos desejos e apetite (Eros) e do afeto (Thymos).

Mais recentemente, Daniel Kahneman criou os termos sistema 1 e sistema 2 em livro “Rápido e Devagar”, que popularizou a distinção entre processos de pensamento automáticos e deliberados. O modelo de Kahneman divide os processos da mente em dois sistemas distintos:

O sistema 1 “é a abordagem rápida, automática e intuitiva do cérebro”, que apelido aqui de modo Capitão Kirk. A atividade do sistema 1 inclui as atividades mentais inatas com as quais nascemos, como uma preparação para perceber o mundo ao nosso redor, reconhecer objetos, orientar a atenção, evitar perdas. Outras atividades mentais tornam-se rápidas e automáticas através da prática prolongada.

O sistema 2 é “o modo analítico mais lento da mente, onde a razão domina”, que chamo aqui de modo Spock. Geralmente, a atividade do sistema 2 é ativada quando fazemos algo que não ocorre naturalmente e requer algum tipo de esforço mental consciente.

Daniel Kahneman fornece um exemplo comum usado para demonstrar os dois sistemas. Um taco e uma bola juntos custam US$ 1,10. O taco custa US $ 1 a mais que a bola. Quanto custa a bola? Diante desse quebra-cabeça, a maioria das pessoas adivinha instantaneamente 10 centavos. A resposta correta, no entanto, é de 5 centavos – o que, novamente, a maioria das pessoas pode resolver depois de passar mais tempo pensando sobre a questão.

Minimizando a resistência a mudanças

Quando buscamos implantar métodos ágeis, temos que ter atenção extrema às respostas dos outros. Peter Senge, exímio pensador sistêmico, já falava:

“As pessoas não resistem às mudanças. As pessoas resistem a serem mudadas”.

Ao reconhecer uma mudança, as pessoas podem trazer objeções no modo Kirk (Sistema Tipo 1 em ação) ou no modo Spock (Sistema Tipo 2 em ação).

O primeiro modo são receios emocionais tais como:

  • Dignidade
  • Respeito
  • Status
  • Identidade
  • Desejos
  • Confiança
  • Orgulho

O segundo modo está ligado a receios de natureza intelectual e aspectos que desafiam o seu modo de pensar. Busque reconhecer as objeções as mudanças quando você se depara como uma resistência.

David Anderson, líder da comunidade Kanban, nos apresenta as duas regras de ouro para lidar com objeções.

  1. Nunca combata uma objeção racional com um argumento emocional.
  2. Nunca combata uma objeção emocional com um argumento racional.

Trabalhar a primeira regra é menos complexo. Se você enfrenta objeções racionais, você pode desenvolver argumentos, trazer fatos e dados para criar um debate. O Spock que habita o cérebro racional da pessoa eventualmente fará as conexões.

A notícia ruim é que na grande maioria das vezes as objeções são emocionais. E enfrentar o capitão James T. Kirk não é tarefa simples. Se você enfrenta uma objeção emocional, você precisa trazer uma emoção ainda mais forte para lidar com a resistência. Emoções mais fortes podem ser aquelas que irão gerar neurotransmissores positivos como dopamina, oxitocina, serotonina e endorfinas ou mecanismos de urgência gerados por descargas de adrenalina e cortisol.

Cito aqui um caso extremo onde pude observar que um gerente de projeto que não aceitou uma mudança de papel para um novo papel de Scrum Master. Se uma mudança de papel afeta a dignidade ou identidade de um funcionário e ele resiste, uma ação que gera uma emoção mais forte (embora negativa) seria uma ameaça de demissão. E foi isso que o diretor fez. Ele ameaçou o gerente de projeto e disse que a mudança era mandatória. O medo de não ter comida ou casa é mais forte (gera adrenalina e cortisol) e sobrepuja o receio da sua mudança de identidade.

Não queremos, óbvio, fazer a mudança pelo medo. Até porque agile coaches não são, normalmente, ou donos das organizações. E mudanças baseadas em medos podem gerar efeitos colaterais muito ruins. Encontrar uma emoção mais forte pode ser difícil e demorado nesses casos, mas é o caminho para combater objeções emocionais. O método Kanban, por exemplo, não busca trabalhar reorganizações ou mudanças de papel na sua introdução pois esses tipos de mudanças estão mais suscetíveis a mudanças que ativem caminhos límbicos de pavor, medo ou perda da identidade.

Um exemplo positivo que pude observar em um time estava ligado a troca do trabalho empurrado para trabalho puxado em um time ágil. Havia uma cultura Scrum de assumir um lote de funcionalidades de uma única vez em uma reunião longa e demorada de Planejamento de Sprint. No final da reunião as funcionalidades já eram atribuídas aos desenvolvedores dessa organização. A gerente percebeu que esse modelo levava a falhas contínuas de entrega. As promessas eram continuamente quebradas. E isso minava a confiança dos diretores e clientes nesse time. Inicialmente a gerente tentou introduzir a mudança para um sistema puxado onde as demandas seriam trazidas uma por vez apenas quando houve capacidade disponível do time. Ao tentar propor a mudança, o time resistiu. Havia uma identidade muito forte ligada a papéis e práticas do Scrum.

Ela então buscou uma abordagem alternativa baseada em princípios Kanban. Primeiro, ela não atacou a identidade do time. Ela teve paciência. Durante algumas semanas ela melhorou a gestão à vista mostrando o trabalho em andamento, impedimentos e bloqueios. Ela também construiu métricas de fluxo como histogramas de tempo de ciclo e fluxos cumulativos de valor. Isso permitiu que as retrospectivas mudassem de momentos de pura lamentação para conversas mais ricas. A gerente também teve cuidado de apontar os problemas sobre o trabalho e não sobre os trabalhadores. A partir de conversas mais ricas e um ambiente seguro para falhar, o time desenvolveu uma base emocional mais sólida para lidar com os problemas de previsibilidade. Depois de poucos meses o time estava emocionalmente preparado para fazer a mudança de um trabalho empurrado para um trabalho puxado. E com o suporte de histogramas de tempo de ciclo o time agora era capaz de trabalhar previsibilidade sobre demandas novas para o seu sistema de trabalho.

Definitivamente, um caminho longo e duro. Mas é necessário quando um agente de mudança enfrenta objeções emocionais no seu caminho e queira criar mudanças consistentes e perenes.

A mensagem aqui é que criar uma cultura de agilidade de negócio é complexo. Não existem receitas de bolo. Ao mesmo tempo, existe hoje uma ampla base sociológica e de práticas de gestão para orientar agentes de mudanças ou agile coaches.

“Live long and prosper”, Mr. Spock.

Resiliência ou Morte

~ Marco Mendes ~ Deixe um comentário

O evento da COVID-19 trouxe estressores fortes para toda a humanidade. E no meio empresarial ele provocou muitas demissões e até mesmo o fechamento de muitas empresas. O segmento de turismo e de aviação, por exemplo, foi brutalmente impactado.

Curioso, entretanto, é que fenômenos como a COVID-19 não são raros na história humana e também das organizações. Há exatamente 100 anos atrás os mesmos debates sobre isolamento social e uso de máscaras se formaram quando a gripe espanhola dizimou milhões de pessoas. Riscos e incertezas, com toda certeza, vão surgir nas próximas décadas com as mais diferentes formas. Sempre foi assim e sempre será assim.  

Quando olhamos para esses fenômenos, podemos classificá-los em três tipos.

Águas Vivas, Elefantes e Cisnes Negros

Uma água viva negra representa eventos ou fenômenos que tem o potencial de se tornarem pós-normais através de escala imensa e instantânea. As águas vivas negras são classificados como desconhecidos conhecidos (Unknowns knowns) — coisas que achamos que conhecemos e entendemos, mas que acabam por ser mais complexas e incertas do que esperamos. Enchentes, crises financeiras e acidentes trágicos são exemplos desses fenômenos.

Temos também um outro tipo de fenômeno chamado de elefantes negros. É um evento que é extremamente provável e amplamente previsto por especialistas, mas as pessoas tentam passá-lo como algo muito exótico (um tipo de Cisne Negro) quando finalmente acontece. Elefantes negros são classificados como conhecidos desconhecidos (Knowns unknowns). A COVID-19 por exemplo, é um tipo de fenômeno como esse. Epidemias e pandemias sempre ocorreram e são previstas por especialistas há décadas e se você fizer uma pesquisa rápida de pandemias na Internet você verá o quanto esse tipo de fenômeno é recorrente na história humana.

Finalmente, temos os cisnes negros, que podem ser negativos ou positivos. São eventos extremamente raros e tem três propriedades básicas.

  • O evento é imprevisível (para o observador)
  • O evento tem ramificações generalizadas
  • Depois que o evento ocorreu, as pessoas afirmam que foi realmente explicável e previsível (viés retrospectivo).

O ataque as torres gêmeas, o surgimento da Internet ou a dissolução da União Soviética são exemplos desse tipo de fenômeno. Esses eventos são chamados de desconhecidos desconhecidos (Unknowns unknowns).

Uma empresa que queira prosperar em tempos de incertezas precisa operar além da agilidade de negócio. Ela precisa ser ágil e também resiliente. A robustez é peça fundamental para você operar nas incertezas – os conhecidos desconhecidos; os desconhecidos conhecidos e os desconhecidos desconhecidos.

Um caso concreto é o das empresas Kodak e Fujifilm. Ambas as empresas faturavam 15 bilhões em 2000. A Kodak faliu e o caso é contato e recontado em prosas empresariais. Já empresa Fujifilm hoje fatura mais de 20 bilhões de reais porque desenvolveu um portifólio diversificado, criou robustez e soube lidar bem com o declínio dos filmes das câmeras analógicas.

Resiliência organizacional deve ser um valor cultural

Julian Birkinshaw, professor de empreendorismo da Business London School, classifica a resiliência organizacional em três níveis (Robustez estratégica, operacional e no nível pessoal).

  • Capacidade de resiliência estratégica da organização para monitorar e responder às mudanças no contexto e permanecer relevante para os clientes.
  • Capacidade de resiliência operacional para manter as operações principais funcionando, desde o fornecimento de produtos e serviços até o financiamento de negócios.
  • Capacidade de resiliência pessoal de funcionários e líderes individuais para suportar circunstâncias difíceis por longos períodos

A tese dele, mais relevante do que nunca, é que a resiliência deve ser um valor e também uma capacidade de negócio da sua organização. Valores definem a cultura. A cultura forma as práticas diárias. E as práticas apropriados para o contexto criam bons resultados de negócio.

Um mapa para a resiliência em organizações

Gosto muito da abordagem do KMM, um modelo de maturidade organizacional baseado no método Kanban. Ele possui princípios inspirados na teoria de antifragilidade de Taleb. Esses princípios permitem que você entenda a maturidade dos serviços de uma organização e introduza estressores apropriados para aquele nível de maturidade. Nem mais nem menos. E junto com mecanismos de reflexão periódicos e atos de liderança o modelo cria um mapa seguro para que serviços empresariais evoluam em uma jornada de fragilidade para a resiliência, robustez e antifragilidade.

O poster em tamanho grande pode ser baixado do sítio em http://www.kanbanmaturitymodel.com

A mensagem é clara. Empresas que querem sobreviver devem se parecer mais com camelos feiosos que sobrevivem em desertos do que com unicórnios fofinhos. Ser resiliente é uma condição essencial a toda organização em tempos pós-normais.

“Difficult to see. Always in motion is the future” , Master Yoda

As 10 práticas de agilidade mais populares do planeta em 2020

~ Marco Mendes ~ Deixe um comentário

Métodos e frameworks ágeis como Scrum, Safe, LESS, DevOps ou Kanban não são atômicos. Eles são compostos por várias práticas de processo. Uma prática é uma estrutura pequena, uma parte do todo. E as partes organizadas em uma coleção ajudam a criar a essência e o comportamento do todo.

Entretanto, um método ágil não é apenas a soma de suas práticas constituintes. Quando examinamos partes e seus coletivos podemos ter arranjos muito interessantes.

  1. Por exemplo, podemos ter partes individualmente estúpidas e coletivos muito inteligentes. A epidemia do CoVid-19 é um exemplo de um organismo coletivo muito inteligente (e perverso) formado a partir de partes individuais estúpidas.
  2. Podemos ter também coletivos inteligentes formados por partes individualmente inteligentes. Por exemplo, uma matilha de orcas caçando um cardume de atuns é um exemplo desse arranjo.
  3. Um outro arranjo são coletivos poucos inteligentes formados por partes inteligentes, como uma carreata de pessoas, individualmente boas, defendendo uma ideologia política dogmática. O mesmo acontece em torcidas organizadas em estádios de garbo e elegância por todo o Brasil.
  4. Finalmente, temos também arranjos coletivos ruins formados por partes individualmente ruins. Se você já tentou fazer bom prato de comida com ingredientes ruins você entendeu a mensagem aqui.

Uma boa prática de processo não irá garantir um bom método (o nosso coletivo de práticas). Mas você não terá um bom método ágil com práticas pouco adaptadas na sua realidade prática. Ou seja, um ponto de partida ainda melhor que métodos quando pensamos em implantações ágeis é o conceito de práticas de processo. Práticas são recombináveis e podem ser experimentadas em virtualmente qualquer ambiente.  Práticas são seguras para falhas pois podem ser facilmente abandonadas se não se mostrarem viáveis.

E, principalmente, práticas são muito mais robustas do que grandes frameworks ágeis inerentes frágeis e que exigem pesados investimentos em treinamentos e reorganização de empresas.

As 10 Práticas de Agilidade Mais Populares em 2020

O Relatório do Estado da Agilidade publicou em 2020 as práticas ágeis mais adotadas por mais de 1100 entrevistados. Os resultados foram:

  1. Reunião Diária – 85% dos entrevistados.
  2. Retrospectivas – 81%
  3. Planejamento de Sprints – 79%
  4. Demonstrações/Revisão de Sprints – 77%
  5. Iterações Curtas – 64%
  6. Kanban – 63%
  7. Estimativas de Time – 60%
  8. Product Owner/Cliente Dedicado – 54%
  9. Planejamento de Releases – 51%
  10. Time integrado (Devs e Testers integrados) – 51%

Algumas interpretações a partir desses dados seguem abaixo.

1.As quatro primeiras práticas estão ligadas a cadências (ou ritos). Cadências formam um tipo de ciclo de feedback fundamental para que sistemas de trabalho possam ser melhorados em ambientes complexos. Muito vezes subestimadas ou tratados com desdém, devemos ter extrema atenção à execução dessas práticas.

Quando facilito essas cadências,  por exemplo, sempre uso um quadro Kanban (prática #6), com o uso da seguinte heurística: foco no trabalho e não nas pessoas. Para a retrospectiva, foco no trabalho entregue na coluna Terminado. Para a reunião diária, sempre pergunto ao quadro o trabalho que está em execução (Work In Progress). E para reuniões de reabastecimentos como o Planejamento de Sprints sempre olho para a coluna de histórias e pronto para iniciar.

2. A prática #5 está ligada a ciclos curtos, também propriedade fundamental de sistemas complexos adaptativos. Times ágeis normalmente trabalham com ciclos entre 1 a 4 semanas. Ciclos menores

3. A prática #6 está ligada a transparência, gestão à vista e gestão de riscos. Quadros Kanban também são um alicerce importante para observar sobrecarga e criar um ambiente de discussão para a introdução de políticas de melhoria.

4. A prática #7 mostra que quase dois terços do mercado ainda definem compromissos baseado em estimativas. É um sinal que existe muita oportunidade de avanço com o uso de elementos mais maduros e robustos que envolvem previsibilidade, métricas de fluxo e o movimento #noestimates. Tenho a esperança que essa prática não apareça mais aqui quando o mercado ganhar mais maturidade.

5. A prática #8 mostra que metade dos times já conseguem ter pontos focais dedicados para interagir com seus clientes. Isso é positivo em minha opinião pois mostra que a interface com áreas clientes está em franca melhoria.

6. A prática #9 exibe que metade dos times estabelecer planos de lançamento no mercado com produtos mínimos viáveis e entregas parciais. Me parece ser um passo de maturidade quando comparamos com abordagens de construção de elefantes em projetos que demoravam muitos anos.

7. Finalmente, a prática #10 mostra esforços de reorganização para a quebra de silos funcionais em metade das organizações. O uso de times multidisciplinares é sem dúvida um facilitador para times operarem e melhorar suas eficiências de fluxo. Vale apenas o ponto de atenção que não é uma receita de bolo que possa ser aplicada em qualquer contexto e não precisar estar no caminho obrigatório de qualquer implantação de agilidade.

Estudar e aplicar práticas é robusto. Quando você combina boas práticas em bons arranjos você poder criar, por emergência sistêmica,  um método muito mais poderoso que as práticas individuais.

 

Scrum ainda mais medíocre – Mais disfunções ágeis e mais antídotos

~ Marco Mendes ~ Deixe um comentário

Publiquei na semana passada um post sobre disfunções ágeis comuns na implementação do framework Scrum.

São elas.

  1. Reunião diária Zombie
  2. Trabalho empurrado
  3. Métricas míopes
  4. Servidão ao backlog
  5. Escopo fixo e prazo aberto

Apontamos também alguns antídotos para essas disfunções, que são:

  1. Pergunte ao quadro Kanban
  2. Trabalho puxado
  3. Métricas acionáveis
  4. Gestão do upstream
  5. Fluxo contínuo e MVPs

Caso ainda não tenha lido recomendo a leitura para contexto.

Dando sequência ao tema de disfunções ágeis, relato aqui mais disfunções ágeis que podem drenar todo o dinheiro da sua iniciativa ágil como um chupa-cabra de métodos ágeis. Mais à frente, apresentamos antídotos para esses problemas.

Mais 5 disfunções ágeis

  1. Critério de preparado (Ready) ausente ou mal especificado

Um problema comum em vários times que operam Scrum é não estabelecer um acordo claro para aceitar um requisito e iniciar a sua construção. Isso se manifesta com reuniões de planejamento longas e cansativas e, pior, problemas de entendimento que acompanham a sprint e um número excessivo de defeitos de negócio em ambientes de produção.

  2. Critério de aceite (Acceptance) ausente ou mal especificado

É também comum quando POs novatos ou que estendem a confiança ingenuamente não definem os critérios de aceite funcionais e não-funcionais externos, como por exemplo a usabilidade, performance ou segurança.

“O óbvio é individual”, já disse um sábio certa feita. Assumir que o time de engenharia de produtos irá incorporar aspectos de qualidade porque aquilo é óbvio é uma decisão ingênua.

3. Critérios internos de qualidade ausentes

Quando desenvolvedores e QAs olham apenas para os requisitos funcionais, uma dívida técnica será naturalmente introduzida dentro do sistema. A razão é a entropia crescente nesses sistemas complexos.  Exemplos incluem:

  • Ausência de automação de testes
  • Códigos-fonte sujos (mal-cheiros)
  • Arquiteturas de software erodidas
  • SQLs ineficientes
  • Problemas de segurança

Se um time não age proativamente e introduz políticas para pagamento permanente da dívida técnica, os sistemas irão apenas degradar ao longo do tempo e eventualmente gerarem problemas gravíssimos para suas áreas de negócio.

4. Ausência de folgas (Slack) e previsibilidade inconsistente

Tom de Marco escreveu um livro muito instigante em 2001 (Slack) mostrando a estupidez da hiper-otimização dos trabalhadores do conhecimento e os seus efeitos ruins para as pessoas e também para a própria organização em médio e longo prazo.

Nicholas Taleb também nos adverte, de forma ainda mais contundente no seu livro Antifragilidade – Coisas que se beneficiam do caos, da fragilidade inerente de organismos hiper-otimizados. A natureza e os sistemas complexos amam redundâncias.

Donald Reinertsen, outro grande pensador, nos mostra também que sistemas de trabalho ocupados afetam brutalmente e negativamente a previsibilidade de entrega de novas funcionalidades.

Livro Slack - Tom de Marco

Livro Antifragilidade - Taleb

Princípios de Fluxo no Desenvolvimento de Produtos

Assumir que alguém trabalha exatamente 7 ou 8 horas por dia e tentar alocar o esforço de pessoas como se fossem máquinas é ruim economicamente para a organização, psicologicamente para as pessoas e também para a previsibilidade de entregas.

Em linguagem simples, você observa essa disfunção através de sprints “que falham”, i.e, não entregaram todo o “escopo” porque as pessoas não “trabalharam” de forma eficiente. Ou titica de galinha sobre esterco de vaca.

5 – Heroísmo. Ou síndrome de Tanus.

Outra disfunção comum é esperar que pessoas e times ágeis irão ter comportamentos heróicos e irão fazer o que for necessário para bater as “metas” definidas pela gerência.

O heroísmo na construção de produtos digitais é um fenômeno estudado há décadas. E a “má notícia” é que não existem heróis. Você não está em um filme de espionagem onde hackers com “intelecto avançado” teclam um monte de comandos mágicos e o sistema começa a operar. E até nos filmes mais recentes, basta alguém estalar os dedos e metade dos heróis vai embora.

Modelos de maturidade mais modernos, como por exemplo o excelente Kanban Maturity Model, mostram que o heroísmo é um sintoma de serviços de baixa maturidade (ML1). Não é algo sustentável em médio e longo prazo e impede a criação de serviços previsíveis e aptos para o propósito de negócio.

Mais Antídotos

1. Gestão do Upstream (para o critério de Preparado  mal especificado)

A gestão de upstream é uma técnica descrita no KMM (Kanban Maturity Model) e assunto central do livro Essential Upstream Kanban.

Livro Essential Upstream Kanban

Entre o Upstream (território do PO) e o Downstream (território da engenharia e Scrum Masters) existe o ponto de compromisso que precisa ser bem estabelecido através de políticas explícitas, prática geral de todo sistema Kanban maduro.

2. Compromisso em duas fases (Two Phase Commit)

Sistemas de trabalho bem estruturados devem ter não apenas o ponto de compromisso bem estabelecido para iniciar o trabalho. Devem ter também o ponto de compromisso onde o trabalho seja aceito. E para isso precisamos ter políticas explícitas indicam como o trabalho deve ser entregue para ser considerado como finalizado.

Se você quer que o seu copo de água seja servido em copo de vidro, com duas pedrinhas de gelo e uma rodela de limão siciliano, explicite isso no começo do jogo. O combinado não é caro.

O Two Phase Commit é uma técnica Kanban que reduz, semana após semana, a ambiguidade para iniciar e fechar um trabalho do conhecimento. Ela permite que você crie critérios de preparado e de aceite incrementais e que funcionem na sua realidade objetiva.

3. Critérios internos de qualidade

Ninguém em sã consciência pede para um cozinheiro não lavar as verduras para apressar o preparo dos pratos. E provavelmente cozinheiros profissionais não aceitariam essa proposta estranha. Lavar as verduras é dever ético e de higiene em uma cozinha profissional.

Da mesma forma, nenhum desenvolvedor deveria negociar aspectos básicos da higiene do seu código no dia a dia. Refatorar e fazer testes de unidade devem ser parte integrante e diária do trabalho. Como tomar banho e escovar os dentes. E não um trabalho adicional que deveria ter permissão gerencial.

Lógico. Falar isso é fácil. E reconheço que isso é ainda muito difícil em ambientes abusivos onde metas de prazo são impostas de cima para baixo e não descobertas pela vazão do time.

Mas é dever ético de qualidade de um time expor e brigar por seus critérios internos de qualidade. Git Pull Requests, Pair Programming, Mob Programming, Testes de Unidade, Refatoração, entre outras práticas, são exemplos nesse sentido.

E se você quiser se armar com argumentos sólidos para conversar com a sua chefia, recomendo dois clássicos a respeito do sempre incansável Uncle Bob, um dos signatários do Manifesto Ágil de 2001.

4. Limitar o trabalho em progresso, políticas explícitas e gestão do fluxo (para atacar o problema de previsibilidade)

Times sem políticas de limitação do trabalho e outras políticas explícitas são facilmente abusados no seu dia a dia. Um dos papéis de um sistema de trabalho é conhecer e estabelecer a capacidade de trabalho apropriada para um time em um contexto real de forma a:

  • Reduzir os prazos de entrega
  • Reduzir a variabilidade.

Fato curioso é que o tempo médio de entrega é inversamente proporcional ao volume de trabalho em progresso, como já nos mostrou John Little ainda nos anos 60 na sua Lei de Little.

Quando você introduz sistemas Kanban sobre times que estão operando o framework Scrum, você ganha consciência da utilização de trabalho mais apropriada para aquele time e evita problemas de sobrecarga que se manifestam como engarrafamentos (muita coisa para fazer, muito estresse, pouca vazão e resultados pífios).

5. Limitar o trabalho em progresso, políticas explícitas e gestão do fluxo (para atacar o problema de heroísmo)

O heroísmo é sintoma de um sistema de trabalho frágil, i.e., onde as metas são impostas de cima para baixo sem conhecer a vazão possível e ideal dos times. É um sintoma de um sistema desequilibrado, onde medições não são realizadas consistentemente, onde políticas corretas estão ausentes e sistemas de feedback não estão instalados.

Novamente, o mesmo antídoto aplicado no item 4 pode ser usado para identificar as causas raízes que levam aos atos de heroísmo, introduzir hipóteses de melhoria e com base no pensamento científico testar e manter as hipóteses que melhorem o sistema de trabalho. Através de um processo contínuo de melhorias através da abordagem de mudanças evolucionárias, criamos um sistema robusto de trabalho em médio e longo prazo.

A mensagem desse post é simples. Faça uso do sistema de gestão de mudanças Kanban para melhorar o seu trabalho como Scrum Master.

 

Scrum Medíocre – 5 Disfunções ágeis e seus antídotos

~ Marco Mendes ~ 1 comentário

O Scrum é o framework ágil mais usado na comunidade ágil. Desenhado ainda nos 90, ele trouxe um guia acionável para organizar e entregar projetos com ideias muito boas tais como:

  • Ciclos PDCA de curto prazo (Sprints) e ritos para sistematizar esses ciclos (planejamento de sprint, reunião diária, revisão e retrospectiva)
  • Papel de facilitador do método, combinando funções de processo e de gestão (Scrum Master)
  • Papel de interface com áreas de negócio e conceito mais claro de produto (Product Owner)
  • Times multidisciplinares (ao invés de pessoas que trabalham sozinhas e não colaboram).

Entretanto, a forma como o Scrum foi implementado em muitas organizações lá fora e no Brasil criou um monstrinho que apelido aqui de Scrum Medíocre. É fácil reconhece-lo através de disfunções comuns. Enumero 5 dessas disfunções ágeis aqui.

Reunião diária zombie

SM: – João, o que você fez ontem?
SM: – E você, Maria, o que fez ontem?
SM: – José, meu filho, me fala o que fez ontem?

João, Maria e José, como zombies, respondem de forma catatônica às perguntas do Scrum Master comando e controle. Eles estão com sono, não querem estar ali em pé, detestam aquele momento e estão contando os minutos para voltar às suas mesas e colocar o fone de ouvido.

Qual o problema aqui? Foco nas pessoas e não no trabalho.

Trabalho empurrado

Primeiro dia da Sprint 
PO: – Time, nos temos 7 histórias que devem ser completadas em 10 dias úteis. Ordens da chefia. João, você pega as histórias 1 e 2. Maria, você que é sênior irá trabalhar nas histórias 3, 4 e 5. José, conto com você para cuidar das histórias 6 e 7.

Ultima dia da Sprint
O time não entrega nem 50% do trabalho empurrado e é culpado pela sua performance ruim. Uma reunião de retrospectiva é chamada onde o time tem a sua atenção chamada pelos problemas de desempenho.

Primeiro dia da próxima sprint
A mesma história se repete.

Métricas míopes

Tudo o que o time conhece são sprints e suas métricas locais. O time estima com planning poker, tamanho de camisa e afins. E ele mede a sua produtividade local com gráficos de burndowns.

Mas se você pergunta a qualquer um, até mesmo o PO, quanto tempo demora em média uma demanda para fluir da chegada até a produção, a resposta é nula. Nenhuma métrica acionável de cliente é usada pelo time.

Servidão ao backlog

O backlog é cultuado como se os desejos ali colocados fossem ordens de Deus. O PO e o time não fazem nenhum engenharia de valor e o foco é puramente centrado na entrega de funcionalidades. O % de completude de backlog é usado como métrica de sucesso da iniciativa, centrada puramente em escopo.

Projetos centrados em escopo fixo e prazo aberto

O escopo, ao invés do tempo, é o principal guia para organizar quando um projeto deve terminar. Se um time trabalha 3 meses e o escopo não foi cumprido, novos sprints são abertos até que o escopo seja completado. O conceito de prazo fechado e MVPs são completamente ignorados. O dinheiro é drenado como em projetos tradicionais pelo modelo mental da fixação ao escopo.

Muitas dessas disfunções tem sido amplamente debatidas por agilistas que assinaram o Manifesto Ágil como Martin Fowler, Robert Martin (Uncle Bob) e Allistair Cockburn.

Juntas, essas disfunções criam um cenário terrível de agilidade burocrática que drenam o dinheiro do seu time como um tipo de chupa-cabra do mal.

chupacabra

Antídotos ao Scrum Medíocre

A boa notícia é que você pode incorporar ideias antifrágeis ao seu sistema de trabalho para sair da mediocridade Scrum.

Pergunte ao quadro (Antídoto para a Reunião Diária Zombie)

Ao invés de perguntas para as pessoas sobre o que elas fizeram ontem, pergunte ao quadro. Faça a reunião diária com o quadro Kanban aberto. Navegue da direita para a esquerda (e não da esquerda para a direita). Você quer terminar itens mais que começar novas coisas e aumentar de forma ingênua o trabalho em progresso.

Para cada cartão navegado, pergunte se existem gargalos. Exemplos de gargalos incluem itens bloqueados, tarefas que estão há muito tempo no quadro ou limites ao trabalho em progresso. Quando um gargalo é encontrado, você incentiva ações do time para desbloquear itens bloqueados ou atuar sobre itens parados. Mostre ao time que estamos interessados em fazer o trabalho fluir.

Em resumo. Não pergunte o que o João, Maria e José fizeram ontem. Queremos gerenciar o trabalho e não as pessoas. Essa pequena mudança de comportamento faz o time perceber que você está preocupado com a entrega. E não microgerenciamento do trabalho deles.

Trabalho puxado (Antídoto para o trabalho empurrado)

Ao invés de um trabalho empurrado de forma comando e controle para o time, o PO deve apenas alimentar uma coluna de pronto para começar.

E o time deve puxar o trabalho sob demanda, um item por vez. Ou seja, o time se compromete com poucas coisas. Isso cria foco para o time e reduz sua ansiedade. O compromisso estabelecido cria um trabalho que deve fluir pelo sistema e com a ajuda de reunião diária efetiva irá fluir.

O PO observa a vazão média de itens por  quinzena ou mês. E essa vazão permite que ele comece a compreender a dinâmica do time e a sua capacidade de entrega. E então ele fornece itens dentro da vazão possível pelo time. A realidade deve guiar o PO e não fantasias imaginárias de produtividade.  O trabalho puxado é o melhor aliado do PO para aumento da eficiência do seu time.

Métricas Acionáveis (Antídoto para métricas míopes)

O PO, SM e time devem observar duas métricas centrais na ótica dos clientes que são:

  • O tempo de ciclo das entregas (lead time)
  • A vazão das entregas (taxa de entrega de demandas em base semanal ou quinzenal)

Por quê?

Porque clientes querem saber quanto tempo um time vai demorar para fazer um trabalho e quantos itens são entregues por período (ou sprint).

Em última instância, essas métricas observam se o seu sistema de trabalho é solido, i.e, como o trabalho flui desde o momento do compromisso até o momento do aceite. Como o tempo médio, sua distribuição e a vazão estão se comportando dentro de cada etapa do seu fluxo de trabalho.

Ou seja, essas métricas permitem que você analise gargalos, critérios de aptidão para os seus clientes e lhe permitem estabelecer previsibilidade de trabalhos futuros. Se um time descobre, por exemplo, que o seu time demora 9 dias para entregar um trabalho comprometido, você consegue estabelecer compromissos baseados na realidade objetiva do histórico do seu time.

Gestão do Upstream (Antídoto para a Servidão ao Backlog)

A gestão do upstream é uma técnica onde o PO pode organizar um quadro Kanban específico para identificar, realizar processos de triagem, engenharia de valor e entregar itens prontos para a execução para o time de desenvolvimento de produtos.

Os processos de “triagem” de ideias podem eliminar demandas antes de irem para o time. Essa mortalidade é positiva. Isso gera economia de tempo e consequentemente de custo.

Além disso, o upstream também busca entender a melhor cadência para entregar os itens para o time de desenvolvimento de produtos e qual deve ser a taxa de entrega de itens em base periódica conforme a taxa de consumo viável do time de desenvolvimento. Um quadro de upstream que entrega trabalho além da capacidade de vazão do time de execução (chamado de downstream) gera um backlog  extenso. E essas demandas se tornam obsoletas enquanto aguardam serem atendidas

Fluxo Contínuo e MVPs (Antídoto para projetos centrados em escopo fixo e prazo aberto)

O conceito de fluxo contínuo é um antídoto que pode ser usado em times de maior maturidade. E é incrivelmente poderoso. Ao invés de fixação em projetos com escopo fixo que levam invariavelmente a conflitos terríveis entre times e clientes, buscamos entregas de fluxo contínuo.

Trabalhar em fluxo contínuo significa que um time pega um item quando tem capacidade disponível, se organiza para entregar o item de ponta a ponta dentro do menor tempo de ciclo possível e agrega valor de negócio incrementalmente.

Trabalho com fluxo contínuo em TI não é trivial e requer também que o custo de transação para implantar em produção seja baixo. Isso muitas vezes requer arquiteturas centradas em microsserviços e práticas DevOps CI/CD bem estabelecidas. Mas se você tem as premissas apropriadas, pode ser uma abordagem muito interessante.

O Catálogo de Antídotos do Método Kanban

Cada um desses antídotos faz parte do método Kanban. O método Kanban não é uma alternativa ao Scrum. Ao invés, ele é uma ferramenta para você introduzir mudanças no seu sistema de trabalho centrado em Scrum. Ele é uma lente de análise para você observar o trabalho do seu time, detectar fragilidades e melhorar continuamente o seu sistema de trabalho. Da fragilidade para a resiliências, robustez e então antifragilidade.

O método Kanban lhe fornece esteróides naturais para você introduzir estressores no seu Scrum e sair de um Scrum medíocre para um Scrum de alta maturidade.

Quer melhorar o seu Scrum? Adote práticas Kanban.

“The fragile wants tranquility, the antifragile grows from disorder, and the robust doesn’t care too much”, Taleb.

 

Um panorama de métodos para aumentar a agilidade de negócios

~ Marco Mendes ~ Deixe um comentário

A agilidade de negócios se tornou um imperativo para muitas organizações. Inovar, criar produtos melhores, engajar mais clientes, encurtar o tempo de ciclo e reduzir desperdícios são alguns dos desafios que atormentam muitos gerentes nas empresas do Brasil e do mundo.

Os métodos ágeis tem sido usados, nos últimos 20 anos, para buscar entregar agilidade de negócios e apoiar gestores e times em linhas gerais. Mas se em 2001 podíamos enumerar os tipos de métodos ágeis em uma única mão, hoje o ecossistema ficou muito mais complexo. Os métodos, frameworks e práticas se multiplicaram e a simples escolha de qual método usar para apoiar as iniciativas de agilidade de negócio se tornou um desafio.

Nesse contexto, trago aqui uma compilação de 11 métodos ligados à agilidade de negócios e que tem obtido alguma visibilidade nos últimos anos.

Método Kanban

O método Kanban é uma abordagem de gerenciamento e melhoria de sistemas de fluxo e que busca criar um modelo evolucionário de aumento de maturidade nas organizações. Ele é uma alternativa a abordagens pesadas que introduzem mudanças radicais, reestruturações organizacionais e modelos prescritivos desconectados da realidade objetiva de cada organização.

O método Kanban foi criado por David Anderson a partir das suas experiências na Microsoft no começo do século e hoje é um dos métodos mais promissores na comunidade ágil.

Ele é mantido pela Kanban.University, que fornece uma trilha de cursos de formação e uma coleção de práticas provadas em centenas de organizações nos últimos 15 anos.

O método Kanban é acelerado por duas ferramentas conceituais poderosas:

  1. STATIK, que é uma abordagem sistêmica para introduzir sistemas Kanban em organizações. Um excelente artigo sobre ele pode ser encontrado aqui no LinkedIn do David Anderson.
  2. KMM, que é um modelo de maturidade organizacional baseado em sistemas Kanban.

Livro chave:

Management 3.0

O Management 3.0 é uma coleção de jogos, ferramentas e práticas em constante mudança para ajudar qualquer trabalhador do conhecimento a gerenciar o seu trabalho em organizações. Ele é uma maneira de ver os sistemas de trabalho em contextos complexos e melhorar esse sistemas.

O Management 3.0 é centrado em seis pilares.

  1. Energizar Pessoas: As pessoas são as partes mais importantes de uma organização e os gerentes devem fazer de tudo para manter as pessoas ativas, criativas e motivadas.
  2. Empoderar Equipes: As equipes podem se auto-organizar, e isso requer empoderamento, consentimento e confiança da gestão.
  3. Alinhar Restrições: A auto-organização pode levar a qualquer coisa e, portanto, é necessário proteger as pessoas, compartilhar recursos, dar às pessoas um propósito claro e metas definidas.
  4. Desenvolver Competências:  As equipes não podem alcançar seus objetivos se os membros da equipe não forem suficientemente capazes, e os gerentes devem, portanto, contribuir com o desenvolvimento de competências.
  5. Crescer a Estrutura: Muitas equipes operam em um contexto de uma organização complexa. E assim é importante considerar estruturas que favoreçam a comunicação.
  6. Melhorar Tudo: Pessoas, equipes e organizações precisam melhorar continuamente.

Publicado oficialmente em 2010 em Jurgen Appelo, o M3.0 teve grande receptividade no Brasil e hoje conta com uma forte comunidade de facilitadores e praticantes.  O portal Management 3.0 contém informações oficiais sobre esse método.

Livro Chave:

DevOps

O DevOps é um movimento cultural habilitado por práticas, técnicas e ferramentas e que tem por objetivo reduzir tempos de ciclo na entrega de produtos de TI, reduzir retrabalhos e habilitar a inovação organizacional.

O DevOps é baseado nos princípios do acrônico CALMS.

  • Cultura
  • Automação
  • Lean
  • Medições
  • Sharing (Compartilhamento de informações)

Na perspectiva mais pragmática, o DevOps é conhecido pelas seguintes práticas técnicas:

  • Automação de Testes
  • Integração Contínua
  • Entrega Contínua
  • Infraestrutura como código
  • DevSecOps
  • Engenharia do Caos

O portal IT Revolution, mantido por Gene Kim, um dos líderes desse movimento, possui uma coleção rica de informações e livros para você se aprofundar nessas práticas.

Mantenho também no meu blog diversos artigos sobre DevOps acessíveis a partir desse link: https://marco-mendes.com/devops/

Livro chave:

OKR – Objetivos e Resultados Chave

Esse é um método para lidar com o problema de definição e execução de metas. A definição de metas tradicional em exercícios de planejamentos estratégicos anuais, geralmente envolve declarações de objetivos criados em torres de marfim desconectadas da realidade operacional, mal comunicadas e cascateados de cima para baixo. Como consequência, a taxa de fracasso é alta.

O OKR, ao invés, é uma estrutura leve para definir e rastrear objetivos e seus resultados baseada em ciclos curtos (até 3 meses), envolvimento de todos na definição de metas e uma abordagem colaborativa para resolver e integrar dependências e conflitos.

O OKR traz como benefícios:

•Foco e disciplina: Poucos objetivos, gerando foco na organização;
•Alinhamento entre equipes: Interdependências funcionais entre os times integradas e resolvidas pelo método;
•Transparência: Todos os OKRs são públicos e possibilitam um alinhamento entre os objetivos e a visão da empresa;
•Gestão e Performance : Os OKRs são acompanhados em base periódica pelos próprios times que definiram as metas;
•Accountability: Todos passam a ser responsáveis por seus objetivos, com critérios claros de sucesso, conhecidos por toda a empresa;
• Centrado em dados: Os resultados chave são quantitativos e centrados em métricas acionáveis (ao invés de métricas de vaidade).
O portal What Matters traz uma rica coleção de recursos sobre OKR. No Brasil, recomendo também o portal do Felipe Castro, pioneiro de OKR no Brasil.

Livro Chave:

Modelo de Fluência Ágil

O modelo de Fluência Ágil ajuda os times a entender onde eles estão em termos de seus próprios objetivos, e entender o que é relevante para o seu contexto e necessidades específicas.
Esse modelo é resumido no seguinte esquema e define um conjunto de práticas e ferramentas que podem tornar uma organização fluente em um dos  possíveis níveis do modelo (nível 1 a 4).
O modelo de fluência ágil não é um modelo de maturidade, mas um mecanismo que permite que empresas possam escolher uma jornada de agilidade apta aos seus propósitos. Esse modelo usa outros métodos como Kanban, Scrum, XP ou DevOps dentro das suas jornadas específicas.
Um excelente artigo sobre o modelo é descrito aqui e foi escrito pelos seus criadores, James Shore and Diana Larsen. E você encontra muito material legal aqui no portal do Agile Fluency também.

Agile BOSSA Nova

O BOSSA é uma abordagem para agilidade organizacional, combinando as seguintes práticas de agilidade de negócio.

  • BB – Beyond Budgeting (orçamentos adaptáveis e flexíveis). Esse é um método de orçamentação moderno que habilita a tomada rápida de decisões em contextos complexos. Recomendo esse portal aqui com mais informações sobre o BB.
  • Open Space (abordagem para habilitar o poder da inovação de todos os funcionários),
  • Sociocracia 3.0 (estrutura organizacional flexível que permite a tomada de decisão descentralizada). Mais informações podem ser encontradas aqui no portal oficial.
  • Agilidade (aprendizado contínuo por meio de experimentos e feedback).
O portal Agile Bossa Nova traz uma rica coleção de recursos para quem quiser conhecer essa abordagem em mais detalhes.
Livro Chave:

Estruturas Libertadoras (LISA ou Liberating Structures)

As estruturas libertadoras são micro-estruturas narrativas que aprimoram a coordenação e a confiança entre as pessoas de uma empresa. Eles rapidamente estimulam a participação ativa de grupos de qualquer tamanho, tornando possível incluir e liberar o potencial de todos os participantes. Estruturas libertadoras são uma alternativas a abordagens de reuniões mais controladoras ou restritivas.
Em termos objetivos, elas são práticas para você conduzir encontros de trabalho no seu dia a dia. São técnicas de facilitação poderosas para apoiar grupos de trabalho a alcançar objetivos específicos em períodos curtos de tempo.
Um resumo dessas estruturas é mostrada na figura abaixo.
O portal do LISA contém uma explicação detalhada dessas estruturas. Existe também um APP móvel que considero muito útil e que disponível aqui na loja da Google Play.
Livro Chave:

Cynefin (leia Kinevin)

Esse modelo foi desenvolvido ainda em 1999 por Dave Snowden para ajudar líderes a compreender melhor o ambiente organizacional onde estão inseridos, e com base nisso, tomar decisões mais apropriadas.
Em termos práticos, o Cynefin é uma ferramenta de análise situacional e que permite qual o tipo de domínio onde as narrativas da sua empresa ocorrem. Os domínios possíveis estão listados abaixo (simples, complicado, complexo ou caótico). Dentro de cada domínio, o Cynefin sugere ferramentas apropriadas para aquele contexto.
O portal Cognitive Edge, mantido pelo Dave Swoden e associados, possui uma rica coleção de recursos e ferramentas ligadas ao ecossistema do Cynefin.

Modern Agile

O Modern Agile é uma comunidade para pessoas interessadas em descobrir melhores maneiras de obter resultados melhores para potencializar a agilidade de negócio. Ele aproveita a sabedoria de muitas indústrias, é orientado por princípios e não possui uma estrutura prescritiva.
Os princípios fundamentais dessa abordagem são resumidos na figura abaixo.
O site oficial do Modern Agile apresenta também as práticas emergentes dessa abordagem.

Heart of Agile

O Heart of Agile é um movimento liderado por Allistair Cockburn e que compila a experiência duas décadas de práticas ágeis dentro do modelo minimalista abaixo.
Esse movimento é um retorno à essência do manifesto ágil e pode ajudar você a descobrir a essência do Scrum, sem cair nas complicações e regras excessivas que foram adotadas pelos guias Scrum nos últimos anos.
O portal Heart of Agile conta também com uma coleção rica de recursos sobre esse movimento e apresentações do Cockburn.

Shiftup

O movimento Shiftup é uma nova marca de workshops, criada por Jurgen Appelo, que abraça a inovação contínua e a agilidade dos negócios como ponto de partida para a mudança organizacional.

O Shiftup é um programa para inovação contínua. Ele oferece um conjunto dinâmico de regras e modelos simples para as organizações se transformarem continuamente. Duas de suas regras fundamentais são colocadas abaixo.

  1. Cada idéia inovadora que evolui para um negócio de sucesso (seja um fluxo de valor individual ou um modelo de negócios inteiro) segue uma progressão natural dos estágios do ciclo de vida ou dos níveis de maturidade.

2.  A abordagem iterativa e incremental da inovação contínua (promovida pelos métodos Agile, Lean, Design Thinking e Lean Startup) se aplica a todos os fluxos de valor e modelos de negócios em todos os estágios do ciclo de vida.

O modelo conceitual é apresentado no esquema abaixo e esse e outros recursos de apoio se encontram no portal Shiftup.Work

Livro chave:

Lean Inception

O Lean Inception é um workshop colaborativo para alinhar um grupo de pessoas sobre o produto mínimo viável a ser construído. Ele é inspirado nos seguintes conceitos, modelos e processos:

  • Lean Startup e MVP
  • Iniciação do Processo Unificado da Rational
  • Design Thinking
  • User Centric Design

Similar à ideia do Design Sprint popularizada pela Google, o Lean Inception obteve uma boa tração no Brasil e tem sido usado por muitas empresas para realizar iniciações ágeis mais efetivas.

O portal do Paulo Caroli, pai do Lean Inception, contém muito mais informações ricas sobre esse workshop.

Livro Chave:

Vejo essa diversidade com bons olhos pois nenhum método é completo e perfeito.

“Não desenvolva apego a nenhum arma ou escola de combate”,
Samurai Miyamoto Musashi, Século 17

Eles são abstrações apenas e uma combinação efetiva deles pode ser interessante dentro da sua realidade. Espero que alguns desses modelos lhe possam ser úteis.

Existem muitos mais modelos de agilidade de negócio e ficaria feliz com feedbacks de outros modelos que não foram contemplados aqui.

Um feliz 2020 repleto de agilidade de negócio para você e até a próxima.
😀

Agile Brazil 2019 – O Bom, o Mau e o Feio

~ Marco Mendes ~ Deixe um comentário

Terminou mais uma edição do Agile Brazil, dessa vez nas alterosas. Muito bom que Minas Gerais tenha recebido pela primeira vez esse evento tão importante na comunidade Brasileira.

Vamos fazer uma resenha com impressões de pessoas que conversei e também com algumas opiniões pessoais minhas. Compilo aqui também alguns links para você se aprofundar em assuntos de algumas apresentações.

O Bom

The Heart of Agile

Começando do fim. A palestra do Alistair Cockburn, sobre o seu novo movimento chamado Heart of Agile. Baseado nas premissas de colaboração, entregas seguras para falhar, reflexão e melhoria contínua, Cockburn avança nas suas ideias lançadas no clássico livro Agile Software Development, de 2002.

Para saber mais:

Lean Inception

Paulo Caroli fez uma apresentação do seu já popular método de iniciação ágil baseado nas ideias da Startup Enxuta, fase de Iniciação do RUP e mecânicas do Design Sprint e Design Thinking.

Para saber mais recomendo o livro do próprio autor.

Práticas Antifrágeis de Engenharia de Software

Sim. A minha apresentação. 😅

Os retornos foram positivos e disponibilizei a mesma aqui no Slide Share para você.

O Caso Nubank

Alexandre Freire, diretor de tecnologia do Nubank, falou muito bem sobre agile na prática. OKRs, blameless postmortem, releases frequentes, business agility, Kudo Cards, Mob Programming, atendimento a deadlines, whole teams, Kudo Cards, DevOps de verdade, entre outras práticas. Wow!

Para saber mais:

Whole Team – Mob Programming (Programação em times)

Woody Zuill veio falar de flow, mob programming e os seus efeitos positivos para criar ambientes colaborativos, seguros.

    • Flow e Kanban

Scrum Patterns do Joseph Yoder

Padrões vem da experiência prática. Padrões são contextuais. E podem ser aplicados em muitos cenários. Joseph Yoder fez um tratamento um pouco mais formal desses padrões em sua apresentação no Agile Brazil 2019.

O portal abaixo mantém uma coletânea de padrões Scrum citados pelo autor que podem ser úteis na sua próxima iniciativa ágil

Práticas Emergentes
Alexandre Magno, um pioneiro da agilidade no Brasil, fez um bom bate papo sobre práticas emergentes e reforçou o papel do sense making para descobrir qual o tipo de prática mais apropriada para o seu contexto. Uma das ideias apresentadas foi o uso de frameworks de sense making como o Cynefin.

Uma boa introdução ao Cynefin pode ser encontrada aqui.https://www.infoq.com/br/news/2012/11/cynefin-gestao-de-mudancas/

The Whole Team

Todos os palestrantes que tiveram a coragem de estar lá e compartilhar seus aprendizados!!! 😀👏👏👏👏👏👏👏

Os seus trabalhos já estão sendo publicados no portal EventMobi e recomendo que você baixe as apresentações. Tem muita coisa legal lá e que não comentei aqui.

https://eventmobi.com/agilebrazil2019/

O Mau

  • Tempos pequenos para perguntas. Muita gente reclamando disto. Precisamos de mais learning 3.0 com as pessoas importantes da comunidade. (em público)
  • Local não promovia tanta interação devido ao sobe e desce das escadas e corredores pequenos para 1000 pessoas.

O Feio

  • Pessoal da organização do Agile Minas não foi chamado ao palco no fechamento e anúncio do Agile Brazil 2020.  Time de Minas trabalhou pesado no backoffice. Mas na hora do palco, ausentes. Por que? Que tal mais visibilidade para toda a comunidade Agile no Brazil?   😥

Filme inspiração do dia –  The Good, The Bad and The Ugly 😀

 

 

 

O filme “O Primeiro Homem” e os aprendizados para criação de uma cultura DevOps

~ Marco Mendes ~ Deixe um comentário

Assisti o filme “O Primeiro Homem” nesse final de semana. É um filme que relata a história da chegada do homem da lua na perspectiva da vida profissional e pessoal de Neil Armstrong.

Caso não tenha visto, coloquei aqui o trailer do filme.

Não sou crítico de cinema e não vou falar das qualidades e defeitos que vi no filme. Mas como agilista quero me debruçar no que a história da corrida espacial americana traz de ensinamentos para você que está buscado implementar DevOps na sua organização.

1. Objetivos Claros

No começo dos anos 60, a governo americano colocou um objetivo claro para a NASA e seus engenheiros, que era ter alguém pisando no solo da lua até o final desta década. Isso deu a todos um senso de propósito mensurável, por mais desafiante ou impossível que pudesse parecer.

No mundo DevOps, não deve ser diferente. A ausência de objetivos de negócio claros traz opacidade para as ações do time e muitas vezes torna uma iniciativa DevOps centrada em apenas rodar um pipeline com o Jenkins ou criar conteineres com o Docker, que são erros primários.

Aprendizado da NASA: Se a sua iniciativa DevOps não tiver um propósito de negócio, você pode estar trabalhando pesado mas a sua bússola pode estar errada. DevOps não é sobre tecnologia. DevOps é para você melhorar resultados de negócio. Simples assim.

Ferramenta para suportar objetivos em iniciativas DevOps:  O OKR (Objective and Key Results) é uma ferramenta leve, de natureza organizacional fractal e que se bem usada, pode apoiar no atingimento de objetivos para uma empresa, áreas, squads e até mesmo indivíduos em implantações DevOps.

Uma boa introdução a essa técnica pode ser encontrada aqui.

2. Cultura de Experimentos

Durante o filme, vemos o time conduzir vários experimentos. Eles estão trabalhando em ambientes complexos e tentando criar coisas que não existiam: foguetes maiores, módulos de alunisagem e outras tecnologias que não existiam.

Nas nossas TIs, não estamos colocando foguetes com humanos na lua, mas estamos criando coisas novas em ambientes complexos. E isso exige que você crie uma cultura de experimentos.

Aprendizado da Nasa: Cultive um sistema de trabalho para permitir que o seu time rode experimentos continuamente.

Ferramenta para suportar experimentos em iniciativas DevOps: Gosto do modelo mental do Lean Change, que traz instrumentos leves e simples para você propor e avaliar opções e criar experimentos simples em ciclo de vida leve com as etapas — preparação, introdução e revisão

Uma boa introdução ao modelo de Lean Change pode ser encontrado aqui nesse sítio.

Se você é gerente, lembre-se que experimentos não surgem se você não fornecer ao seu time as três coisas abaixo:

  • Tempo
  • Recursos
  • Autonomia

A gestão 3.0 pode te ensinar bastante sobre isso e a respeito recomendo o excelente livro Como Mudar o Mundo: Gestão de Mudanças 3.0, escrito por Jurgen Appelo.

A mensagem e intenção do livro é brutalmente simples e tomo a liberdade de reproduzi-la abaixo.

Como lidar com minha organização medíocre? Eu gosto do meu trabalho, mas eu não gosto do que a gestão está fazendo. Como lidar com isso?

Bem, é fácil. Você tem três opções:

1. Ignore. Mudar organizações é um trabalho duro. Se você não tem o vigor necessário para aprender como tornar-se um bom agente de mudança, então, pare de reclamar do que está ruim. Aceite que a organização é o que é, e aproveite as partes boas do seu trabalho. Nesse caso, você pode parar de ler, daqui.

2. Peça demissão. A única razão pela qual organizações ruins existem é porque as pessoas não pedem demissão. Faça um favor para o mundo e encontre um lugar melhor para trabalhar. Ajude organizações ruins a saírem de suas misérias não trabalhando para elas.

3. Aprenda sobre gestão de mudanças. Muitas pessoas são péssimas em influenciar outras pessoas a mudarem organizações. Mas, se você levar a sério, você pode aprender a ser um agente de mudança mais eficiente.

É pegar, largar, ou mudar.

Este livro é para aqueles que escolheram a opção 3.

3. Esteja preparado para falhar

Durante o filme, vemos várias falhas. Vemos também acidentes que terminam em mortes. E vemos também que as pessoas vivem em contextos sociais complexos, que podem gerar falhas no trabalho delas.

Em uma passagem do filme, Neil Armstrong, depois de destruir um módulo de alunisagem, diz algo aproximadamente assim: “Precisamos falhar aqui embaixo para não falharmos lá em cima”.

Se você é curioso o suficiente, deixo aqui uma lista de acidentes que ocorreram durante o programa espacial americano dos anos 60. A lista é enorme.

Aprendizadazem da NASA: Se você rejeita a falha, irá continuar a ser medíocre. Mas se abraçar a falha e usá-la como instrumento de feedback irá crescer e se tornar melhor. E isso vale para organizações complexas e para a sua empresa também. A Toyota e a Amazon, que abraçaram a cultura de expor falhas com segurança psicológica e promover melhoria contínua, se destacaram de outras organizações.

Ferramenta para suportar falhas em iniciativas DevOps: O Celebration Grid, ferramenta do Management 3.0, é um instrumento barato e simples para você coletar aprendizados.

Fonte: Site do Management30.com

Um artigo introdutório a esse instrumento pode ser encontrado aqui.

Um outro instrumento que gosto é o Safe to Fail Probes, derivado do modelo mental do Cynefin, de Dave Snowden. E aqui nessa página você encontra um roteiro detalhado de como aplicá-lo no seu dia a dia.

4. Sistematize a melhoria contínua

Quando você combina o segundo e o terceiro princípio acima, pode criar uma cultura Kaizen.

Aprendizados da Nasa: Teste práticas e faça provas de conceito e busque organizar o que esta funcionando e o que não está funcionando através de reuniões periódicas e análises post-mortem dos eventos.

Ferramenta para suportar falhas em iniciativas DevOps: O Loop OODA,, criado por um militar americano chamado Joyn Boyd, é um poderoso modelo mental de como você pode  lidar com problemas diversos que organizações vivenciam na entrega de produtos, redução de retrabalho e criação de aprendizado e melhorias.

Uma outra técnica derivada da retrospectiva e apresentada no excelente livro DevOps Handbook são as Análises Post-Mortem Sem Culpados. Descrevo ela brevemente abaixo.

Para fazer isso, nós agendamos o post-mortem o mais cedo possível após o acidente e antes de perdemos as memórias vívidas do ocorrido.

Você deve chamar. As pessoas envolvidas em decisões que podem ter contribuído para o problema. As pessoas que identificaram o problema. As pessoas que responderam ao problema. As pessoas que diagnosticaram o problema. As pessoas que foram afetadas pelo problema. E qualquer outra pessoa que esteja interessada em participar da reunião.

Nessa reunião post-mortem, faremos o seguinte:

  • Construir uma linha do tempo e reunir detalhes a partir de múltiplas perspectivas sobre falhas, garantindo que não iremos punir as pessoas por cometer erros;
  • Capacitar todos os engenheiros e analistas para melhorar a segurança, permitindo-lhes prestar contas detalhadas de suas contribuições para falhas;
  • Capacitar e incentivar as pessoas que cometem erros a serem especialistas que educam o resto da organização sobre como não repeti-los no futuro;

Finalmente, as contramedidas são registradas com uma data prevista e um proprietário para acompanhamento

“Um especialista é alguém que conhece alguns dos piores erros que podem ser cometidos em seu assunto e como evitá-los.”
– Werner Heisenberg

 

Trilhando a sua jornada DevOps

~ Marco Mendes ~ Deixe um comentário

Tivemos o privilégio de acompanhar nessa semana o primeiro DevOps Days Belo Horizonte. Lotação esgotada, excelentes palestras e muitas trocas de experiência. Definitivamente, o tema DevOps está nos corações e mentes de muitos profissionais de TI pelo Brasil afora.

E como boa coincidência, tivemos nesse mês a publicação do relatório State of DevOps Report 2018 do instituto de pesquisa e avaliação DevOps – o DORA. Ele trouxe nessa edição um modelo evolucionário para o aumento da sua maturidade DevOps. E esse modelo foi compilado através da análise do que milhares de empresas tem feito por todo o planeta. Faço um resumo do relatório abaixo para ajudá-lo a desenhar a sua jornada DevOps.

vladislav-babienko-703701-unsplash.jpg
A sua jornada para o mundo DevOps

Estágio 0 – Construir a Base

A análise dos dados da pesquisa do estado de DevOps de 2018 revelou as práticas fundamentais empregadas pelas equipes bem-sucedidas. Essas práticas se correlacionam tão fortemente com o sucesso do DevOps que o instituo DORA recomenda que elas são essenciais em todos os estágios do desenvolvimento do DevOps. Em outras palavras, as práticas que devem ser adotadas em qualquer estágio para progredir para o próximo estágio permanecem importantes até mesmo para aquelas organizações que evoluíram mais longe em sua jornada DevOps e que já mostraram o maior sucesso.

As práticas fundamentais estão listadas abaixo:

  • O monitoramento e alertas são configuráveis ​​pelas equipes que operam o serviços em produção. 
  • Os padrões de implantação para a criação de aplicativos ou serviços são reutilizados.
  • Os padrões de teste para a criação de aplicativos ou serviços são reutilizados.
  • As equipes contribuem com melhorias nas ferramentas fornecidas por outras equipes.
  • As configurações são gerenciadas por uma ferramenta de gerenciamento de configuração.

Estágio 1: Normalize a pilha de tecnologia

A maioria das organizações que usam grandes quantidades de tecnologia está lidando com muita complexidade, diminuindo seus esforços para avançar nos negócios. Portanto, não é surpreendente que os primeiros esforços em uma transformação DevOps
(ou qualquer tipo de transformação de negócios) se concentraria na redução da complexidade.

As duas práticas que definem o estágio 1 funcionam para reduzir a complexidade:
• As equipes de desenvolvimento de aplicativos usam controle de versão.
• Equipes fazem a implantação de aplicações em um conjunto padrão de sistemas operacionais.

Estágio 2: Padronize e reduza a variabilidade

No estágio 1, vemos organizações normalizando suas tecnologias
e processos. Quando chegam ao estágio 2, as organizações já começaram o processo de padronização de um conjunto de tecnologias; configurações de aplicativos separados dos dados, uso consistente de controle de versão e também um processo consistente para testes de infraestrutura e um padrão de compartilhamento de código-fonte.

No estágio 2, as organizações estão trabalhando para padronizar e reduzir a variabilidade, um tema que prevalece em todos os estágios da evolução do DevOps.

Toda organização tem variação, que pode derivar de várias causas diferentes, incluindo:
• Adoção de novas tecnologias para substituir muitas funções de tecnologias antigas. E ao mesmo tempo, as tecnologias mais antigas nunca são removidas.
• Produtos caseiros que não seguem padrões comuns do setor e não possuem interfaces comuns.
• Uma proliferação de ferramentas que se sobrepõem e não foram racionalizadas.
• Fusões e aquisições, que trazem ainda mais tecnologias legadas para casa.

No estágio 2, a reutilização de tecnologias e padrões se torna importante. Isso leva os times de Dev e  Ops a colaborar e tomar decisões de arquitetura que afetam a capacidade de implementação e testabilidade dos aplicativos. Por causa do direcionamento para esses padrões comuns, as equipes começam a inventar maneiras de aumentar a velocidade na adoção de padrões e reduzir ainda mais a variação. Isso impulsiona a inovação no nível de equipe para otimizar processos e fluxos de trabalho em torno das pilhas de tecnologia abençoadas.

Um antipadrão primário a ser observado neste estágio é que cada equipe se normalize em seus próprios padrões. Isso levará a um maior grau de variação global e é exatamente a direção errada.

Em essência, as práticas de definição para o estágio 2 são:
• Construa em um conjunto padrão de tecnologias.
• Implante em um sistema operacional padrão único. (ou em um conjunto mínimo, se um apenas não for possível)

Os principais benefícios da organização dos padrões e tecnologias de uma equipe de TI são:
• Velocidade de entrega mais rápida.
• Mais flexibilidade para a equipe de desenvolvimento trabalhar em novos aplicativos, serviços ou componentes.
• Área de superfície reduzida para vulnerabilidades de segurança.
• Menos partes móveis para manter, atualizar e aprender. E isso reduz a complexidade essencial e acidental.

Etapa 3: Expandir as práticas do DevOps por toda a TI e além

Os estágios 1 e 2 reduzem a complexidade geral da pilha de tecnologia para que as equipes possam obter resultados mais repetitivos com variação limitada. O estágio 3 é sobre a expansão das práticas de DevOps para o grupo mais amplo de equipes de TI e prestação de serviços.

No estágio 3, as práticas de DevOps se espalham para além das equipes de desenvolvimento e operações, onde primeiro criaram suas raízes. À medida que a colaboração aumenta e a organização se concentra em melhorias em torno do gerenciamento de serviços, implantação, redução de tempos de espera e minimização de aprovações, esses esforços afetam as áreas além dos departamentos de tecnologia. O compartilhamento de ferramentas, aplicativos e serviços aprimorados – assim como o conhecimento – com outras áreas funcionais da empresa agora se torna fundamental para expandir o sucesso anterior do DevOps e dimensionar o DevOps em toda a organização.

As pesquisa do instituto DORA mostraram que o estágio 3 é onde as iniciativas de DevOps mudam de pequenos grupos de sucesso em algumas equipes para uma onda que se espalha e eventualmente transforma toda a organização.

Foi também observado em achados do grupo que o Estágio 2 (reduzindo a variação
na pilha de tecnologia) e a Etapa 3 pode ocorrer em ordem direta, em ordem inversa ou ao mesmo tempo. Mas ambos precisam acontecer antes de progredir para o estágio 4 (automatizar a entrega da infraestrutura).

Ou seja, faz mais sentido concentrar-se na redução da variabilidade nos estágios iniciais, de modo que haja menos ocorrências para gerenciar, economizando tempo e distração de sua equipe. Mas se isso não for possível porque algumas dessas coisas estão fora do seu controle, trabalhe primeiro nas coisas que você pode controlar. O mais importante é que a equipe de gerenciamento de serviços de TI e quaisquer outras equipes que dependem de serviços trabalhem juntas durante esse estágio.

As práticas definidoras no estágio 3 são:
• Os indivíduos tem autonomia para poder trabalhar sem aprovação manual de fora da equipe (ex. gerentes e áreas de negócio). E isso foi alcançado através da confiabilidade obtida na busca das práticas do estágio 2.
• Padrões de implantação para criar aplicativos e serviços são reutilizados.

Outras práticas importantes para estágio são:

• Os indivíduos conseguem fazer alterações com tempos de espera reduzidos (lead times).
• Mudanças de serviço podem ser feitas durante o horário comercial.
• Revisões pós-incidente ocorrem e os resultados são compartilhados.
• Equipes constroem código em um conjunto padrão de tecnologias.
• Equipes usam integração contínua.
• As equipes de infraestrutura usam também controle de versão.

Etapa 4: Automatizar a entrega da infraestrutura

O estágio 4 é onde as equipes de infraestrutura estão no centro da atenção. As práticas definidoras neste estágio são sobre automatizar a entrega de infraestrutura – o que muitos pensam como o início de uma iniciativa de DevOps.

Essas práticas de automação de infra-estrutura aparecem mais tarde na jornada evolucionária do que podemos esperar. Isso porque são ativadas por coisas que caracterizam estágios anteriores: normalização, redução de variáveis ​​e expansão da evolução do DevOps para além das equipes de tecnologia nos negócios. Sucesso em estabelecer esses fatores em estágios iniciais torna muito mais fácil alcançar o sucesso no Estágio 4.

E  isso não quer dizer que a automação de infraestrutura não está acontecendo em estágios anteriores. Já no Estágio 0: Construir a base, a prática de gerenciar configurações de infraestrutura com uma ferramenta de gerenciamento de configuração rapidamente se instala desde o início, quando as equipes de operações estão buscando padronizar para resolver suas próprias necessidades.

A principal diferença no estágio 4 é que o objetivo de conduzir a automação de infraestrutura nesse estágio é proporcionar maior agilidade a todo o negócio, não apenas para uma única equipe.

Embora esse estágio seja gratificante – parece que você está realmente fazendo o DevOps agora – é importante reconhecer que os estágios anteriores possibilitam a automação da infraestrutura. O instituto DORA viu organizações tentando saltar imediatamente para este
estágio sem passar pelos estágios anteriores. E o resultado é a frustração. É preciso que essas organizações demorem mais do que o esperado para fazer qualquer progresso real com a automação da infraestrutura.

As equipes de infra-estrutura nesse estágio da jornada de DevOps começam a adotar práticas de desenvolvimento ágil, como o uso de controle de versão para configuração do sistema e configurações de aplicativos, e adotam ferramentas usadas pelas equipes de desenvolvimento de aplicativos. As equipes, nesse estágio, também automatizam as configurações de políticas de segurança dentro de sua esfera de influência.

As práticas centrais para o estágio 4 são:
• As configurações do sistema são automatizadas.
• O provisionamento é automatizado. 

E algumas práticas associadas são:
• Configurações de aplicativo estão no controle de versão.
• As equipes de infraestrutura usam o controle de versão.

Estágio 5: Fornecer recursos de autoatendimento

Para passar para o Estágio 5, uma organização deve ter os seus vários departamentos comprometidos em fornecer recursos de TI como um serviço para a empresa, em vez de tratar a TI como um centro de custo que executa ordens de serviço. Esses departamentos incluem desenvolvimento, qualidade, operações, segurança, ITSM e outras áreas funcionais.

Neste último estágio da evolução do DevOps, os benefícios para a organização multiplicarem-se enormemente à medida que a colaboração bem-sucedida entre os limites funcionais se acelera.

Esses ganhos são vistos em várias áreas distintas:
• A arquitetura de aplicativos vai além da padronização de tecnologias e começa a evoluir no sentido de trabalhar e suportar a migração na nuvem, a adoção de contêineres e a proliferação de microsserviços.
• A automação da política de segurança passa de atender as necessidades de uma equipe para se tornar a linha de base de como a segurança e a conformidade são medidas em todo o departamento, ou mesmo em toda a organização. Além disso, o provisionamento automatizado avança para o provisionamento de ambientes completos para desenvolvedores, testadores e outras equipes técnicas.

Uma vez que você comece a ter sucesso em múltiplos limites funcionais, os pilares do DevOps – (CAMS) Cultura, Automação, Mensuração e Compartilhamento – tornam-se mais difundidos em toda a organização.

As duas práticas de definição para o estágio 5 são:
• Respostas a incidentes são automatizadas.
• Recursos de TI (ex. máquinas ou conteineres) estão disponíveis via autoatendimento.

As duas práticas associadas neste estágio são:
• Aplicativos de arquitetura com base nas necessidades de negócios.
• As equipes de segurança estão envolvidas no design e na implantação de tecnologia.

Resumo do relatório

Em resumo, os dados coletados pelo instituto DORA mostraram que embora existam muitos caminhos individuais por meio de uma transformação DevOps, há maneiras de atingir e dimensionar o sucesso mais rapidamente. As organizações têm uma escolha: elas podem escolher ser sistemáticas sobre como elas evoluem ou podem adotar uma abordagem mais dispersa. É claro que é possível que até mesmo uma abordagem ad-hoc funcione, mas o que foi observado nas organizações que atingiram os níveis mais altos da evolução do DevOps é que elas não chegaram lá por acaso.

O Todo Poderoso Gráfico do Fluxo Cumulativo de Valor

~ Marco Mendes ~ 1 comentário

Figuras brilhantes da administração moderna, como Peter Drucker, já diziam que é inútil tentar gerenciar um sistema de trabalho sem um sistema consistente de medições e métricas. Se você já trabalha com métodos ágeis isso é ainda mais importante pois métodos ágeis são baseados nos princípios de transparência radical, feedbacks e replanejamentos contínuos. Sem números apropriados, não conseguimos avançar na maturidade do uso de métodos ágeis.

Felizmente, existe um gráfico simples e superpoderoso que pode ser facilmente usado por times ágeis. Esse gráfico lhe dará muitas informações valiosas, tais como:

  1. A representação das entregas realizadas no fluxo de valor do seu sistema de trabalho.
  2. O tempo médio que o seu sistema de trabalho demora para processar um novo pedido ou requisito. (lead time ou tempo de atravessamento).
  3. O tempo médio que cada papel ou área do seu sistema de trabalho demanda para processar novos itens. (cycle time ou tempo de ciclo).
  4. A quantidade de itens que estão sendo processados em um determinado momento do tempo (WIP ou trabalho em progresso).
  5. Observar mudanças de escopo ao longo do tempo
  6. Observar a vazão do seu sistema de trabalho, de um papel ou de uma área. (throughput)
  7. Observar gargalos
  8. Estimar quando o seu projeto irá terminar

Ferramentas normalmente usadas por times ágeis, como por exemplo o Microsoft VSTS/TFS, JIRA Agile, Redmine ou o Trello com plugins, já constroem automaticamente esse gráfico e liberam o nosso tempo para a análise intelectual das informações. Ao mesmo tempo, você pode criá-los em ferramentas de planilhas simples como o Google Sheets ou o Excel. Irei fazer isso ao longo desse post para que você possa entender como construir e interpretar esse gráfico.

Construindo o Gráfico do Fluxo Cumulativo de Valor

O nome do nosso super-gráfico é fluxo cumulativo de valor e é também chamado de CFD ou Burn-Up.

Os passos essenciais para a construção desse gráfico são:

  1. Decidir que tipo de informação será medida.
  2. Decidir a frequência da análise.
  3. Decidir que etapas do fluxo de valor serão medidas.

Vamos trabalhar com um primeiro exemplo onde queremos analisar os incidentes que são atendidos por uma área de suporte de um produto. A nossa análise nesse exemplo será semanal e iremos analisar as seguintes etapas:  novos incidentes, incidentes em tratamento e incidentes fechados.

Primeiro monte uma tabela com as informações dos incidentes em cada estado ao longo de cada semana.

Captura de Tela 2018-09-09 às 11.02.39.png

Depois você deve somar os dados em cada semana, i.e, em cada semana iremos ver todos os incidentes naquele estado. Na semana 2, portanto, teremos 17 incidentes no estado aberto, 10 em execução e 7 fechados. Isso irá gerar uma planilha simples conforme mostrado abaixo.

Captura de Tela 2018-09-09 às 11.02.46

Agora iremos representar isso visualmente em um gráfico de área 2D (Area Chart Non Stackable no Google Sheets ou Área 2D no Excel). O resultado abaixo será mostrado.

chart

 

Extraindo Informações do Gráfico Cumulativo de Valor

Vamos agora interpretar as informações trazidas por esse gráfico.

A representação das entregas realizadas no fluxo de valor do seu sistema de trabalho.

O primeiro fato a ser extraído do gráfico é como o seu sistema de trabalho está se comportando conforme o seu fluxo de valor, que é a coleção de etapas ou estados através dos quais podemos observar o sistema de trabalho.

Podemos observar que nas 4 primeiras semanas tivemos 52 incidentes abertos, 33 itens em execução e 19 fechados. Já na semana 6 observamos 78 itens abertos, 51 em execução e 40 itens fechados. E isso indica que o sistema na semana 6 está menos saudável que na semana 4 pois existe um acúmulo maior de itens nos estados aberto ou em execução. Colocado de outra forma, podemos ver que na semana 4 existe um acúmulo de 33 itens (52 itens abertos – 19 itens fechados). Já na semana 6 temos 38 itens acumulados (78 itens abertos – 40 itens fechados).

Se observamos a figura, podemos observar como a barriga da área azul. Visualmente podemos ver que a barriga na semana 6 se tornou maior que a barriga da semana 4. E isso indica que a saúde do sistema piorou.

Sistemas de trabalho saudáveis devem manter conseguir processar itens em taxas similares às suas chegadas. Isso evita filas, troca de contexto e defeitos no processamento de pedidos, requisitos, demandas ou encomendas.

O tempo médio de processamento de pedidos (lead time ou tempo de atravessamento)

Um dos motivos que leva a que métodos ágeis tenham esse nome é que eles buscam garantir que um pedido aberto não fique muito tempo dentro do seu sistema de trabalho, i.e., um novo pedido ou requisito deveria ser rapidamente construído, verificado e liberado para os seus clientes. Chamamos essa métrica global de tempo de atravessamento ou lead time.

Vamos examinar como o lead time pode ser examinado pelo gráfico do fluxo cumulativo de valor. Ele pode ser lido através da diferença horizontal entre os itens fechados e os itens abertos.

Captura de Tela 2018-09-09 às 11.38.25.png

Por exemplo, na semana 5 estamos vendo que os itens fechados correspondem aos itens que foram abertos na semana 2. O lead time da semana 5 está perto de 4 semanas, que indica que um incidente fica perto de um mês no seu sistema antes de ser finalizado.

Se observarmos a semana 10, vemos um o sistema ficou ainda menos saudável.  Os itens fechados na semana 10 foram abertos entre a semana 5 e a semana 6, que indica que o lead time médio agora está em cerca de 4 semanas e meia.

Nos métodos ágeis, buscamos minimizar o lead time. Quanto menor o lead time, mais rápida é a capacidade do seu time de processar pedidos. E portanto a medição do lead time é em minha opinião a mais importante métrica a ser observada em sistemas baseados em métodos Scrum, Kanban e afins.

O tempo médio de processamento de pedidos por papel ou área (cycle time)

Se o lead time mostra o tempo total de atravessamento no nosso sistema de trabalho, podemos usar o mesmo racional para examinar como uma etapa do trabalho (papel ou área) está se comportando. Considere o gráfico abaixo como exemplo.

Captura de Tela 2018-09-09 às 11.54.21.png

Aqui estamos observar o tempo de ciclo da etapa de execução, i.e, o tempo médio que um incidente demorou para ser efetivamente resolvido uma vez que ele começou a ser tratado pela equipe. Podemos ver que o tempo de ciclo na semana 5 era de um pouco mais de 1 semana. Já na semana 10 o tempo de ciclo já era de 3 semanas, indicando que o time de execução claramente não está conseguindo liberar incidentes na mesma taxa que eles estão chegando.

Veja ainda que o tempo de ciclo pode ser analisado em outras etapas. Por exemplo, no gráfico abaixo podemos observar o tempo de ciclo da etapa de Novos Incidentes.

Captura de Tela 2018-09-09 às 12.02.14.png

Aqui podemos ver que na semana 3 um incidente demorava, em média, uma semana e meia até começar a ser tratado pelo time. Já na semana 10 um item ficava aberto quase 4 semanas até começar a ser tratado pelo time.

Longos tempos de ciclo para uma etapa indicam que a área associada aquele trabalho está com dificuldades. E isso indica que a gestão deve buscar formas de apoiar aquele time para reduzir nos gargalos. Ao invés de permitir a chegada de novos itens de foram desenfreada (ilusão de controle) ou fazer ameaças (management 1.0) a gestão ágil deve promover enxames de ajudantes de outras áreas e funções para desafogar o time com dificuldades e com isso reestabilizar o sistema.

A quantidade de itens que estão sendo processados em um determinado momento do tempo (WIP ou trabalho em progresso).

Esse gráfico é tão legal que podemos observar também como os itens estão se acumulando no sistema de trabalho. A isso chamamos de trabalho em progresso ou WIP (Work In Progress). Valores altos do WIP indicam que o seu sistema não está saudável pois indica que as pessoas estão tentando fazendo muita coisa ao longo de uma semana. Isso leva a interrupções no trabalho, trocas de contexto e esgotamento mental pelo seu time.

No gráfico abaixo, podemos observar que o WIP da semana 10 é claramente pior que o WIP da semana 02, mostrando como o sistema está se degradando ao longo do tempo.

Captura de Tela 2018-09-09 às 12.09.16.png

De fato, se você observar os dados da planilha fornecida no exemplo você irá observar que o WIP da semana 02 era de 19 itens (26 – 7). Já o WIP na semana era de 37 itens (119 – 72).

Observar mudanças de escopo ao longo do tempo

Vamos considerar o contexto de um time que precise construir um produto e fez um levantamento inicial dos requisitos do produto. Esse time trabalha em um fluxo de valor com os estados: Backlog, Em Análise, Em desenvolvimento, Em testes, Em homologação e Fechado.

O gráfico mostrado abaixo mostra que houve um intenso esforço na descoberta de requisitos nas semanas 2 e 3. E o gráfico também mostra que houve mudanças de escopo ao longo da semana 8 (12 novos itens surgiram). E se o projeto foi baseado em premissa de escopo fechado, isso indica um sinal gerencial amarelo que sinaliza que novos sprints talvez sejam necessários para completar o escopo recem-descoberto.

Captura de Tela 2018-09-09 às 13.34.42.pngObservar a vazão do seu sistema de trabalho, de um papel ou de uma área. (throughput)

Podemos observar ainda um aspecto bem importante na saúde de um sistema que é a sua vazão, ou taxa de produção de itens no tempo. Por exemplo, considere o seguinte gráfico.

Captura de Tela 2018-09-09 às 13.41.45.png

Explicitei nesse gráfico a vazão dos responsáveis pelo desenvolvimento nas semanas 4, 5, 6 e 7. Observe que quanto maior a inclinação da seta, maior é a vazão. E então podemos observar que o time de desenvolvimento teve um problema mais sério entre a semana 5 e 6. A inclinação da seta aqui está muito baixa nesse região do gráfico. Talvez algum dos desenvolvedores tenha sido alocado em outro projeto ou algum aspecto técnico da arquitetura ainda não explorado do produto tenha surgido e atrasado o trabalho de todos eles.

A análise da vazão ao longo de cada etapa é um instrumento importante para o Scrum Master, Agile Coach e time analisar a saúde e estabilidade do sistema de trabalho.

Observar gargalos

Um outro superpoder desse gráfico é permitir que você analise gargalos. E para isso vamos habilitar as linhas de tendência das etapas inicial e final desse sistema de trabalho (novos requisitos no backlog e requisitos fechados). As linhas de tendência são criadas pela opção Trend Lines no Google Sheets e Excel e são observadas pelas linhas vermelha e preta nesse exemplo.

Captura de Tela 2018-09-09 às 13.56.38.pngSe a inclinação das linhas é igual isso indicaria que o sistema está saudável. No caso aqui, estamos vendo que a inclinação da linha vermelha é maior que a inclinação da linha preta. E isso indica que mais itens estão chegando do que itens saem do sistema de trabalho.

Podemos fazer essa análise comparando quaisquer duas etapas (ex. desenvolvimento versus testes ou análise versus testes), para todo o intervalo de tempo ou para um período de análise. As inclinações das retas nos permitem analisar se gargalos estão sendo formados.

E se você observar um gargalo, é o momento de ligar um sinal amarelo e analisar como podemos pensar coletivamente e apoiar área que está apresentando dificuldades.

Estimar quando o seu projeto irá terminar

Por último, mas não menos importante, esse gráfico lhe dá também uma oportunidade de estimar quando o projeto provavelmente irá terminar.  Vamos considerar o gráfico mostrado abaixo, onde explicito a quantidade de itens fechados ao longo do tempo e também a quantidade de itens que devem ser realizados ao longo do projeto.

Captura de Tela 2018-09-09 às 14.07.07.png

Uma heurística simples que podemos usar aqui é a regra de três sobre os itens fechados até o momento. No nosso exemplo temos 28 itens que foram fechados em 10 semanas. E como temos 117 itens a serem realizados, o tempo total para finalizarmos todos os itens no escopo seria calculado como: 117/28 *10 = 41 semanas.

Essa abordagem, pois mais simplista que pareça, trabalha com o princípio básico que a velocidade passada é um excelente preditor da velocidade futura em um sistema. E isso se torna cada vez mais verdade quando você tem um bom número de observações ao longo do tempo.

Erros Comuns no uso do Fluxo Cumulativo de Valor

Embora esse gráfico seja extremamente poderoso, devemos ter atenção a alguns pontos para não usarmos a ferramenta de forma errada. Alguns erros incluem:

  1. Começar com um fluxo de valor complexo. Recomendo começar com um fluxo simples (A Fazer, Em execução, Finalizado) e incluir mais estados a medida que você e o seu time se acostumarem com o instrumento.
  2. Possui uma definição fraca de Finalizado. Finalizado é algo que está pronto para os seus usuários finais. Se você trabalha com entrega de livros, Finalizado significa que o seu livro está na casa do seu cliente. Se você trabalha com uma cozinha, Finalizado significa que o seu cliente está almoçando o prato que ele pediu há 30 minutos atrás. E se você trabalha com desenvolvimento de software, Finalizado implica que o aquela funcionalidade está nas mãos dos seus usuários no ambiente de produção.
  3. Não possuir Critérios de Aceite para mover um item ao longo do fluxo de valor.  É fundamental que o time defina critérios objetivos que permitam avaliar se um item pode transitar de um estado para outro no fluxo de valor. Isso evita falsos positivos e a maquiagem de dados.
  4. Não comunicar o gráfico. Esse gráfico deve ser afixado em base periódica nas paredes do local de trabalho do seu time ou exibido na TV da sua sala. Esconder esse gráfico em alguma planilha obscura na rede não irá ajudar ao seu time, nem você.
  5. Ter uma frequência baixa de atualização. O poder do gráfico cumulativo de valor vem das interpretações que conseguimos obter das medidas ao longo do tempo. (WIP, Lead Time, Taxas e Gargalos). E isso depende de um ciclo de amostragem regular. Recomendo um ciclo mínimo de uma semana. mas se você coletar os números em base ainda menor você terá insumos ainda melhores.
  6. Adotar esse gráfico apenas para  um único tipo de informação. Todo sistema complexo deve ser examinado em diferentes níveis. E cada nível  lhe dar perspectivas diferentes de análise. Por exemplo, na construção de produtos podemos analisar Épicos, Features ou Histórias. E podemos ter gráficos CFD para cada um desse itens, que permite que você observe a saúde do sistema em níveis distintos e possa extrair interpretações mais robustas.

“Don’t look with your eyes, look with your feet. Don’t think with you head, think with your hands.“ – Taiichi Ohno

A planilha mostrada nesse exemplo está compartilhada aqui para seus estudos sobre o CFD.