Arquivo da tag: retrospectiva

3

Toolbox 360° – Edição SP Março 2019

|

A parceria e organização foi da Egrégora Inteligência, puxado pela amiga Renate Land, na DoMore Training da Av Paulista a uma quadra da FIESP, a sala preparada para um dia de muita interação, compartilhamentos, debates e insights … do jeito que eu gosto, com fundo de cena e provocações implícitas e explícitas a cada minuto.

O workshop oferece fundamentação, histórico e mediadores da mudança ou quebra de paradigmas do século XX para a nova era do conhecimento proposta pelo século XXI, seguida de vários trabalhos em grupos, dinâmicas autorais como o jogo Desafio Toolbox, Toolbox Wall e técnicas variadas.

Todo o fundo de cena, desenhos e personagens são obra da Luisa Audy, hoje estudante na VFS no curso de animação, o vídeo animado dos personagens é trabalho da Anima Pocket da Adri Germani … eu fico emocionado sempre que olho o vídeo do jogo Desafio Toolbox 360°, é muito FO-FO!

Contei com a presença de muita gente querida, parceiros de viagem, alguns com quem já muito interagi, alguns que só conhecia virtualmente pelo linkedin e facebook – a Claudia Montagnoli, Monique Padilha, Camila Teixeira, Robson Sanchez, Frederico Oliveira, Karen Medina, Laura Fontana, com uma variedade de empresas presentes, algumas já parceiras de outras edições como a TOTVS, Everis, BRQ e Itaú, além de novos parceiros nas redes sociais a partir de agora  o/

Ao final, hora do feedback em relação a nossos temas e metas, primeiro sobre fundamentos e oportunidades de mercado e técnicas, segundo com a prática do jogo para resolução de desafios propostos pelos próprios grupos, terceiro a proposta prática de GC com o Toolbox Wall e por fim o core deste workshop através das 10 disciplinas organizacionais – quatro essenciais, humanas, que oferecem substrato para a constituição de um ecossistema ágil, além das outras seis pragmáticas com prismas e técnicas específicos para um trabalho eficaz e eficiente.

image_2b3ba484-f4e4-4f28-849d-f13a1c8fdb9a20190324_080826

55505689_10217695727160433_4305180182769041408_o

Sempre bons feedbacks, desde a estrutura, organização, conteúdo e especialmente a interação N x M, formato que descentraliza e deixa muito mais rico os exercícios práticos, quer seja o jogo com suas cartas, o mural com sua técnica colaborativa ou os 10 exercícios realizados a cada disciplina organizacional apresentada.

Nada é por acaso, cada peça neste xadrez tem provocações por tráz do título, mediadores e moderadores em seus 360°, mas o cerne sempre é gerar valor, converter para resultados em equidade, desde organizações exponenciais, MUndo.VUCA, Digital Transformation, Design Thinking, óbviamente Agile, mas cada um e outros prismas sob aspectos que usualmente não são debatidos, não estão nas palestras e treinamentos certificados usuais que só falam da parte glamourosa.

Muita, mas muita mesmo, interação com um resultado invertido, interações em técnicas em que através do debate com outros nos conhecemos mais e mais. Debatemos o tempo todo custo-benefício, oportunidade-conversão, mitos-verdades, o quanto o mercado vende a casquinha mais por motivações financeiras que valorosas ao cliente, distorcendo teorias e fatos, em um mercado que movimenta bilhões em cursos, certificações e consultorias.

O ponto não é discutir o Agile Business, mas o discernimento e isenção pessoal, profissional e organizacional em buscar o que é melhor para si sem se deixar influenciar mais pela retórica publicitária, palestras e eventos que por fatos, sempre baseados não pelo método, técnica e condição inicial, mas pelo PDCL, apredizados e evolução que nos permite evoluir além de qualquer destes métodos e certificações para aquilo que mais gera transparência, colaboração, equidade e valor.

Para encerrar de forma descontraída … o vídeo do jogo Desafio Toolbox 360° pra vocês:

 

0

Diferentes alegorias para Débito Técnico

|

Em meio a um debate sobre Débito Técnico no curso de PSPO no TecnoPUC neste mês de Dez/2018, o Alejandro Olchik da Ionatec compartilhou uma alegoria categórica que merece estar aqui registrada no blog junto a outras que já compartilhei para ilustrar Débito Técnico.

1. Alejandro Olchik e a alegoria do Restaurante

Débito técnico equivale a um restaurante optar por ser mais “ágil” abrindo mão de perder tempo em lavar a louça que suja na cozinha e durante o atendimento, vai chegar uma hora em que não terá mais loça para fazer os pratois ou atender os clientes.

Se não tomar o cuidado de manter a cozinha, louça e instalações limpas, esta decisão oportunista começará a gerar problemas de forma cumulativa e chegará uma hora em que sua operação será paralisada porque de tanto acumular chega-se à inflexão.

2. Ward Cunningan e a alegoria do empréstimo bancário

Ward Cunningham apresentou em 1992 uma metáfora onde o débito técnico de um projeto é como se endividar, decisão que pode acelerar o desenvolvimento e entregas em determinados momentos, mas que deve ser seguido de resgates e quitação.

Sem executar os devidos refatoramentos para reduzir o endividamento, podemos perder o controle e esta dívida não mitigada pode acumular, dívida sobre dívida, colocando em risco todo o projeto.

3. Martin Fowler e seu canvas do Débito Técnico

Eu tenho utilizado uma canvas de mapeamento e planejamento de riscos, quando sob controle é o mesmo canvas – Probabilidade x Impacto. Mas Martin Fowler propõe uma nova perspectiva visual – Domínio (conhecimento prévio) x Risco (prudência).

Fowler propôs um canvas para diagnosticar débito técnico que busca explicitar os fundamentos ou explicações racionais acordadas que o originam, explicitando ser aconteceu(rá) por pressa ou conveniência, um risco calculado ou desconhecido.

4. Neal Ford e a alegoria da Dietzler’s Law

Vale a pena citar Neal Ford da TW, keynote no primeiro dia do Agile Brazil de 2012, ele diz que nós temos 2 usuários, um visível que se beneficia do software que vamos construir e um usuário oculto, que são os próximos profissionais que irão dar continuidade e manutenção futura no software que construímos.

Ele provocou uma reflexão sobre as distrações das abstrações, como a Dietzler’s law sobre o paradoxo de soluções que abstraem e facilitam a construção de uma solução, agilizando resultados iniciais, mas que podem tornar o projeto inviável na reta final, quando exigir especialização ou flexibilidade do framework inicialmente abençoado. Exemplificou alguns que ajudam nos primeiros 80%, dificulta nos 10% seguintes e inviabiliza nos últimos 10%.

5. Uncle Bob e a primazia do Refactoring

Uncle Bob afirma que código de má qualidade NÃO é dívida técnica, a premissa para dívida técnica é uma decisão calculada, uma estratégia não desejável e não sustentável, mas que gera valor antecipado, garantindo uma entrega importante para o cliente, mas sujeito a refactoring.

Este conceito está ligado a boas práticas de engenharia relacionadas à XP (Extreme Programming), a refatoração, ação recomendada como parte importante do processo de desenvolvimento, de forma a ter-se uma visão evolutiva contínua do software.

6. As 8 leis de Lehman (’70)

O conceito de evolução contínua e “refatoração” não é novo, nos anos 70 haviam as 8 leis da evolução de software de Meir Lehman. Com uma abordagem técnica, por 30 anos a Lei de Lehman esteve para o Software do século XX assim como a Lei de Moore esteve para o hardware.

A lei #2 tratava da complexidade crescente e afirmava que se não forem tomadas medidas para reduzir a complexidade do software conforme ele é alterado sua complexidade irá aumentar progressivamente. Deve haver um esforço para reduzir a complexidade final de um sistema enquanto este recebe alterações.

E-Type é um conceito ou categorização proposta por Lehman que caracteriza sistemas que resolvem ou contribuem com um desafio do mundo real, desta forma, sua evolução precisa ser orgânica, conseqüência direta de existir em um mundo real e dinâmico, mutável, evolutivo.

Acordos e estratégias para o Débito Técnico

Débitos técnicos devem ser mapeados e uma estratégia deve ser estabelecida pelo Time Scrum para mitigá-lo permanentemente, eventualmente incorporando-o ao product backlog, sendo reduzido dentro do fator de ajuste ou reserva técnica.

Algumas equipes, após alguns sprints e primeiras entregas, combinam que a cada novo sprint será incluído algo de refactoring, como história ou ocupando um % dedicado a sustentação (reserva técnica).

Alguns desenvolvedores reclamam muito do débito técnico, mas é para ser uma estratégia envolvendo entrega + refactoring, cabe ao time manter explícito em um canvas, mapa ou categorizado no product backlog restante.

Já vi times com uma enorme lista de débito técnico, mas aí a primeira pergunta não é como reduzí-lo, mas porque ele existe, para que serviu plannings, reviews e retrospectivas se esta dívida foi-se acumulando tanto.

Um dos soft skills mais relevantes para um time ágil é a arte da negociação, do poder de argumentação, base para a auto-organização. Afinal, se temos problemas e não sabemos explicá-los, dimensioná-los ou priorizá-los … a culpa não é dos outros.

0

EBM – Evidence Based Management Guide

|

O modelo de EBM, Evidence Based Management Guide ou gerenciamento baseado em evidências em português, é uma estrutura proposta pela SCRUM.ORG e Ken Schwaber não só para orientação, mas também oferece uma plataforma que gera estatísticas relacionadas a métricas de equipes, produtos e projetos ágeis.

EBM – Evidence Based Management Guide – Como melhorar continuamente os resultados de negócios, medindo o valor e usando o gerenciamento empírico.

O fundamento é que a inspeção frequente dos resultados apóia a melhoria contínua, a tomada de decisão focada em aprendizados, não só para a melhorias da eficiência operacional, mas para melhorar sua capacidade de criar valor para clientes e stakeholders.

A EBM analisa métricas e indicadores em 4 áreas de valor-chave, selecionadas caso-a-caso de acordo com a organização, todas contribuindo para a melhor percepção possíuvel e potencialização dos melhores resultados de forma iterativo-incremental-articulada.

  • Valor corrente – Mede o valor entregue ao cliente ou usuário hoje;
  • Valor Não Realizado – Mede o valor que poderia ser realizado atendendo a todas as necessidades potenciais do cliente ou usuário;
  • Capacidade de Inovar – Mede a capacidade de fornecer um novo recurso que pode atender melhor a necessidade de um cliente ou usuário;
  • “Time to Market” – Mede a capacidade de fornecer rapidamente novas capacidades, serviços ou produtos.

O objetivo é valorizar a transparência, inspeção e adaptação a partir de métricas para esclarecer a capacidade de uma organização e suas práticas de entrega de produtos. Melhoria contínua não é uma opção, é a base do Agile, ciclos consistentes de construção, aprendizado, melhoria.

A provocação é muito oportuna, há métricas de projeto e de produto, no curso de PSPO com o Alexandre Mac Fadden fica claro a percepção de que há métricas mais influenciáveis (cycle e lead time, velocidade) e aquelas menos influenciáveis (receita, acessos, downloads), categóricas.

Vale a pena baixar o manual, ler com atenção e processar as informações com atenção:

https://scrumorg-website-prod.s3.amazonaws.com/drupal/2018-09/EBM_Guide%20September%202018.pdf

0

Dinâmicas para ressignificar nossa percepção de time

|

Quer um roteiro simples e muito efetivo para sua equipe esclarecer quem somos, porque existimos, o que fazemos, qual a importância, como fazemos, etc? Os artefatos resultantes são muito importantes de início, mas desapegamos deles com o tempo a medida que evoluímos e crescemos como um time de alta performance.

Conforme a famosa Curva de Tuckman – Forming, Storming, Norming, Performing e um dia Adjourning – iniciamos por alinhamentos, que nos permita experienciar, hora acertando, errando, aprendendo e melhorando, passando assim por um período de storming até que estabeleçamos um bom padrão de interação e resultados.

Importante alinhar desde o início que nosso objetivo é debater e modelar uma primeira versão em uma timeboxe que pode ser de uma manhã, de 2,5 a 3,5 horas, desta forma questões mais polêmicas podem ser combinadas como um MVP, pois o todo deverá ir evoluindo e melhorando com o passar do tempo.

1. Quebra-gelo – Conforme o perfil do time e a janela de tempo podemos escolher um quebra-gelo rápido, como crachá para montar um quadro de identidade, sucata para fazer um brasão ou bandeira do time, um moodboard com nomes, talentos e propósito do time ou mural com spots de jogos e dinâmicas que o time realiza;

2. “Briefing” – É muito importante uma abertura em que a liderança, um diretor ou gerente, fale sobre histórico, sua percepção e confiança no time. Esse início ajuda a mitigar eventuais birras e disputas internas, oferecendo uma percepção de que a empresa aposta em cada um e no conjunto para atingir os resultados desejados;

3. 5w2h – Um aquecimento muito bom é cada um escrever em postits perguntas que lhe inquietam ou acreditam importantes a serem respondidas ao final. Eu ofereço um bloco de postits grandes a cada um para que escrevam perguntas que deseja verem respondidas nesta reunião, para então clusterizá-las na parede;

4. Role Model Canvas – Uso uma adaptação deste canvas para discutir quem somos, desde missão, restrições, parceiros, informações, ferramentas e cenários (fluxos). Tenho usado este Canvas para realizar este brainstorming, suas células oferecem orientação para idear, debater e convergir os temas mais importantes;

5. Próximos passos – Ao final, sempre é importante rever a essência do que foi discutido e materializado, ver no 5w2h se tudo foi endereçado, rever o resultado do Canvas, construindo um To Do List com os próximos passos e endereçamentos de forma que alguns, cada um e todos tenham metas até o próximo encontro do time.

39982292_2063271203725819_8246384165197447168_n

Role Model Canvas

Quanto ao Canvas, não o uso de forma literal, o adaptei a minha necessidade, mas mantive o mérito ao autor. O reinterpretei visualmente de forma a privilegiar o que é para nós mais importante (cenários), por isso reorganizei e propus uma abordagem dirigida para preenchimento conforme segue, ultimando com nossos fluxos de trabalho:

1º. Missão, antes de mais nada, o que é esperado, resultados esperados, porque de sua existência;
2º. Restrições conhecidas, as principais, tendo surgido algo quanto a alçada, budget, equipe, dependências;
3º. Parcerias essenciais, internas ou externas com quem a área ou processo ou programa conta ou depende;
4º. Informação que lhes são cobradas, métricas, metas, indicadores e quem as solicita ou exige;
5º. Ferramentas, de forma a deixar claro quais são e eventual contextualização;
6º. Trabalho, principais jornadas, procedimentos, com selos de valor, oportunidade e prioridade.

A tempo, o original é alemão e um pouco diferente, com outro fechamento (link):

0

Problem Pitch para empatia, entendimento e solução

|

Uma espécie de notação para estruturar a declaração de problemas, assim como uma User Stories para necessidades do cliente. Segundo seus criadores, é possível gerar maior assertividade se ao declararmos um problema usarmos arquétipos: <Papel> <Emoção> <Ação> <Motivo>.

  • Papel – “Como integrante de um time ágil,”
  • Emoção – “fico perdido e chateado,”
  • Ação – “quando repriorizam algo”
  • Motivo – “sem debater o porque da mudança, benefícios e ônus”.

Assim como em uma User Story, a notação padronizada nos oferece a disseminação de uma técnica que colabora para uma comunicação posicional mais assertiva sobre problemas e oportunidades, para então priorizá-las com objetividade. A seguir uma apresentação com sugestão de uso:

Assim como o Learning Canvas e o Managing Dojo dos mesmos autores, o Pimentel propôs usar o conceito como base para uma técnica para resolução de problemas, pautando primeiro o passado (problema), para estabelecer o futuro (resultado esperado) e só então debruçar-se no meio, por plano(s) de ação (hipóteses).

Na apresentação tem tempos e formato sugeridos, eu uso de diferentes formas, o aspecto original desta técnica é a construção do “problem pitch”, de resto segue a linha de várias outras técnicas de brainstorming para resolução de problemas ou aproveitamento de oportunidades.

Por exemplo, assim como outros tantos para debate e resolução de problemas com foco em entendimento, empatia e planos de ação, o quadro abaixo é uma opção:

0

Jogo do Quebra-Cabeças quebrado

|

Um jogo clássico para desenvolvimento de times, com boas pitadas de negociação e liderança, vários grupos na sala precisarão montar diferentes quebra-cabeças, mas ao receberem o seu material perceberão que lhes faltam algumas peças, ao mesmo tempo que sobram outras que aparentemente são de outros grupos.

  • Divida seu time em grupos de 3 ou 4 integrantes;
  • Explique que cada equipe é uma empresa autônoma;
  • A primeira equipe a concluir ganha, pois é uma competição;
  • Entregue uma caixa pequena de quebra-cabeça, diferente para cada um (certifique-se que antes de entregar sejam misturadas algumas peças, de forma que nenhum deles possa ser formado sem destrocar com pelo menos dois dos outros grupos);
  • Ofereça 5 minutos, pedindo que eventuais negociações devem ser feitas time-a-time e não entre todos na sala;

Já participei duas vezes distintas em treinamentos de lideranças na década de 80 e 90, assim como com a de Jenga com um dos integrantes de olhos vendados e a do barril e cordas em grande escala.

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.