Arquivo da tag: opinião

2

$howbiz e auto-promoção estão deturpando eventos e princípios ágeis

|

Muitos agilistas brasileiros estão preocupados demais com o ego e em vender “novos” treinamentos, modelos, certificações, criar bordões, vender coaching, palestrar muito em todos os eventos, com muita pirotecnia e muito show de ilusionismo. Sempre pensando na próxima palestra com conteúdo espetaculoso ao invés de contribuir.

Isso já aconteceu na praia do universo startup, que aos poucos virou uma enganação, o negócio não é ajudar a gerar resultados, o negócio é showbiz, onde ir palestrar, gerar factóides e gerar gurus virou um objetivo muito lucrativo, para muitos o business está nos eventos, palestras, seu negócio é o Startup Showbiz.

Também já aconteceu no universo do coaching, essa praia deturpou tanto que até eu sou sondado a cada semana, pois para ser um coach é só certificar-se em um curso PNL de final de semana para então começar a usar isso a seu favor, … desculpa, mas no século XX o nome disso era charlatanismo.

Eu palestro cada vez menos, quando o faço eu sou quase rabugento, inicio alertando que sou ácido contra esse grande negócio Agile, Startup, Coach, que ao invés de acelerar está empatando. Até entendo, pois é a lei da oferta e procura, apontar culpados e receitas mágicas é o que a maioria quer, então tem cada vez mais quem venda.

Quem assiste acaba achando que está fazendo algo muito errado, porque ele não é como palestram, logo, tem que contratar um coach ou consultor para melhorar (sic) … se ele soubesse que a palestra conta 25% e omite os 75% daquilo igual ao que ele chama de carência por um coach … daria um processo de propaganda enganosa!  😦

um-bom-negocio

Agile showbiz paradoxal

Entrada triunfal, apontando erros e criticando o que está posto, oferecendo as únicas receitas que funcionam, minando iniciativas anteriores com frases de efeito e muita auto-ajuda, ironicamente fazendo isso após falar de PDCL, Kaizen, Gemba, baby steps, Karasek e Tuckman.

Tem muito agilista que palestra sobre um monte de coisas legais, descoladas, divertidas, criativas, mas na maior parte das vezes tudo isso ele faz em 25% do seu tempo, nos outros 75% não é mais que um bom e velho GQA de processo, porque agilidade tem que ser do jeito dele.

É fácil de reconhecer, eles tem convicção de que o que eles sabem e orientam é a melhor solução, as outras não, consequentemente geram um paradoxo esdrúxulo, pois eles defendem a auto-organização, desde que da forma deles, o resto é ilógico, ruim e incongruente.

Ok, entendo, é um bom negócio!

O MiMiMi do Scrum, Kanban, ScrumBan, XP, Lean, SAFe, S@S, Less, Mng 3, DT, não tem fim e gera milhões de receita, cada um de seus defen$ore$ fazendo de conta que só o seu resolve … eu sempre ofereci escolherem um como base, pinçando boas práticas e opções dos outros não oferecidas pela base escolhida.

A maioria omite os pontos de contato porque o seu curso, certificação, coach, palestras e outras fontes de receita e ribalta são Scrum, Kanban, XP, SAFe, … Tem que fazer de conta que é único, singular e mágico … a discussão entre Scrum, Kanban e XP seria engraçada se o ônus não fosse tão alto para o mercado e empresas.

Se é um ou outro, se não pode experimentar, se após acertar não pode mais errar, se todas as equipes possuem pautas e métricas extrínsecas comparativas, se apontamos “culpados”, se errar é inaceitável, qual foi a aula sobre Agile que eu faltei?

Uma das estratégias mais incríveis é negar aprendizados, ao invés de continuar evoluindo é preciso negar, se não conseguir, mudar os nomes das coisas, via de regra eu fico com a impressão de que o objetivo é preparar a próxima palestra no próximo evento, permanente gerando o próximo “case” … business em segundo plano.

Os eventos de Agile a muito tempo se tornaram iguais aos de Startup, grandes cifras e muito showbiz, muitos dos que estão lá palestrando estão mais preocupados com seu enorme ego e seu business do que passar conhecimento realista, verdadeiro, vicariante útil.

Paradoxo do coach indispensavel substitui o paradoxo de controle e o do super-heroi

0

Jogo – Você Prefere?

|

Que tal um jogo em que temos uma linha divisória, a cada pergunta do facilitador as pessoas posicionam-se a esquerda ou a direita. As perguntas devem ser instigantes, inesperadas e polarizadas, posto que as pessoas precisam sempre posicionar-se preferencialmente à primeira ou segunda opção.

Inicie pedindo que todos fiquem sobre a linha e explique que para escolher a primeira opção devem ir para a direita, a segunda é à esquerda. Cada pergunta feita deve iniciar com “Você prefere?”:

  • Cobertura de código ou entrega?
  • Qualidade ou débito técnico?
  • Documentação ou conversação?
  • Testador na equipe ou só desenvolvedores?
  • Aos stakeholders, status report ou comunicação verbal?
  • Review ou retrospectiva?
  • Último dia, fazer a daily ou terminar o código?

PRINCÍPIOS: No cotidiano do trabalho em uma equipe de desenvolvimento de software, muitas vezes não é uma questão de certo ou errado, mas de equilíbrio entre o ideal, o desejável e a necessidade, as metas.

DICA: Mescle algumas perguntas diferentes, divertidas, inesperadas em meio às pertinentes ao seu projeto, tecnologia e princípios. Por exemplo:

  • Possuir um cachorro ou um gato?
  • Tirar férias ou economizar?
  • Conhecer seu futuro ou mudar o passado?

0

Value Stream Mapping

|

A criação de um mapa de fluxo de valor de estado atual é um passo importante quando estamos debatendo nosso processo de trabalho, mas a meu ver é fundamental que entendamos os conceitos, os processemos e a luz de nossa realidade adaptemos ou simplifiquemos à nossa necessidade.

Tenho cases bem legais em áreas como financeiro, contratos, compras, RH, educação, conteúdo, baseados em “Genchi Gembutsu” e “Gemba Walk”, que traduzem o conceito de verificar in loco onde as coisas acontecem, com quem faz acontecer. Porque o primeiro passo é não tomar decisões sem convidar para o debate quem faz acontecer, inexiste entendimento sem envolver as pessoas.

O mapa de fluxo de valor do estado atual é um trabalho onde a equipe, com ajuda de um facilitador, debate e mapeia os limites e passos do processo, os dados e fluxo, os tempos de execução e transição, tudo isso para debater gargalos, problemas e oportunidades para planejar e experimentar melhoria.

No slideshare encontrei este desenho de processo para execução iterativo-incremental de mapeamento e melhoria do mapa de fluxo de valor (Lean Webinar Series):

Eu muito usei este conceito ajudando áreas de escritório (Lean Office) a mapear e tentar melhorar seus fluxos de valor, mas para ilustrar este post eu procurei exemplos de desenvolvimento de software para tornar mais legível para a maioria, exemplo de indústria há milhares no gloogle.

O que é VSM

Mapeamos o fluxo de valor do estado atual com o intuito de enxugá-lo e construirmos o estado ideal ou futuro, para tanto representamos o passo-a-passo de cada um de nossos fluxos de trabalho, entendendo atores, responsabilidades, informações, recursos e tempos médios.

Trata-se de um exercício coletivo e colaborativo, envolvendo representantes de todas as áreas e equipes, todos temos condições de fazê-lo se desapegarmos de notações, foque no fluxo e não no formato, debata e ao mesmo tempo registre diagramaticamente de forma clara aos presentes.

Um rabiscoframe legível e claro a todos os presentes vale muito mais que um diagrama cheio de regras e notações, quando perdemos tempo abertos a comentários e rec
lamações que nada agregam em valor ao assunto, apenas a regras de representação absolutamente dispensáveis.

Quem nós somos e o que fazemos?

Sugestão, use um Role Model Canvas, um Design Ops Canvas, inicie alinhando quem nós somos, qual é a nossa missão, restrições, informações, ferramentas, … liste os principais fluxos de trabalho, escolha aquele que mais tem a agregar se o analisarmos e enxugarmos.

A escolha diz respeito a Pareto, queremos mapear um fluxo de projeto, operação, relacionado a um produto ou serviço, interno ou externo, frequentemente diz respeito a algo que está gerando problemas, mas pode ser algo novo, um desafio ou objetivo organizacional em enxugar.

Quem fará a facilitação?

É importante ter alguém que faça a facilitação, mediação, provavelmente alguém com alguma experiência ou habilidade na diagramação de mapas de valor ou processos, podendo ou não ser alguém do time ou (frequentemente) um profissional dedicado a este tipo de trabalho.

Ele alinhará de início algumas regras e técnicas Lean ou Ágeis para debates colaborativos, registrará o objetivo e criará alguns quadros auxiliares, bem como combinará em comum acordo alguns acordos sobre simbologia, significado de cores, postits, etc.

Essas combinações são essenciais para direcionar os debates, diz respeito a fazer um pacto de trabalho, delimitando algumas balizas e restrições, acordando o(s) principal(is) foco(s) de atenção e dedicação.

Desenhando o fluxo?

O desenho incia invariavelmente por um storytelling, com key-users, usuários e operadores contando como realizam este trabalho, onde ele inicia, por onde passa, suas operações, filas, transformações, evitando entrar a nível de tarefas ou detalhamento de atividades.

É muito importante neste momento incluir os fluxos de informação envolvidos, solicitações, registros, workflows, aprovações, aguardando, manipulações, sempre a partir de um paradigma de operação e não detalhando atividades, mergulharemos nela mais adiante se necessário.

Esta discussão tem valor per si, o simples fato de colocar as pessoas para discutir seus trabalho atual explicitam eventuais desperdícios ocultos, alguns preconizados pelo Lean desde a década de 50, como estoques de inacabados, deslocamento desnecessário, complexidade desnecessária.

Se a equipe for provocada desde o início a sair da caixa, analisar críticamente sem prévios conceitos e questionando regras e hábitos, é muito provável que todo e qualquer fluxo terá desdobramentos para otimização e enxugamento de seus passos, potencializando seus recursos e tempo.

Dados, medidas e informações?

Agregue informações pertinentes a métricas do seu fluxo, de cada passo e entre eles, mas evitem percepções abstratas ou históricas, gere informações atualizadas e reais para evitar birras e distorções pessoais ou mesmo coletivas.

Ao registrarmos tempos médios, se necessário também mínimos e máximos, muito do valor pertinente a demora e oportunidades de redução se explicitam automaticamente, informações básicas do Lean são Lead Time (desde a requisição inicial) e Cycle Time (tempo de execução).

No mapeamento de fluxo de valor dedicamos algum tempo na análise de tempo, quer no de execução de uma operação quanto no tempo de fila ou aguardando algo, o que muitas vezes se reflete em desperdícios.

Obs: A imagem abaixo retirei de um post em que Al Shalloway destaca que um bom Kanban com seus status visíveis de fluxo seria um passo dado para incrementar médias e informações para análise de gargalos, algo que tentamos fazer sem explicitar um VSM, mas usando quadros auxiliares com Lead Time, Cycle Time, Throughput, …

Como criar o mapa de fluxo de valor do estado ideal?

Iniciamos combinando qual é o ideal que queremos ou necessitamos, para então começar ciclos de análise, debate, proposição a partir dos pontos de maior desperdício ou “dor”. Iniciamos debatendo o ponto em comum acordo que é onde maior valor agregaria se o otimizassemos e assim por diante.

Aqui entra em ação nossa Toolbox, apoiados por frameworks, técnicas e boas práticas para otimização de cada operação analisada, como o uso de quadros Kanban para eliminar desperdícios de tempo e estabelecer um fluxo puxado.

Naturalmente vamos planejar algumas melhorias, priorizadamente, em ciclos evolutivos, iterativo-incrementais-articulados, para avaliar, planejar o próximo passo e seguir adiante. A técnica recomenda que demarquemos os pontos que estão sendo priorizados e a ação que está sendo realizada a cada novo passo (kaizen Burst).

As vezes temos resultados imediatos, mas para atingir um estado ideal otimizado é preciso persistência e dedicação.

0

Ishikawa para análises de causa-efeito

|

Não sou preconceituoso com boas práticas só pela idade, talvez por empatia, afinal já ultrapassei a barreira dos 55 anos há algum tempo, então uma técnica conhecida e fácil sempre é uma opção conforme o perfil, formação e área do grupo. Dito isto, já usei Ishikawa e continua sendo uma opção na minha Toolbox.

O Diagrama de Ishikawa é usado para análises causais, por isso é conhecido como “Diagrama de Causa-Efeito”, mas devido ao formato é conhecido como “Espinha de peixe”. Em grandes grupos sigo os princípios de Dojo com piloto e copiloto como no Managing Dojo e World Coffee.

  • Efeito – O que queremos entender e solucionar;
  • Categoria – Principais grupos de problemas;
  • Causa – Causa possível pertencente a um grupo;
  • Soluções – Alternativas ou oportunidades.

Análise causal de problemas, utilizada por equipes empenhadas na busca por soluções ou melhorias em seu processo ou produto. Apesar do original da década de 50 ter sido criado em um formato para a indústria, eu não uso os temas originais e defini-los faz parte da dinâmica, como tecnologia, ambiente, processo, pessoas, empresa, cliente, etc.

Segundo a Wikipedia: “O Diagrama de Ishikawa, também conhecido como Diagrama de Causa e Efeito ou Diagrama Espinha de peixe, é um gráfico cuja finalidade é organizar o raciocínio em discussões de um problema prioritário, em processos diversos, especialmente na produção industrial. Originalmente proposto pelo engenheiro químico Kaoru Ishikawa em 1943 e aperfeiçoado nos anos seguintes.”

No original, Ishikawa fixou as seis áreas (6M) que exigem reflexão para a identificação de soluções para um problema em uma unidade fabril – Método, Máquinas, Medidas, Mão-de-Obra, Material ou Meio-Ambiente. Entretanto, para desenvolvimento de software é mais flexível – Processo, Ambiente, Ferramental, Tecnologia, Time e Relacionamento.

  • Método: causas no método que estava sendo executado o trabalho;
  • Material: causas no material que estava sendo utilizado no trabalho;
  • Mão-de-obra: causas nas atitudes – pressa, imprudência, qualificação;
  • Máquina: causas envolvendo a máquina que estava sendo operada;
  • Medida: instrumentos de medida, calibração, indicadores, acompanhamento, frequência;
  • Meio ambiente: poluição, calor, poeira, layout, falta de espaço, dimensionamento.
0

Focus Group para assistir, pesquisar, consultar, avaliar

|

Focus Group é uma técnica de pesquisa qualitativa em que um grupo de pessoas é reunida em um ambiente exclusivo e interativo, questionados sobre suas percepções em relação à produto, serviço, conceito ou ideia ali apresentados. Neste contexto, assistido pelos facilitadores, visíveis ou ocultos, cada convidado é livre para falar com outros participantes, experimentar, opinar, debater.

Deve ser realizado em um ambiente adequado, descontraído, funcional, observável, registrando não só a opinião mas as interações entre os membros do grupo, o volume de dados gerados e riqueza de detalhes verbais e não verbais. Bem desenvolvido, geram um mar de oportunidades, analisados em tempo real e a posteriori por equipes multi-disciplinares que assistem a suas gravações.

focus-group

A análise dos dados dos grupos focais apresenta desafios e oportunidades quando comparado a outros tipos de dados qualitativos. Por ser uma experiência de grupo em ‘laboratório’, pode inibir ou potencializar, gerando características únicas e desafiadoras nos dados. Um facilitador inexperiente com certeza pode conduzir ou desperdiçar relevantes sutilezas e situações.

Existem variações para a realização de Focus Group, mas a mais comum trata-se do convite de grupos contendo de 6 a 12 participantes, onde um produto, serviço, conceito ou ideia é apresentada para opinião, podendo haver livre debate, apenas moderado a nível de dinâmica, mas jamais influenciando de alguma forma a opinião dos participantes.

Na minha dissertação de mestrado eu lancei desta técnica para convidar especialistas em implantação de metodologias ágeis para que de forma independente e sem influência externa cada um pudesse avaliar meu artefato de pesquisa e posicionar-se de forma a legitimá-lo e aprimorá-lo.

FOCUS GROUP ÁGIL

Em meados do mês de Outubro foi realizado um Focus Group organizado  pelo doutorando Guilherme Wiedenhoft e pela professora Edimara Luciano, que por acaso também é minha orientadora, com um formato a partir de dinâmica típica de um User Story Mapping. Uma semana antes debatemos o formato e eles optaram pelo uso de um Canvas semelhante ao quadrante mágico do Gartner com eixo X de Relevância (valor) e Y crescendo de específico para genérico.

Para ler mais sobre o tema de Efetividade em Governança de TI, linha de pesquisa da Profa Dra Edimara M Luciano, orientadora do Guilherme e minha:

O quadrante mágico eu uso a anos em workshops para gestão do tempo (importante x urgente), para princípios (crença x realização), para retrospectivas em debates no plano de ação de mudanças (valor x investimento). O principal benefício é favorecer a participação colaborativa e o uso de percepção visual, auditiva, motora, instigando a atenção, argumentação e convergência.

DSC06461p

O Focus Group iria discutir a relevância e validade de um pack de mais de 50 indicadores de efetividade da Governança de TI. Dados que vieram sendo levantados pelo Guilherme em meio a seus estudos, em uma revisão teórica sobre o tema e junto a especialistas. Ele concluiu o mestrado recentemente e hoje cursa o doutorado no PPGAd / FACE / PUCRS.

A dinâmica teve a oportunidade de acontecer em uma sala muito descolada, forrada de fórmica branca em todas as suas paredes, bem iluminada, agradável e que permitiu muita interação entre todos os participantes.

Iniciou com uma explanação feita pelos facilitadores, explicando a dinâmica e realizando um pacto a favor da colaboração franca e participativa. Os quadros, da esquerda para a direita, cfe segue:

  • Um quadro com a legenda de cores para cada critério (ilustrativo);
  • Um quadro contendo todos os indicadores sugeridos para cada critério, a serem discutidos e remanejados no transcorrer do debate;
  • Um canvas com os eixos crescentes de relevância (X) e utilidade (de nicho até os mais generalista);
  • Um quadro para os postits dos indicadores que o grupo concluísse como NÃO sendo indicadores ou inválidos para governança de TI.

canvas-focus-1

Durante o Focus Group, no transcorrer dos debates, os postits foram sendo movidos para os quadrantes do Canvas principal de valor e utilidade ou considerados inválidos. O legal desta dinâmica é que a cada nova movimentação somos obrigados a rever e validar os anteriores, reposicionando-os, reavaliando quando necessário um ou mais dos anteriores frente a novas percepções, pois na medida que se desenvolve vamos mais entendendo e nos apropriando.

canvas-focus-2Como qualquer outra técnica produtiva, o tempo deve ser planejado em mínimos ou máximos (timeboxes), pois se for rápido demais é porque não houve a devida reflexão, se for demorado demais, cansa e torna-se improdutivo. O tempo foi cumprido, uma hora e meia de debates, inicialmente contidos e um pouco caótico como sempre, seguido de um crescente de entendimento e posicionamento de parte a parte … muito legal.

Como sempre, uma pilha de lições aprendidas, coisas a iniciar, a manter e a melhorar … mas uma experiência interessante a ser compartilhada e repetida. Os eixos do Canvas são ajustáveis a cada tipo de pesquisa, assim como há vários outros formatos de Canvas, este é apenas um a ser considerado.

focus-3

1

Paradoxo do Coach indispensável substitui o de Controle e o do Super-Herói

|

Na medida em que o tempo passa, novas fórmulas e modelos mentais vão sendo construídos, substituindo com novas percepções de mercado em detrimento a outros já desacreditados. Infelizmente, algumas mudanças acabam apenas substituindo os antigos paradoxos por novos tão incongruentes quanto.

Paradoxo – Pensamento, proposição ou argumento que contraria princípios básicos e gerais, aparentando falta de nexo ou de lógica; contradição.

Enquanto consultores, entramos já com meta explícita para sair, nosso papel é instigar o interesse em trabalharem de forma colaborativa, auto-organizada, iniciando uma caminhada de aprendizado continuado. A meta não é fazer mágica, mas iniciar uma caminhada evolucionária, ampliando suas caixas de ferramentas a cada passo.

Este post não é um julgamento de valores ou abordagens, apenas reflete sobre os principais paradoxos sobre equipes de trabalho nos últimos 100 anos sob uma percepção das mecânicas organizacionais desde a revolução industrial até os dias de hoje …

Paradoxo do Controle

Na primeira metade do século XX o paradoxo era que controle gerava mais produtividade, mas a produtividade era uma percepção consequente de trabalho sob pressão e em condições físicas e psicológicas que prejudicavam a capacidade produtiva, em tempo real ou em uma visão longitudinal, cumulativa, linear.

Aquele paradoxo do controle gerava uma sobrecarga organizacional em cargos, custos, tempo, de forma que precisamos de mais controle para ter “trabalho”, mas aumentar gestores, coordenadores, supervisores, gerentes, diminui a capacidade de investir no trabalho em si, que conhecemos como Gemba, onde e quem faz acontecer.

Paradoxo do Super-Herói

Na segunda metade do século XX havia o paradoxo preponderante do Super-Herói, da Liga da Justiça, dos profissionais workaholic, destacando o individualismo para serem valorizados. Mas quanto mais valorizamos um indivíduo como Sassá Mutema, salvador da produtividade, menos contamos com a desejada sinergia coletiva.

O paradoxo do Super-Herói ao mesmo tempo era valorizado porque resolvia, mas ele resolvia preponderantemente os problemas que ele mesmo criava, resultado da falta de união e colaboração entre todos os envolvidos em prol do coletivo e dos resultados conjuntos, desprivilegiando a comunicação e gestão do conhecimento.

Paradoxo do Coach indispensável

Muitas empresas investem no novo paradoxo do século XXI, o Paradoxo do Coach indispensável, papel que deveria ser libertador, mas ao invés disto cria dependência através de um processo continuado de sapiência singular para direcionamento adequado, como uma babá para evitar que crianças façam a coisa errada.

Um paradoxo que gera a cada dia novos coachs indispensáveis, não só Agile Coach organizacionais, também Life Coach, Personal Coach, Teen Coach, Baby Coach, … o paradoxo é o coachee ver-se dependente do coach para continuar avançando, gerando dependência ao invés de auto-conhecimento e auto-organização.

O antídoto segundo Len Lagestee

É a antítese da proposta por Len Lagestee, Agile Coach de Chicago em http://illustratedagile.com/2016/10/24/exit-strategy-agile-coach/ quando afirma que um Agile Coach não deveria trabalhar para perpetuar-se (em monitorar e controlar para dizer o que é melhor e o que é certo), um artigo a mim apresentado pelo colega Silas Serpa de SP.

Em um mindset de comando-controle, este paradoxo é mais do mesmo, pois quanto mais precisamos de uma pessoa para dizer o que está certo ou errado em nome da organização, mais lembrará GQA e gestão, uma pasteurização que trabalhará contra o objetivo de auto-organização e protagonismo.

A chave não é controle, mas propósito, aprendizado, equidade, então a solução não é continuar valorizando gestão e monitoramento, métricas e indicadores, a chave é para ser colaboração e coletividade baseados em um senso comum de confiança, de liberdade com responsabilidade, cada time e profissional com suas peculiaridades.

Conclusão

O verdadeiro processo Kaizen é suscitador de acertos e erros, aprendizados diretos e indiretos, verticais e horizontais, criar papéis paradoxais e mantê-los mais que o mínimo necessário, ao invés de acelerar, atrasará a mudança. Se as pessoas percebem que não decidem, tocarão o barco e aguardarão para saber o que fazer, sem se arriscar.

Cada grupo humano é único, se queremos maior performance do time e para isso contratamos um “gestor” travestido de coach com o objetivo de comparar e cobrar melhor performance, talvez indique que 100 anos depois ainda tentamos reinterpretar os estudos do casal Gilbreth sobre tempos e movimentos.

O que garante aprendizado, foco e engajamento são mecanismos que proporcionem comunicação, garantindo a auto-gestão do conhecimento por toda a organização, através de encontros, CoP, compartilhamento, retrospectivas e futurespectivas. É a mágica do moto-contínuo, que ao invés de dissipar energia, a potencializa!

Um post de opinião na mesma linha do https://jorgeaudy.com/2017/01/12/uma-alegoria-poetica-e-dura-para-agile-coachs/

 

0

O caminho é sermos Iterativo-Incrementais-Articulados

|

Há sete anos compartilho neste blog absolutamente tudo o que aprendo, alguns podem ser generalizados e outros não, mas tudo é fruto de muito estudo, leitura, proposição, experimentação e aprendizados a partir de tudo isso … me orgulho muito quando dá match com ideias de ícones da área.

Desde 2012 compartilho a percepção de que em Agile temos múltiplos Duplos Diamantes (Design Council), que é a representação diagramática mais significativa do Design Thinking, para entender, observar, gerar empatia, idear, prototipar, iterar e aprender.

Ser Iterativo-Incremental é pouco, devemos ser Iterativo-Incrementais-Articulados, planejamos em alto nível de abstração para aprender mais e mais a cada sprint e melhorar a cada iteração. Essa é a essência do conceito de Decidir no Último Momento Responsável, após acumular novos aprendizados e conhecimentos a cada sprint.

design thinking

Metodologias ágeis se utilizam dos mesmos princípios baseados em empatia, colaboração, coletividade, multidisciplinaridade, pertencimento e feedback. Rapidamente deixei de usar os diagramas tradicionais do Scrum, porque desenvolvi um diagrama com pequenos duplos diamantes a cada sprint, DoR x DoD, baseado em meus aprendizados.

Em abril o Eduardo Peres compartilhou comigo um artigo de 2017 do Jeff Pathon – https://jpattonassociates.com/dual-track-development/ – que chegou a algo muito alinhado a minhas crenças e representações, mesmo sem usar a mesma analogia, ambos transformamos cada DoR em uma oportunidade de duplo diamante  \o/

piramide abstração 2 - scrum

O pré-game é um ou mais duplos diamantes, usando técnicas diversas para entendimento, observação e seleção de alternativas, prosseguindo com ideação, prototipação, validação e planejamento em iterações, encerrando com um planejamento inicial, MVP, iterativo-incremental-articulado.

Nos ciclos iterativos-incrementais-articulados, cada combinação de DoR seguido de DoD é um pequeno duplo diamante, cada ciclo de entendimento, discussão e especificação em discovery é complementado por desenvolvimento, testes e homologação em delivery.

Ciclos concorrentes, onde o discovery/DoR está sempre um passo a frente, pré-requisito do ciclo de delivery/DoD, este quando estiver sendo executado tendo em paralelo inicio e especificação de um novo discovery/DoR, imprescindível para a próxima iteração, o próximo duplo diamantezinho dos nossos sprints.

multiplos diamantes

O desenho acima foi como tudo começou quando tentei diagramar o método SCRUM de uma forma em que o ciclo de DoR de Discovery fosse precedente ao ciclo de DoD de Delivery. Desta forma, teremos sempre ciclos concorrentes e subsequentes em pedaços mais relevantes e cronologicamente organizados.

Antes mesmo de compartilhar o diagrama, fui refatorando por achar que estava muito complexo com os tais diamantezinhos, concluindo que a simples alusão usando uma diagramação mais simples seria melhor, chegando ao desenho final que adotei, do qual tenho muito orgulho quando a uso para explicar princípios e framework.

scrum

James Shore em 2012 apresentou no Agile Brazil seu modelo de fluência, onde percebe-se agilidade desde o primeiro passo, assim que uma equipe e empresa inicia sua caminhada. Quem acha que Design Thinking é só quem usa blocos coloridos, sucata, ludificação, desculpa aí: É porque não entendeu nada!

NÃO acredito em receitas mágicas, monolíticas, sou defensor da convergência metodológica. Quem só acredita em uma metodologia, framework ou conceito do seu tempo, tende a ter uma visão intensa, monocromática e limitada de causas e efeitos, apostando na sorte: As vezes da certo, as vezes não!

Design Thinking é modelo mental complementar e sinérgico ao Scrum, Kanban, Lean Startup, Gamestorming, Lean Office, todos seguem os mesmos princípios e nenhum deles é independente. É insano aplicar um sem analisar complementariedade metodológica, necessário e desperdícios, valor e foco, negócio, tecnologia, envolvidos.

No Dual Track do Jeff Pathon, ele não cita o duplo e chama Delivery de Development, mas o resultado é absolutamente convergente (pessoalmente gosto mais do meu diagrama). Após o Release Plan, até o fim do projeto estaremos refinando, melhorando, agregando múltiplos aprendizados a cada novo sprint de DoR + DoD: