0

Kirkpatrick – O que seria de nós se não soubéssemos das curvas?

Há diferentes teorias e curvas que reiteradamente discuto e que nos ajudam a entender o processo cognitivo e desafio relacionado ao aprendizado, mudança e melhoria, como a Curva de Tuckman para formação de um time, hoje vou compartilhar a Curva de Kirkpatrick.

Em 1994, Donald Kirkpatrick publicou um bestseller intitulado Avaliando Programas de Treinamento, apresentando quatro estágios relacionados aos possíveis desdobramentos de um treinamento, gerando o que chamou de reação, aprendizado, comportamento e resultados.

O entendimento de Tuckman, Ebbinghaus, Kirkpatrick e outras, nos ajudam a entender antecipadamente os porquês e de posse destas informações trabalharmos desde cedo com argumentos e ações para gerar maior efetividade na formação e evolução de nossos times.

Vejo isso a cada treinamento, a curva sobre a conversão de ensino em aprendizado e sua conversão em prática, os estudos de Kirkpatrick lançam luz e nos ajudam a melhorar enquanto palestrante, instrutor, professor, facilitador e/ou coach.

Vai além da Curva de Ebbinghaus sobre nossa capacidade e limitação de retenção e assimilação, também Edgar Schein, lembrando que a mudança gera desconforto quando percebemos que deixaremos o conhecido para tentar algo novo, que ainda não dominamos.

Eu tenho uma matriz temporal de condução para qualquer treinamento, conhecida por quem me acompanha, com um pré (organizar e instigar metas), há a execução (interagir e projetar) e um pós (experimentar, persistir e melhorar), onde acrescentei a curva de Kirkpatrick:

Em seu estudo Kirkpatrick estabeleceu ranges para cada etapa, mas como agilista eu acredito que cada pessoa, imerso em times e cultura organizacional, estabelecerá um ritmo para seu grupo, conforme liderança, metodologia, maturidade, domínio, etc.

Conhecer as diferentes curvas nos ajudam a agir para torná-las mais fluidas, gerando maior retenção e conversão em resultados práticos. Mantendo a reação em seus insights, o interesse no aprendizado, a pró-atividade do comportamento e persistência até os resultados:

1- Reação é quando o aluno ou participante percebe que aquele conteúdo tem a ver com ele e que pode ser útil de alguma forma, colaborando para possíveis melhorias no seu trabalho ou a ele enquanto pessoa. Refere-se a interesse e a maioria se motiva!

2- Aprendizado é quando o aluno ou participante se mostra interessado realmente, interagindo com o instrutor e demais participantes enquanto traça cenários imaginários de uso e projeção de resultados. Diz respeito a entendimento e planejamento!

3- Comportamento é quando o aluno ou participante estabelece uma experimentação e aprendizados, permitindo-se mudar para tanto. Diz respeito a vivência e validação, exigindo engajamento e persistência!

4- Resultados é quando estabelece-se aquilo que chamamos de melhoria contínua, os resultados já são percebidos e os mesmos são valorizados. Refere-se a evolução proposta pelas artes marciais como Ju-Ha-Ri, adaptando e tirando o máximo de benefícios.

Em treinamentos é preciso instigar pessoas a serem agentes de mudança, não desistirem e serem exemplo. A psicologia afirma que todo grupo humano possui lideranças ou formadores de opinião, o tempo e o sucesso de um processo de mudança depende muito do exemplo deles.

 

0

Desculpa, mas agile não é trincheira … pronto, falei!

A maior quebra de paradigma do nosso tempo não é usar design thinking, lean startup ou métodos ágeis, nem Angular, NodesJS ou microserviços, o desafio é termos profissionais mais conscientes, colaborativos, transparentes e realistas.

Mudar de método de trabalho e adotar novas práticas é sim um desafio, porém se não mudarmos o modelo mental e hábitos ancestrais, será tão somente um novo processo de trabalho para servir de zona de conforto, cada um no seu quadrado.

A pergunta não é se somos ágeis, mas se trabalhamos para nos tornarmos equipes de alta performance, porque agilidade é meio, trabalho em equipe, valoroso, colaborativo, sustentável, positivo, os resultados são o fim.

Nossa crença é que esse meio, com ambientes e equipes ágeis, suscitaremos melhores resultados a todos. Sem resultados e valor, sua agilidade não se sustentará muito tempo.

Trincheiras

Mesmo entre aqueles que se dizem ágeis, muitos misturam “reclamação” com transparência, apontar culpados com “eu fiz a minha parte”, “alertam” problemas esquecendo que nosso papel é mitigar, contornar, resolver … ver um problema é só o primeiro passo.

Eu acredito muito na frase “Esperamos que as retrospectivas façam o seu trabalho!” mas, se o resultado recorrente de uma retrospectiva é listar problemas dos outros, não é retrospectiva, é trincheira.

Muitos agilistas reclamam de problemas que eles próprios viram começar, crescer e se estabelecer, apenas assumindo o papel de arautos da verdade dos outros, apontando o dedo e deixando o seu projeto ir pro beleléu, mesmo com opções de contorno.

Construção

Há uma estrada longa para colher o que não plantamos ainda, caso ainda não usemos Lean Business Analisys, DDD, BDD, clean code, XP, DevOps, haverá muito o que fazer e consolidar para aos poucos estabilizarmos nossa realidade.

Muitas vezes eu escuto de equipes que o seu cotidiano é estressante, mas ao averiguar, não é nada além do cotidiano de uma área que lida com a complexidade inerente a software e ao imediatismo no caso de problemas em produção (legados).

Se vamos trabalhar 8 horas por dia em projetos que mexem com os destinos de empresas, áreas, produtos, serviços, mas ainda não temos um bom pack de boas práticas, querer que não hajam momentos de tensão é impossível, temos que saber lidar com eles enquanto evoluímos.

Poupança

Muitas vezes eu comparo uma empresa ou equipe que começa a adotar Agile como alguém que abre uma poupança, teremos que fazer vários depósitos pequenos para hora dessas termos um montante legal … não é imediato.

Projetos e tecnologia é igual, temos um débito técnico gigantesco, legados, falta de boas práticas variadas a cada passo, mesmo assim muitos acham que o simples fato de decretarem que se tornaram ágil esse histórico desaparecerá …

Desculpa aí, mas é o mesmo que um eu de repente decidir usar calça número 39, para isso acontecer vou ter que me empenhar a baixar do 42 para o 39, melhorar hábitos alimentares, academia, retomar os percursos diários de bike.

Adotar Agile para o modelo de fluência do James Shore pode exigir de 4 a 5 anos de dedicação, porque envolve cultura, envolve gente, hábitos, costumes, é preciso crença e dedicação, flexibilidade, jogo de cintura, é preciso ser ágil na agilidade.

Agile é valor entregue

Se há algo errado, propomos alternativas, qual a melhor delas e argumentos, mesmo assim, quem decide as vezes pensa diferente, reclamar e emburrar não é solução, só piora, é preciso tentar fazer dar certo … o que estiver ao nosso alcance!

Toolbox, foco na entrega de valor, o objetivo é sempre buscar uma técnica que melhor enderece, o que pode ser feito para resolver ou mitigar? Se necessário, excepcionalmente, stop the line e replanejar.

Trabalhar em equipe ágil não quer dizer unanimidade de opinião, mas debate e tomada de decisão coletiva e colaborativa … depois é trabalhar nos termos que ficaram definidos, mantendo um ambiente positivo e profícuo.

Quer saber? Gostaria de ser uma mosca e poder assistir incógnito alguns agilistas de boutique se “adaptando” as idiossincrasias de suas empresas, contratos e clientes … porque agilidade na vida real exige muita resiliência até que teoria e prática se encontrem. Agilidade, sustentabilidade e sinergia não são disciplinas que acontecem por decreto … é algo que construímos aos poucos, um passo de cada vez, as vezes para a frente, as vezes para os lados ou mesmo para trás. Ficar idealizando, de mi-mi-mi, só empata mais ainda. Pode demorar anos, enquanto isso, temos que ir lá e fazer, ganhando créditos, avançando, baby steps, menos mi-mi-mi e mais pés no chão por favor!

mosca

Post difícil, tabu, dá vontade de escrever mais 2 laudas, mas até aqui já expressa por alto meu sentimento.

2

Microgerenciamento leva à Paralisia de Análise

De onde saem meus posts? De minha inclinação a filosofia, sexta estava conversando com a Ana Hermann e ela citou o conceito de analysis paralysis em jogos. Acabei dedicando a noite de sexta à leitura, reflexões e derivações que me fizeram refletir sobre microgerenciamento.

“gestão com controle ou atenção excessivos nos detalhes” – Merriam Webster’s

“gestão ou controle com excessiva atenção aos menores detalhes” – Reference.com

“atenção a pequenos detalhes na gestão: controle de uma pessoa ou situação prestando extrema atenção a pequenos detalhes” – Encarta

“A noção de micro-gerência pode ser estendida a qualquer contexto social em que uma pessoa adota uma abordagem agressiva ao nível de controle e influência sobre os membros de grupo. Frequentemente, esta obsessão com os menores detalhes causa uma falha de gestão direta na habilidade de focar nas questões maiores” – Harry Chambers em My Way or the Highway (2004)

Inexiste agilidade lastreada em microgerenciamento, impossível falar de auto-organização e equipes de alta performance sem pressupor liderança ágil e delegação. Microgerenciamento destaca o líder, porque suas equipes acabam sendo dependentes, com medo de errar.

Você já ouviu falar no “Dilema da Centopéia” como alegoria ao equivoco de tentar controlar algo que deveria ser fluido, dinâmico e descentralizado? O cérebro consciente deve decidir sobre a direção, mudanças, não sobre a posição de cada dedo do pé conforme o terreno.

Qualquer controle não deveria impedir que decisões do dia-a-dia sejam tomadas, centralizando decisões de trabalho. Aquelas atividades que deveriam acontecer naturalmente não devem exigir esforço de adivinhação ou auto-proteção, acarretando desperdício de tempo e recursos.

O Dilema da Centopéia

Um poema do século XIX fala de um sapo espertinho que pergunta a uma apressada centopeia que passava ao largo: Qual a próxima pata que ela iria mover? A centopeia faceira ao tentar racionalizar seus movimentos para responder a pergunta, tropeça e cai no charco.

Líderes não deveriam recorrer a microgerenciamento, declarando não confiarem na capacidade de seus liderados, apenas na sua própria decisão. Nestes casos, aos times resta tentar antecipar o que o líder vai decidir ou tropeçar, “cair no charco” com atrasos e retrabalho.

Microgerenciamento

Meu estudo no mestrado usou o modelo Job Strain Model de Karasek, que estabelece trabalho ativo como aquele onde há alta demanda e autonomia do executor sobre a forma como melhor pode realizar, o oposto é trabalho passivo, reduzindo o controle e gerando desperdício.

O microgerenciamento gera trabalho passivo e zona de conforto, mesmo não transparecendo, o foco é entregar aquilo pelo qual vai ser cobrado, evitar riscos e pró-atividade, pois ela pode não ser bem aceita, uma situação que é a antítese de equipes auto-organizadas.

A obsessão por controle cria feudos (silos) e demonstra desconfiança da liderança na capacidade e qualificação de suas equipes em fazer o seu trabalho e tomar decisões cotidianas, gerando um ciclo vicioso de comando-controle, ações reativas, stress, atraso e zona de conforto.

Paralisia de Análise

Chamamos de paralisia de análise situações que poderiam ser fluidas, dinâmicas, seguindo pressupostos e modelos que mostram que profissionais do conhecimento necessitam de espaço e alçada para fazerem seu trabalho da forma melhor e otimizada, ainda mais em equipe.

O overhead gerado por muitos controles e restrições em atividades e tarefas do dia-a-dia gera apenas demora nas tomadas de decisão, coisas simples e imediatas geram tensão e dúvidas, não sobre o que é o melhor, mas o que o gerente espera ou exige de fato naquela situação.

É o oposto dos princípios iterativo-incrementais-articulados propostos pelos princípios e métodos ágeis, baseados em equipes auto-organizadas, até mesmo porque comando-controle e pressão só é eficiente em atividades braçais, repetitivas, onde o capital intelectual não é o diferencial.

Reflita, com o passar do tempo deixamos de ouvir falar sobre CMMI e MPS-Br, enquanto é crescente e onipresente DevOps, Management 3.0, Agile e TI-Bimodal, temos o PMBOK Ed 6 e seu apêndice ágil, estudos cintificos crescentes sobre Agile Governance e Agile PMO – porque será?

 

1

Ao invés de perguntar sobre documentação, aprenda com ela

Que tal um Doc Journey Map, como um Customer Journey Map inspirado em 5w2h e SIPOC?

Conforme o porte da empresa, envolvem-se Governança, PMO, área de processos e representantes das equipes, trata-se de uma necessidade e responsabilidade da organização estabelecer alguns padrões e GQA necessário.

Lembra SIPOC, trabalha uma espécie de 5w2h de origem a destino de cada artefato, incluindo uma reflexão sobre custo (empenho), confiabilidade, redundância e validade, quer temporária ou permanente.

Como todos os canvas e artefatos ágeis, são experienciais, o objetivo não é seguir o roteiro, mas estabelecer uma discussão focada em desperdícios e valor, assertiva, da melhor forma possível, caso-a-caso.

Não se preocupe com o número de campos, o preenchimento é orgânico, preencher é fácil e rápido se as pessoas envolvidas estiverem presentes, promovendo um debate não sobre certo e errado, mas uma auto-avaliação, momento e necessidades.

DOC JOURNEY MAP II

Baixe o canvas acima em tamanho A3
Baixe o canvas acima em tamanho A4

Em startups e pequenas empresas nunca usei, nunca precisou, esta é uma técnica para grandes empresas, quando há áreas de processo, governança e PMO, pois a discussão sobre métodos ágeis sempre envolve também documentação.

Um exercício que pode gerar muita empatia e sinergia, todos buscando potencialmente passar a gerar artefatos com maior conhecimento do processo, o mínimo realmente necessário, considerando origem, destino e relevância.

Eu sempre começo pelo processo, é quase um aquecimento, de forma simplificada, garantindo sempre que seja divertido e descontraído, direto no quadro branco. O resumo é o passo-a-passo da documentação em questão, eu coloco inclusive os nomes da galera.

Artefato – Nome do artefato
GT – Grupo de trabalho
Data – Datas de discussão

Quem cria – papel ou equipe
Onde/como – ferramenta e repositório
Conteúdo/objetivo – informações
Custo/energia – Tempo e envolvimento
Redundância – Único ponto ou não

Quem usa – papel ou equipe
Quando/porque – momento e para que
Valor agregado – qual o seu valor
Validade – temporário ou permanente
Confiabilidade – é confiável, timing

Processo – fluxo simplificado de manipulação desta documentação
Meta/futuro – qual a projeção, melhoria, mudanças, novas práticas, substituição

Não tem um roteiro rígido, mas bom senso, eu uso uma folha para cada artefato utilizado ou proposto, preenchendo com postits pequenos, pelos olhos de quem faz e quem consome … estruturando um mapa de docs na parede, da esquerda para a direita representando tempo.

Uma folha para cada documento ou artefato, entre as pessoas interessadas, em um GT, não impondo certo ou errado, mas provocando uma reflexão e debate sobre cada oportunidade, construção e manutenção, custo x benefício.

No mercado tem uma variedade de artefatos e documentos, alguns bem tradicionais, alguns ágeis, muitos em transição – Visão, análise de negócio, casos de uso, ER, histórias do usuário, product backlog, BDD, protótipos, cenários de testes, …

Não é um autor que vai dizer o que é bom ou não para o momento de vocês, afinal estamos todos em transição, os livros, artigos e debates em fóruns e CoP’s ajudam a ter maior discernimento neste debate sobre o que manter, mudar, abandonar, um passo cada vez.

O campo de meta/futuro é exatamente identificar alternativas futuras para substituição ou mesmo eliminação, quem sabe boas práticas como histórias do usuário, seguindo DDD, partindo de BDD, código auto-documentado e clean code, uma boa orientação a serviços, automação de testes funcionais, etc.

Documentação é inversamente proporcional às suas boas práticas ágeis
Acredite, documentação é muito mais que as tais histórias do usuário

2

Sua carreira deveria ser um de seus hobbies

Vejo o planejamento de carreira como meu hobby mais instigante, até mesmo porque ter prazer em sonhar e projetar diferentes cenários futuros deveria ser algo apaixonante à todos nós – onde, como, porque, com quem, fazendo o que, ganhando quanto, para quando.

O risco de vermos nossa carreira como trabalho é acabar acreditando que carreira é só o trabalho, cartão-ponto, mas é muito mais, trabalho é apenas o aspecto efêmero da carreira. Carreira é hobby, arte, como no cinema, (re)criando storyboards, (re)desenhando o futuro.

O risco de não vermos nossa carreira como hobby, é seguir caprichos do acaso ou sorte, correr o risco de seguir como muitos profissionais que não possuem qualquer plano, trabalham onde há vaga, onde lhe chamarem, como um mal necessário, qualquer coisa com salário serve.

Hobby – Algo interessante que se goste de fazer em horas vagas ou para passar o tempo.

Planejamento de carreira envolve pesquisa, networking, interação, o que nos leva a saber mais sobre onde queremos trabalhar e onde NÃO queremos trabalhar. Começa por autoconhecimento, missão, visão, objetivos, passa por modelagem e envelopamos com planejamento.

Afora SWOT, Johari, mapa de competências, sempre sugiro um Business Model You expandido de três informações – seus sonhos de futuro, quais competências lhe dão sustentação e facilitarão atingi-los, quem são parceiros de viagem, os bruxos que ajudarão a fazê-lo.

Quando se pensa em empresas, onde queremos trabalhar ou mesmo construir, é fundamental entender e discutir sua cultura, ambiente de trabalho, qual o modelo mental na prática, trabalhando como operários, especialistas ou profissionais do conhecimento.

Essas informações não encontramos nos classificados, exigem algum empenho, networking, almoços ou cafés com pessoas que lá trabalham, buscar conhecer muito mais que as vagas abertas, mas como é trabalhar com suas pessoas, mindset, hierarquia, ritmo, agilidade.

21169241_1153030664841686_90682797_o

Este post inspirou-se em uma conversa e no artigo do Fábio Trierveiler, agile coach de uma das maiores empresas brasileiras de tecnologia, sediada em SC – https://www.linkedin.com/pulse/musiquinha-do-fant%C3%A1stico-te-causa-depress%C3%A3o-est%C3%A1-na-f%C3%A1bio

A seguir, alguns posts meus sobre o tema:

 

1

Documentação é inversamente proporcional às suas boas práticas ágeis

O volume de documentação que uma empresa precisa é inversamente proporcional ao número de boas práticas ágeis que pratica, desde a relação de confiança com o cliente, interação entre as pessoas, auto-organização, qualidade, especificação tardia e excelência técnica.

No século XX tínhamos contratos rígidos, escopo prévio, preditivo e extensivo, muita desconfiança, bônus e penalidades, comando-controle e muito tempo em change management. Isso gerava baixa efetividade e qualidade, decorrente do stress e zonas de conforto gerados por isso.

No século XXI temos orientação à relacionamento, equilibrando valor e excelência, buscando eliminar todos os desperdícios visíveis em prol de valor entregue no tempo e custo, com documentação mínima, necessária e viva, valorizando boas práticas em engenharia de SW.

Confiança é a base

A mudança de paradigma faz com que clientes e usuários apropriem-se de seus projetos, participando ativamente ao invés de terceirizar o trabalho com a TI. A TI ao invés de se ver como fornecedor, assume o papel de parceiro, colaborando ativamente para seu sucesso.

O vetor mais relevante é a retirada do teatro das relações interpessoais e comerciais, assumindo-se uma posição cooperativa, mitigando a Lei do Gerson (tirar vantagem), a Lei Ricúpero (enganação), na troca de uma relação pautada na desconfiança por uma de confiança e sinergia.


imagem – http://nathandonaldson.com

Temporário ou Perene

É importante saber distinguir para si o que é documentação temporária ou documentação perene, pois usamos documentos, quadros e mapas mentais no dia-a-dia, a maioria deles de utilidade volátil a medida que o projeto segue adiante, então: Descarte o descartável.

Quanto a necessidade, é preciso entender o problema, ao invés de perguntar o que se quer, usar de empatia para colocar-se no lugar do cliente, usuários, stakeholders e equipe, entender o 5W2H dos desafios, a cada passo, temos um entendimento, alternativas e best choice.

Se você não usa conceitos convergentes, tal como domain driven design (DDD), behave driven development (BDD), Service-Oriented Architecture (SOA), código limpo e auto-documentado, … é pouco provável que documentação mínima e mapas mentais sejam suficiente;

O que vejo por aí? Documento de visão, termo de abertura, inception, casos de usos, histórias do usuário, product backlog, mapa de arquitetura, integrações, regras de negócio, protótipos com principais regras funcionais, plano e cenários de testes, mapas mentais, canvas, etc.

Novos Paradigmas

O método, tanto quanto documentação trabalham para o valor a ser gerado, jamais o contrário. O contrato e combinações é para serem usados como baliza do trabalho do time e partes interessadas, empenhadas em fazer o seu melhor dentro do custo, tempo e escopo-base;

Agile – Planejamento baseado em alto nível de abstração e complexidade, ciclos iterativo-incrementais-articulados, detalhar e tomar decisões no último momento responsável, se a arquitetura e arquitetura for legível, a documentação será mais leve e talvez temporária;

Enxuto – Privilegiar o vital e não o trivial, registrar o óbvio é inútil, foquemos no desconhecido de alto impacto, é desnecessário registrar o óbvio. Quanto mais enxuto e relevante melhor. Valor está no uso e quanto maior, menor o uso, maior o custo relativo e mais rápido caduca;

5W2H – É fundamental mapear entre os envolvidos, racionalmente cada artefato ou documento, a quem ele interessa, qual a alternativa ideal, o que é e porque existe, quanto custa a sua atualização, por quanto tempo será útil, quando deve ser feita e se permanece ou será descartada.

Referências

Há algumas cláusulas pétrias quando falamos de documentação ágil, como YAGNI (You Aren’t Gonna Need It), KISS (Keep it simple stupid), auto-documentação enquanto excelência em engenharia de SW, menor assombro (seguir padrões), DRY (não redundância), garantia de links estáveis, especialização (foco), dependências estáveis, fácil de manter, fácil de encontrar – www.agilemodeling.comwww.smartics.eunathandonaldson.com.

Documentação tem a ver com a cultura da organização, relacionamento e tecnologia, por isso tem a ver com boas práticas ágeis. A regra é trabalhar de forma fluida, sem tanto desperdício, seguindo a máxima de Pareto – Poucos Vitais para muitos triviais.

Conclusão

Sem boa engenharia de software, domain driven design (DDD), behave driven development (BDD), arquitetura orientada a serviços, código limpo e auto-documentado, … é pouco provável que uma documentação mínima e mapas mentais sejam suficientes;

Use o conceito de “Gemba” do Lean, pergunte a quem está onde as coisas acontecem, não faça documentação por idealização de quem não as constrói, mantém ou usa. Documentação boa é documentação útil, ela tem que informar coisas relevantes e serem confiáveis.

Pare de buscar receitas mágicas e aprenda a cozinhar, estabeleça uma discussão sobre sua documentação atual, perenes ou temporárias, se está lendo este post é porque já sabe o suficiente para pensar Lean, experimentar, aprender e melhorar.

0

Do Takt Time do Lean ao Tiki-Taka do Barcelona

Os conceitos e fundamentos do Lean sobre fluxo são essenciais para entender métodos ágeis. Tem a ver com a percepção de produtividade e efetividade, evitando a sensação de trabalhar muito e não ter os resultados e reconhecimento desejados. Então vamos falar de Takt Time e cadência  \o/

Takt Time é o tempo dividido pela demanda na indústria Lean, um fundamento essencial ao conceito de sistemas puxados, se for rápido demais gerará stress e estoques intermediários, se for lento demais gerará ociosidade e descompasso, ambos induzindo ao erro e desperdícios.

Cadência é o estabelecimento de um ritmo sustentável e equilibrado entre recursos, pessoas, tempo e produção, com valor e qualidade. O segredo é encontrar um ritmo constante que mantenha o fluxo, desafiador mas possível, seguro mas não pessimista.

SCRUM

Equipes que seguem o método SCRUM são impelidas a trabalhar com conceitos e regras que os induzem ao estabelecimentos de seu Takt Time e cadência a cada projeto, de forma iterativo-incremental-articulada, ajustando conforme avançam e aprendem.

Baseado nesta premissa conceitual eu propus o Scrum Setup Canvas antes do planejamento do Release PLan, de forma a levarmos em consideração os vetores e variáveis que influenciam as estimativas em cadência, validando nossa capacidade a cada sprint.

Os instrumentos oferecidos com sucesso pelo método é o DoR (Definition of Ready) e DoD (Definition of Done), o primeiro estabelece os critérios que permitirão o desenvolvimento de cada história de forma eficiente, o segundo são critérios para considerar cada história pronta para o cliente.

o Dor e DoD estabelecem o ritmo de um time, que proporcionará um compasso estabelecendo mínimo desperdício e alta performance sustentável para entrega contínua de valor ao cliente com a qualidade estabelecida e acordada.

A intenção é estabelecer um ritmo cadenciado entre o DoR e DoD, enquanto os desenvolvedores trabalham no desenvolvimento partindo do DoR das histórias do sprint corrente até seu DoD, colegas trabalham para o estabelecimento do DoR do próximo sprint, orquestrando a evolução.

KANBAN

No kanban temos o conceito de fluxo contínuo, método que utilizo muito para equipes de sustentação. Neste caso, não temos o Release Plan, DoR e DoD como no Scrum, pois trabalha foco naquilo que é mais importante a cada momento, não constituindo sprints, mas continuamente.

Mas o mesmo mecanismo é utilizado de forma diferente, priorizadas as alterações corretivas ou evolutivas o time vai puxando conforme escala e trabalhando de forma a entender, executar e atender, entregando valor e qualidade sem o estabelecimento de demandas para cada duas semanas de trabalho.

Neste caso, ao se utilizar de suas boas práticas, teremos um quadro físico ou virtual com a evolução de status até estar pronto, regras explícitas, estabelecimento de quantidades, monitoramento de fluxo com métricas como lead time, cycle time, throughput, burn down, cumulative flow.

Na prática, a essência do conceito de equipes de alta performance diz mais respeito a cadência coletiva que a produtividade individual, quais as técnicas que nos auxiliam a práxis de comunicação ativa, colaborativa e tomadas de decisão a cada dia em prol de eficácia e eficiência em processo e produto.

TIKI-TAKA

Uma analogia descompromissada com o famoso conceito Tiki-Taka do Barcelona e seleção espanhola, definido como um sistema baseado em posse de bola através de passes curtos utilizando todos os espaços do campo e todos os jogadores, a bola não para, cada jogador sempre com múltiplas opções de passe rápido.

No sistema catalão, também usado pela seleção espanhola, todos os jogadores participam direta ou indiretamente da jogada, movimentando-se de forma a serem uma opção para receber a bola e passar a outro colega, mantendo o ritmo, atenção e colaboração ativos sempre, envolvendo o adversário e, com frequência, vencendo.

CONCLUSÃO

Os desperdícios do Lean dizem respeito a tudo o que possa comprometer nosso Takt Time e cadência de valor, produção apressada com estoques intermediários inúteis e de alto risco, movimentação indesejada, execução defeituosa, foco fora da prioridade a cada momento, tudo isso dinamicamente.

Fazer certo a coisa errada é tão ruim quanto fazer errado a coisa certa, é preciso fazer certo a coisa certa, um passo de cada vez, de forma cadenciada, sempre iterativo-incremental-articulada, com pequenos e contínuos ciclos sustentáveis, projetando, executando, validando e corrigindo.

Não é tão difícil assim, é só começar a andar e a cada ciclo ir experimentando, aprendendo e melhorando, deixando as retrospectivas fazerem seu trabalho. Como disse o Bilbo Bolsseiro, “Você pisa na Estrada, e, se não controlar seus pés, não há como saber até onde você pode ser levado …” \o/