2

Esquizofrenia Ágil frente a um período de estabilização

Nos últimos anos finalmente iniciamos uma caminhada esperada, em que o Agile assume seu papel de alternativa viável em qualquer negócio, projeto ou operação. Cada vez mais valores, princípios e boas práticas deixa de ser algo diferente, algo “novo” a ser pilotado e passa a compôr aToolbox de todas as empresas e profissionais.

A TI Bi-Modal do Gartner tem mais de meia década flexibilizando grandes empresas, o PMBOK Edição 6 e seu Guia de Boas Práticas Ágeis já está no mercado há mais de um ano. Desde 2016 alerto que esse momento chegaria, mesmo assim há um sem número de “agilistas surpreendidos” de calça curta e “sem saber se comportar”.

No post de 2017 sobre quem mexeu no meu queijo eu escrevi – “Em alguns anos ninguém vai perguntar se você é PMBOK ou Agile, eles vão perguntar se você gerencia bem seus projetos, se há desperdício ou sinergia na geração de valor às partes!”

O problema é que muitos agilistas estão viciados com a ribalta de serem reverenciados como singulares e ganham milhões sendo os “cools” e “inovadores”, então não aceitam a realidade que métodos e técnicas são meios, que projeto é projeto e operação é operação. Agile não é um segmento, agile é opção para todos os segmentos.

Frente a realidade do Agile estar acessível a todos, disponíveis e factíveis à maioria, muitos agilistas apelam e NEGAM a essência de que TODOS tem o direito de tentar, experimentar, aprender, melhorar. Preocupados, partem para a NEGAÇÃO de que qualquer agilidade SEM ELES ou DIFERENTE DELES é ERRADA.

Os Lord Beckets do mercado terão que se ajustar ao fato que não estão mais sozinhos, foram sim early adopters, mas isso já é história, agora eles são players e a cada mês entra mais um punhado e o fato deles terem sido early adopters não lhes garante nada, terão que saber trabalhar com concorrência sem negar seus princípios.

um-bom-negocio

É quase NON SENSE quem advoga empirismo, auto-organização, kaizen, pragmatismo, defendendo seu FEUDO, seu QUEIJO, acusando e negando outras tentativas fora de seu alcance, afirmando peremptóriamente o que é melhor para todos, negando que eles mesmos e os seus cases muito erraram até acertar …

Aliás, reduzi a quase zero eventos “puro sangue” Agile, porque me tira do sério tanta maquiagem e lentes, métodos mágicos que tudo resolvem, consultores que atuam em empresas que eu conheço bem e que em palestras omitem o óbvio, o humano, as dificuldades naturais, a resiliência e a variedade de opções.

Os mesmos que abrem seus cursos dizendo que NÃO É BALA DE PRATA, garantem que longe deles não há salvação, que os Agile dos outros são errados e não devem ser tentados, PIOR, a mensagem subliminar é que eles ACREDITAM sim que ELES são a bala de prata, que ELES representam um único método que conseguem fazer acontecer do jeito “certo” os outros são “errados” … Onde está o Agile nessa abordagem?

Desculpa aí, tentar Scrum, Kanban, Lean, XP, SAFe, SoS, DSDM, … patatí ou patatá, é parte da crença que pessoas irão interagir e aos poucos encontrar seu melhor fluxo e dinâmica. Um método serve como acelerador inicial para a mudança de um ancestral mindset WATERFALL para um mais cooperativo, sinérgico, equitativo.

Se agilistas afirmam que as pessoas NÃO podem tentar nada diferente daquilo que elas recomendam, é porque lá no fundo acreditam que elas NÃO possuem inteligência suficiente ou atitude para evoluir e melhorar a partir de suas tentativas. Outra opção é porque ganhavam muito dinheiro com o que faziam e agora estão mexendo no seu queijo!

Fico imaginando o MEDO nesses agilistas que acham que o mundo está repleto de gente que faz coisas diferentes do que ele faz, logo, “erradas” … Ao contrário, quando inicio um trabalho ou curso, a primeira coisa que afirmo é que não mudamos porque fazemos algo errado, mudamos porque o mundo muda, gira, e exige de nós experimentação.

Experimentar novos mindsets, valores, princípios, métodos, frameworks, técnicas e boas práticas é uma coisa mágica, vamos experimentando, aprendendo e somente fazendo isso é que saberemos o que é melhor para nós … porque se ainda não o fizemos, tudo o mais é o que foi bom para os outros, que temos que validar.

Conclusão

Alguns tem que parar de tratar Agile da mesma forma que a criatura Gollum tratava o anel do poder, tá na hora de desapegar, entender que as crenças, valores e princípios de que pessoas são a chave, que auto-organização é a base, experimentação, tentar, errar e acertar, aprender. Concorda? Então deixe de julgar e deixe de ser arrogante ao pensar que a única solução é a SUA, que sem você e seu anel (método) de poder NÃo há agilidade. Pare de falar palavras ao vento sobre pessoas, equipes e empresas praticando Kaizen, porque na frase seguinte você diz que eles não sabem nada e não tem condições de aprender nada a não ser que seja com o SEU método, do SEU jeito, preferencialmente com a $UA consultoria Scrum, Kanban, Lean, XP, SAFe, … Todas são ponto de partida, todas proporcionarão uma construção. Pronto, falei! –

download

0

Planejamento – Quase sempre as preliminares são cruciais

Há alguns anos eu propus e uso de um canvas para pré-inception, entretanto, não é só em software que esta abordagem faz sentido, isso vale para a vida. O canvas em questão é o SCRUM SETUP CANVAS, destinado a materializar, debater ou refletir sobre questões básicas relacionadas ao planejamento de um software corporativo.

Há exceções, reunir um grupo de pessoas para discutir um projeto de software em uma organização pode seguir um viés de inovação tal que não temos nem ideia de qual a tecnologia, quem serão as pessoas envolvidas, metodologia, bem como arquitetura ou plataforma … mas essa não é a regra, nem para tecnologia, nem boas práticas.

Em 95% dos projetos que me envolvo há um domínio e tecnologia implícita, usualmente há uma equipe envolvida, há padrões e limitações. Em sistemas financeiro, de RH, logística, varejo, entre outros, a inovação via de regra está nas histórias, nas características, ergonomia, usabilidade, etc.

A tempo, clique no link para acessar o manual com o canvas em A3 para impressão – https://jorgeaudy.com/manual-ssc-scrum-setup-canvas-ed-5/

A Mayra de Souza Machado incrementou alguns campos adicionais relacionados a outras combinações, como times remotos, ajustado a realidade do ZAP em https://medium.com/guma-rs/alinhamento-teamrules-facilita%C3%A7%C3%A3o-agreements-teams-canvas-acordos-do-time-cee832b65ba3

Nem sempre preencho todos os campos, as vezes alguns campos possuem seu próprio quadro ou canvas, como o Elevator Stetement ou um Mapa de Tecnologia, mas a intenção aqui é registrar o contexto metodológico e tecnológico em que o projeto transcorrerá.

Arquitetura e tecnologia

Um amigo meu defende que não vale a pena perder tempo mapeando a arquitetura e tecnologia no início, diz que isso deve acontecer conforme o projeto anda e decisões vão sendo tomadas, mas a minha experiência em projetos de software é que poderão haver experimentos, mas sempre temos um mapa amplamente conhecido.

Digo isso, porque frameworks, bibliotecas, linguagem, automação, boas práticas e técnicas influenciam em tudo, desde expectativas, estimativas até a aceitação, algumas vezes já prevendo possíveis variações entre MVP’s e Releases. Normalmente é rápido e muito elucidativo a todos os envolvidos – riscos e oportunidades.

Planejamento Estratégico ou Tático

Sempre que posso, saber quem somos é fundamental, já conduzi várias dinâmicas de planejamento estratégico, portfólio, programas, meu primeiro passo sempre é mapear quem são as partes envolvidas, seu dimensionamento e ao que estão dedicados, se possível, com um mapa de dedicação e portfólio.

Eu chamo estas prévias de aquecimento de sinapses, conheço muita gente que acha que ser inovador é partir de uma página em branco, mas estes casos sempre demoram mais para chegar no ponto de largada e com frequência esquecem coisas importantes que inviabilizarão suas conclusões.

O mais surpreendente e positivo em um bom briefing e combinações sobre o contexto em que estaremos planejando algo é que com frequancia não há um consenso fácil e alguns termos precisam ser pactuados, as vezes, alguém tem que ceder ou decidir para que uma só percepção seja estabelecida coletivamente.

Desperdício

Planejar a revelia de quem somos, o que somos, nossas competências e deficiências, é sinônimo de querer não perder tempo alinhando percepções essenciais, expondo conhecimentos e domínios relevantes, normalmente isso é sinônimo de engavetamento, porque na hora de fazer, surgem questões que foram deixadas de lado.

Para qualquer tipo de planejamento, quer estratégico, tático ou técnico, auto-conhecimento e alinhamento de quem somos e quem queremos ser é fundamental, porque gera uma percepção de realidade e desafios, pontos de atenção e viabilidade. O maior valor é o debate, resultando em um pacto em torno de termos de contexto.

Por exemplo, em Design Thinking se diz que um MVP (Minimum Viable Product) é a intersecção entre algo que é Desejável, Factível e Viável. Logo, é de se pressupor ser importante um bom mapeamento e auto-conhecimento para balizar o que é factível e o que é viável, ou pelo menos o que não é e exigirá mais recursos ou tempo.

0

17º Seminário Internacional de GP

JORGE HORÁCIO NICOLÁS AUDY Consultor, DBServer Jorge Audy é consultor sobre métodos ágeis na DBServer, professor na Escola Politécnica da PUCRS, mestre pela Escola de Negócios da PUCRS na linha de pesquisa sobre Gestão da Informação, blogueiro e autor dos livros SCRUM 360º, Toolbox 360° e Jogos 360°. Escoteiro e agilista 24 horas por dia.

INSCREVA-SE! • 18, 19 e 20 de SETEMBRO • 1º LOTE • 30% DE DESCONTO • Saiba mais em: https://goo.gl/PxPy4e

Coisas boas acontecem quando você se envolve com o PMI !!! #gopmisp #17SIGP #pmisp20anos

Algumas fotos de workshops e start de Toolbox Walls:

0

Jogo sobre inclusão – Pizzaiolo

Somos uma grande rede de Pizzarias com um forte cunho de responsabilidade social, por isso temos equipes que contam com alguns pizzaiolos experientes, jovens e alguns deficientes que precisam integrar-se.

Uma adaptação de um jogo escoteiro de inclusão, o jogo consiste da confecção de pedaços de pizzas em nossas unidades para serviço de rodízio, temos vários sabores, como pizza de queijo, brócoli, atum, tomates secos, além de chocolate e também banana.

Peça voluntários ou sorteie alguns que receberão algumas limitações, como uma venda nos olhos (cegos), um fone de ouvido tocando uma música (surdos), uma mordaça (mudo) e uma mão amarrada para trás (limitação física) … fazendo isso de forma divertida e descontraída.

Treinamento

Antes de iniciar o jogo, faremos um treinamento em que um instrutor irá mostrar como se faz cada pedaço de pizza, desde a massa, molho de tomate, recheio, forno e entrega no balcão para que os clientes se sirvam.

Pegue um pedaço de massa fresquinha (recorte um quarto de uma folha A4 na diagonal simulando um pedaço de pizza), despeje o molho de tomate (pintar o pedaço de folha de vermelho), mostre os diferentes recortes para recheio (queijos quadrados, atuns retangulares, tomates redondos, bananas redondinhas, pintados da cor em questão).

Kanban/Fluxo Contínuo

Identifique-se como representante do cliente, deixe que separem os grupos em times de 4 ou 5 integrantes para rodar uma sprint de 3 minutos, ao final dê um feedback quanto a qualidade, tamanho das fatias, cobertura do molho, qualidade e homogeneidade no tamanho e cor dos pedacinhos do recheio.

Dê tempo para uma retrospectiva onde o foco é cada time discutir como melhorar o seu trabalho, esteira, produtividade, qualidade, comunicação, … e peça um planejamento de quantos pedaços cada time de unidade pode se comprometer a fazer, porque limitaremos o número de clientes nos estabelecimentos em função disso.

Orquestração

Rode mais uma ou duas sprint de 3 minutos. Ao final dê sempre seu feedback sobre o que foi produzido e peça que eles façam nova retrospectiva. Aproveite para falar um pouco do modelo Spotify e de CoP’s internas, sobre o papel de lideranças, também sobre reuniões de melhoria contínua transversais, envolvendo todos os times.

Antes do próximo sprint, simule grupos de discussão transversais, onde integrantes de diferentes grupos possam discutir e aprender uns com os outros, em especial se podem equilibrar melhor os times fazendo trocas, para assim manter uma qualidade mínima e cadência padrão em todas as unidades.

Rode mais uma sprint de 3 minutos, repita os ciclos, conforme seu tempo disponível, é possível gerar bons resultados em apenas 5 sprints, consumindo em torno de 45 minutos bastante produtivos, divertidos e com debate não só de equipe, mas de múltiplas equipes com igual objetivo e metas organizacionais.

Conclusões

Não esqueça de que vários participantes terão algum tipo de limitação, visual, auditiva, motora, o que não impede de se divertirem enquanto atingem sua melhor e mais sustentável performance, aproveitando ao máximo o que cada um pode colaborar em suas limitações.

Além de bons insights sobre sprints – planejamento, execução, review e retrospectiva – é legal o debate de que somos mais que nossas tarefas e objetivos, somos organização e temos um compromisso também com compartilhamento de nosso aprendizado, sugerindo alternativas, buscando melhores performances além do nosso umbigo.

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

Jogo da Guerra dos Balões

É um quebra-gelo clássico, que existe com diferentes nomes, mas sempre com garantia de trabalho em equipe, definição de estratégia e adaptação a medida que se desenvolve. A preparação é providenciar balões normais de festa de criança e providenciar um espaço amplo, preferencialmente externo.

Um jogo para lembrar de competições com fair play, pois é responsabilidade de todos manter a adrenalina em um patamar seguro, sustentável, divertido. Jogar querendo ganhar, mas privilegiando uma competição saudável e sem excessos.

  • Separar o grupo em duas equipes;
  • Delimitar o campo de jogo (ex: 4 x 4 metros);
  • Cada participante prende um balão em cada tornozelo;
  • As mãos devem ficar uma segurando a outra nas costas;
  • Com os pés, tentarão estourar os balões dos outros;
  • Ganha a equipe com mais balões ao final do tempo.

Já joguei com poucos jogadores, mas usando um balão em cada pé, mas tanto com um ou dois é muito legal refletir sobre a estratégia de cada um e da sua equipe, que deveria ser uma só mas frequentemente acaba sendo cada um por si e normalmente sem cobertura, tática e colaboração o time perde …

PRINCÍPIOS: Estratégia coletiva, auto-organização, cuidado com os colegas, … mesmo em lados opostos.

DICA: Uma variação é jogar em duplas, abraçados com um dos braços pelas costas um do outro, cada dupla com balões nas pernas de fora, correspondente ao braço que está livre.

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.