Arquivo da tag: metodologia

Duas horas falando sobre Agile Transformation

Mais um bom papo com o pessoal de SP, profissionais de grandes empresas que compareceram no Impact Hub Pinheiros para falar sobre Agile Transformation. A primeira parte tem do início até o Coffee, com muito conteúdo:

A segunda parte tem menos de uma hora, do Coffee até o fim:

Muita interação, uma galera super interessada, um grande prazer ter podido estar mais uma vez em SanPa em meio a gente tão querida, desta vez na nova sede da DB, no Impact Hub Pinheiros, mas a talk foi em frente em uma galeria de arte.

A seguir colei todas as telas da apresentação e na sequência também compartilho um vídeo mostrando o Impact Hub Pinheiros, que em breve terá na área externas food truck, espaço tipo Arena e muito mais. A tempo, porque o fundo de cena do Scooby? Porque Agile Transformation é um grande mistério a ser desvendado, mas tem um porção de assombrações, o monstro de piche e o mineiro 🙂



Fiz um vídeo com a proposta do Impact Hub Pinheiros … é curtinho:

Até a próxima \o/

Desenvolver um novo jogo equivale a escrever um livro

Pode ser um modelo de negócio ou um hobby, em ambos os casos é preciso ter crença naquilo que está fazendo, condição para continuar investindo e evoluindo em versões, bonecos ou play tests. Nada mais iterativo-incremental que livros e jogos … eles não surgem de repente, são fruto de muita interação e validação.

Eu diria que desenvolver um novo jogo é apaixonante quando temos em nós uma motivação lastreada em compartilhar algo em que acreditamos. Não é para ser uma decisão racional, mas fruto de uma construção temporal, algo que vai se desenvolvendo a partir de oportunidades e experimentação.

É semelhante a escrever um livro, pois exige muito tempo, dedicação e investimento. Assim como em um livro, desde a primeira linha até a primeira versão ou edição, passam-se meses de redação e experimentações, investimento, envolvendo várias pessoas, amigos, colegas, familiares, além de fornecedores.

Tanto um quanto o outro envolvem gráficas expressas, trabalho de ilustração, edição, editoração, muitas noites e finais de semana. Nos livros, meu recurso para validação de ideias e apresentação está no blog, enquanto para validar os jogos eu interajo com colegas, clientes, em eventos e comunidades de prática.

WWII – Meu primeiro jogo (World War II)

Um jogo que surgiu em meus treinamentos SCRUM ainda em 2011 enquanto scrum master de uma empresa aqui da região Sul. Um jogo bem simples, inspirado inicialmente no jogo Aviões 2.0 do Steffens e Prikladnicki, mas só consolidou após conhecer o jogo Scrumia de Wangenheim, Savi e Borgatto.

O objetivo era em menos de uma hora, no final de um curso SCRUM para gerenciamento de projetos ágeis, realizar uma prática tão divertida quanto elucidativa quanto a esquecer de entender o problema, individualismo, de focar na quantidade e não na qualidade, falta de comunicação e esquecer do cliente.

Eu entro em sala usando um chapéu verde camuflado estilo Australiano, um apito pendurado que uso para demarcar tempo ou pedir atenção e me identifico como sendo o cliente das equipes de 5 pessoas formadas para o jogo. Meu nome? General Audy, a procura de equipamentos, aviões e barcos militares.

meios-de-transporte

Cada equipe escolhe um facilitador, que irá receber os materiais, ajudará na organização e sempre que necessário para retirar impedimentos. Cada time pode se organizar como queira, para a cada avião, barco ou capacete entregue Ok, ganhar 1K, mas perder 1K para cada não entregue e 2K aos entregues e recusados.

Cada equipe recebe 3 folhas A4 (recicladas) e hidrocores para fazer protótipos, estimar tempos, organizar seu fluxo de trabalho para então fazer uma proposta de quantas unidades de aviões, barcos e capacetes é capaz de me entregar a cada 3 minutos, com 3 iterações previstas. Eles tem 5 minutos para este planejamento;

O plano de cada equipe é apresentado, informando quantas unidades de cada um dos três elementos – barcos, aviões, capacetes – entregarão a cada 3 minutos, sempre seguindo o piloto e o feedback dado pelo cliente (eu). No início de cada iteração eles pegam o número exato de folhas conforme o planejamento e …

Aviões, barcos e capacetes possuem capacidade, requisitos, características que devem ser levadas em consideração. A cada iteração, pegam o material, se organizam, executam, entregam (ou não) e recebem bônus ou penalidades. No fim, Sprint review e retrospectiva, sempre com grandes reflexões e aprendizados.

Bamboo Challenge

Este game foi idealizado para o II Moot InterAmericano em Osório entre 31/12 e 04/01, oferecido aos 1200 jovens escoteiro de países latino-americanos com idade entre 18 e 20 anos. Gostei tanto que acabei adotando, guardando as taquaras, mantendo rolos de sisal em casa, já rodei em diferentes edições de Agile Games do TecnoTalks e do S2B do CI do TecnoPUC.

Um Agile Game diferente, com prototipagem, planejamento de tempo, matéria-prima, responsabilidades e metas, com aquisição do material planejado, distribuição de tarefas, pair para transferência de conhecimento, renegociação, conclusão e venda, com bônus e penalidades, por valor agregado ou falhas.

p1388676700515

Uma vez planejado, a produção acontece em 3 sprints de 15 minutos cada, intercalado com 5 minutos de review, retrospectiva e replanejamento. A cada Sprint as equipes produziam e ao final de cada Sprint apresentavam ao cliente o que conseguiram fazer e finalmente revisavam o planejamento, podendo alterar a altura proposta e se precisariam adquirir mais taquaras e sisal.

Após o final do terceiro Sprint, no caso de atrasos, cada minuto representava uma penalidade. Cada metro planejado e entregue (a partir de 3 metros) recebia bônus. Um Agile Game para espaços abertos, pois a meta é um mastro auto-portante que atinge de 2 a 5 metros de altura, assim como podem cair ou vergar … um jogo que eu adoro aplicar e que simula cada passo de um projeto SCRUM real.

Banco Intergaláctico – ATM ou POS

Este eu construí do zero, a procura de um jogo completo SCRUM para treinar as equipes de uma grande instituição financeira. O mote era realizar o Release Plan após um Project Model Canvas e uma certificação em PCT (papel, cola, tesoura e canetinhas), para executarmos 2 ou 3 sprints construindo o MVP do projeto.

O fundo de cena é um banco intergaláctico querendo colocar ATM’s (caixas automáticos 24H) em cada planeta e asteróide para saldo, saque, pagamento e extrato, na edição na Virada Ágil do Agile Brazil 2016 eu fui com um cosplay do Darth Vader, que era o cliente, dono do banco, querendo se regenerar.

darth-vader-virada-agil-2016-ufpr

Com user stories, prioridades para o cliente e um hardware feito em papelão para os caixas automáticos, adquiridos na China com hardware específico para tela, teclado, saída da impressora e câmera, a serem respeitados em suas dimensões e características, devidamente validados pelas equipes durante o projeto.

As telas e relatórios de extrato e recibo de pagamento são construídas usando papéis de diferentes cores, tesouras, postits, cola e um estojo de canetinhas hidrocôr. Um paiol de oportunidades para experienciar e entender cada um dos princípios ágeis e regras do método SCRUM.

O jogo é um sucesso como exercício prático, quer na versão ATM ou POS, em versões para treinamentos de 8Hrs ou 16Hrs, um pouco mais focados ou mais sofisticado. Os aprendizados são os mesmos do WWII, mas o uso de um protótipo de ATM com telas e relatórios aproximam a galera de algo do seu cotidiano.

caixa-24h

Este jogo é bem mais complexo para o instrutor, porque necessita de muito mais preparação e simulações, inclusive com um pack de user stories, o project model canvas, além do material para o Release Plan e Retrospectivas. Fiz duas rodadas de pilotos e já rodou umas 20 edições no ano de 2016 para diferentes clientes.

Desafio ToolBox 360º

Este é meu xodó no final de 2016, início de 2017, exigindo investimento em várias formas e recursos, mas é uma peça importante na construção de uma proposta diferente para o mercado, que iniciou com o livro ToolBox 360º no final de 2015. Um guia com 70 boas práticas e técnicas reconhecidas em projetos.

A principal motivação foi minha disciplina de Tópicos Especiais em Engenharia de Software, pois durante o semestre rolam alguns games durante as aulas, além do uso de Agile Subway Maps e Mapas de arquitetura e tecnologia. Queria algo ainda mais ilustrativo e pedagógico, este ano de 2017 o usarei pela primeira vez em aula.

A previsão de lançamento está agendado para o Agile Trends 2017 em São Paulo, para o qual terei o apoio da empresa que escolhi trabalhar em Junho/2013 e comecei como consultor em Julho/2014. Desde então, tenho viajado o Brasil ministrando cursos e implantando equipes e projetos SCRUM  \o/

16427225_1380540551998891_3389568428498263358_n

O mote era um jogo que instigasse à galera a conhecer as mais de 70 boas práticas sugeridas no livro e no blog, se utilizando de técnicas de ludificação, com desafios individuais e coletivos, com traços de competição e colaborativos. Cada jogador precisa conhecer cada vez mais as técnicas disponíveis para avançar e ganhar.

O jogo possui duas instâncias, a primeira se utiliza do perímetro do tabuleiro em que a cada rodada do segundo os jogadores avançam com suas fichas para vencer. O segundo se utiliza de cenários/desafios a serem atendidos com as cartas de cada jogador. Cerca de quatro cenários atendidos, um jogador pode ganhar o jogo.

É bem simples e divertido, onde os argumentos de cada jogador, o entendimento de cada desafio e o equilíbrio para encontrar a melhor solução possível a cada rodada com as cartas, fazem os jogadores avançarem com suas fichas pelas mais de 30 posições existentes no perímetro até o seu final.

tabuleiro-evolutivo-dez2016

Agile e democracia não é só a voz da maioria, é mais que isso

Agile tem muito a ver com experimentação e aprendizado, direto ou indireto, de forma que busquemos compreender o que aconteceu a cada ciclo, o que poderia ou deveria ter acontecido, estabelecendo um mindset de melhoria contínua. Com este fim, devemos buscar mais que “maioria”, que mesmo estabelecida, é preciso ouvir, mitigar ou potencializar desafios percebidos pelas minorias.

Não fosse assim, correríamos o risco da ditadura da maioria, acho que inexiste democracia ou agilidade se não houver um senso de corpo que nos mova a sempre tentar entender o outro, gerar empatia, buscar sinergia. Para tanto, além de conhecer a maioria, também é preciso entender e respeitar a minoria. A pena pode ser desperdício, negar a inovação, a disrupção.

Todos nós somos dados a crenças e ideais, ao compreendermos algo como útil, gerador de valor para o atingimento de nossos objetivos, tentamos utilizá-lo de forma melhor possível … tem muito a ver com o que o psicólogo Albert Bandura chamou de Aprendizado Vicariante, desde crianças repetimos aquilo que percebemos como bom e positivo para nós ou a quem queremos bem.

Por isso, lastreamos decisões e ações a nossos princípios, que agem em nossa vida de forma cumulativa e complementar desde a infância, por auto-preservação, bem ao próximo, religião, muitos são escoteiros, praticantes de artes marciais, conheço uma galera que é agilista. A soma disso tudo faz com que assumamos um papel colaborativo, que nos define enquanto seres sociais.

scrum-team-praia

Após entender isso é que agilidade começa a fazer sentido, porque a simples maioria pode ser tão perniciosa ou pior que comando-controle. Por isso os frameworks baseados em Lean iniciam pelo conceito de empatia, derrubando feudos, construindo um senso ampliado de time, liberdade e responsabilidade. É preciso relevar prós e contras, assumir riscos, convergir é mais que decidir!

No berço da democracia, Sócrates e Platão falaram sobre a Tirania da Maioria (oclocracia). Em agilidade, o conceito por trás de um senso ampliado de time, é investir e valorizar o protagonismo de todos. Todo e qualquer grupo humano possui formadores de opinião, que exercem algum tipo de liderança, cabe ao conjunto auto-conhecer-se e gerar decisões, executá-las, discuti-las e aprender.

Ter direito a opinião e feedback, valorizar a argumentação, buscar tomar decisões conscientes, não só pela maioria ou por conveniência, mas por estratégia. Se queremos gerar valor, é preciso ter a responsabilidade de entender seu contexto, que pode e é normal que mude a cada ciclo, a cada entrega, tomada de decisão, time to market, ROI, sustentabilidade, … fosse fácil, todo mundo já faria!

Agilidade é um grande desafio a todos os envolvidos, todos precisam mudar a forma como se relacionam – o cliente tem que participar de fato, o time deve se auto-organizar, as lideranças tem que se reinventar, praticar devops para gerar melhores resultados, todos em conjunto devem gerar mais valor, … tudo isso é mais que imposição ou maioria, porque maioria é a mesma Zona de Conforto!

all-blacks

 

ROI, você está calculando isso errado!

Desculpa ai, mas talvez você esteja calculando ROI errado. Evite usar uma visão restrita a resultados de curtíssimo prazo, não entre no lugar comum de avaliar o ROI apenas contra custos imediatos do projeto, o ônus posterior decorrente da ausência de domínio, qualidade, boa arquitetura, automação, não é acaso do destino, ele foi gerado conscientemente ou fruto do descaso. Softwares são ativos ou passivos, temos dezenas ou centenas deles em uma empresa, que gerarão um grande desperdício para mantê-los ou não.

Na década de 70 do século XX a relevância com os custos recorrentes e o valor agregado por um software já estava embutido nas Leis de Lehman, após 40 anos esta relação ficou ainda mais clara e racional. Se você demorou 6 meses para construir um produto que vai ser usado por 10 anos, é enganação calcular ROI apenas se atendo ao resultado dos 6 meses. Cada linha desnecessária ou de baixa qualidade gera sobre-custos e antecipa sua obsolescência, rasgando dinheiro na forma de mais e mais investimento, equipe, alocação, incidentes, insegurança.

projeto-x-manutencao

O racional de muitas empresas é produzir, quanto mais melhor, se depois gastar o dobro para manter e o triplo para refazer antes do previsto é outra história, o que importa é “seu projeto concluir com aparente sucesso”, “merecer parabéns e uma promoção por ter entregue” … quase ninguém considera ou reflete sobre débito técnico e qualidade-desperdício, no contraste entre o valor real e aparente.

A tempo, importante diferenciar CAPEX (CAPital EXpenditure) relativo a investimento e OPEX (OPerational EXpenditure) relativo a despesas operacionais, muitas empresas acabam dando especial atenção ao investimento para aquisição ou construção (temporário) em detrimento ao custo continuado (recorrente), que poderia ter sido amplamente mitigado, evitado ou melhor planejado.

Princípios e métodos ágeis, iterativo-incrementais-articulados, design thinking, devops, kanban, melhoria contínua, tantos fundamentos e argumentos são utilizados e o maior deles que é o desperdício em uma análise de ROI é muitas vezes esquecido. Como evitar? Lean Business Analysis, Métodos ágeis em projetos Scrum, Kanban para gestão de fluxo, XP para engenharia de software, qualidade e automação, sem esquecer DevOps, etc.

roi

1. Falta de boas práticas ágeis – Elicitação, modelagem, planejamento e execução colaborativas. O quanto não antecipamos riscos e oportunidades, validando e adaptando desde antes de construir, mitigando desperdícios?

2. Transição eterna – você inclui no cálculo de ROI daquele projeto que foi um “sucesso”, a necessidade de uma equipe de atendimento rápido para corrigir ou ajustar problemas em produção … que poderia ter sido evitado ou reduzido?

3. Retrabalho – Você calcula o tempo de vida do produto construído versus o custo de ter que refazer partes ou todo a cada tanto porque inviabiliza mantê-lo devido a tantos remendos pela falta de boas práticas de engenharia de software?

4. Não automação – Pesa no cálculo de ROI a falta de testes automatizados, inexistência de testes de regressão, de boas práticas de aceitação que pesarão contra a sua usabilidade, integridade e imagem futura junto ao mercado e clientes?

5. Insustentável – Você inclui no ROI o ônus de ter dito que a equipe virou semanas sem dormir gerando código feito sob pressão, stressados, cansados e com foco apenas na data, em entregar a qualquer custo (com baixa qualidade)?

6. Inutilidades funcionais – Você inclui no ROI o custo de ter feito requisitos e dados inúteis, que só tornaram o produto mais complexo e inchado, onerando sua evolução, escalabilidade e manutenção?

7. Insatisfação – Você inclui no ROI o turnover e seus desperdícios em eternamente estar treinando novos integrantes, porque acha que isso faz parte e não precisa de um programa de atração e retenção de talentos?

8. Hardware proprietário – Você inclui no ROI o custo de ter silos e feudos, um pedaço na cabeça de cada integrante e área, sem sinergia, investindo só em capital individual, pontos únicos de falha, na síndrome do super-herói?

Não tem mágica, precisamos atrair, valorizar e reter talentos, usar métodos ágeis, boas práticas em engenharia de software, investir no coletivo e senso de pertença, testes automatizados, code review, … Qualidade não é não ter bugs, é construir certo na medida certa, com uma empresa e equipe engajadas e conscientes, porque neste contexto a palavra sustentabilidade ganha outra dimensão e profundidade.

De toda forma, tem cada vez menos Baby Boomers enviando currículos e cada vez mais Millenials, talvez em breve possa faltar talentos querendo trabalhar para empresas que continuem dependentes de workaholics, peças fundamentais para manter códigos “eternamente legados”, onde ninguém assume a responsabilidade pelo futuro, mas ganha méritos por ter apagado mais um incêndio.

 

PMBOK e Agile – Quem mexeu no meu queijo?

O lançamento da 6ª edição do guia PMBOK entrará para a história como um marco, pois traduziu uma postura eclética imposta pelo mercado e profissionais contra o Taboo de que gerenciamento de projetos é uma coisa e métodos ágeis para gerenciamento de projetos, como SCRUM, são outra.

Vaticínio: “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!”

Reflita comigo, o PMI foi criado em 1969, apenas quinze anos depois começaram a pipocar práticas, técnicas e métodos chamados inicialmente de lightwave, batizados de Ágeis em 2001. O artigo seminal do SCRUM foi “The new new product development game” de T&N na Harward Business Review em 1986.

Na minha visão, um grande acelerador desta quebra de barreiras com certeza foi o lançamento dos conceitos de Pace Layered e TI-Bi Modal pelo Gartner, que desde então acelerou a inserção de métodos e práticas ágeis nas grandes empresas e corporações, antes dominadas por processos hierarquizados e preditivos.

Meta: “Atrair e reter talentos, com empatia e sinergia, gerando valor em equidade, de forma que empresa, fornecedor e cliente, tanto quanto seus integrantes, cresçam e melhorem continuamente!”

Convergindo à isso, no início deste século era difícil imaginar grandes eventos do PMI com grandes palestras sobre Agile, mas no início dos anos 10 deste século passei a ver grandes agilistas passarem a frequentar os grandes eventos do PMI, bem como grandes nomes do PMI começarem a se aproximar da comunidade ágil.

Acredito que muito em breve deixará de existir o monopólio dos GP’s ditos tradicionais versus Agilistas, isto ao mesmo tempo é inspirador e curioso, porque estamos falando de cifras na faixa dos bilhões de dólares em cursos oficiais (PMBOK, Scrum Alliance, Scrum Org, etc), certificações e consultorias.

Aos que acreditam que sua metodologia ou processo é sagrado, quase uma religião onde os “outros” ou mudanças no seu Be-a-Ba são profanos, muito em breve terão que mudar suas posturas e atitudes. Haverá sempre espaço para os xiitas, mas o futuro organizacional será iterativo-incremental-articulado, evolutivo, adaptativo.

Foco: “Sentar-se a mesa em uma organização, antecipar e promover mudanças no sentido certo é mais importante que a intensidade e profundidade! Se não pode mudar tudo, faça algo, fazer nada não é opção!”

Muitas empresas e profissionais já perceberam que “mexeram no queijo delas“, negar iniciativas de experimentação de técnicas em qualquer escala é negar os benefícios que eles trazem às pessoas e empresas. Eu acredito que dado o primeiro passo, percebido os primeiros ganhos, a tendência é dar o próximo, um a um.

Quem mexeu no meu queijo?

Em Setembro de 1998 Spencer Johnson lançou o livro “Quem mexeu no meu queijo?” – uma parábola sobre adaptar-se às mudança, pela história de quatro personagens pequeninos acomodados ou pró-ativos em relação ao seu estoque de queijo. Um best seller que discutiu acomodação, adaptação e antecipação.

who-moved-my-cheese-3-638

Lembra um pouco o conceito de exploration x exploitation, escancarando os principais motivos pelo qual muitas empresas líderes de um mercado em determinado momento, faliram após anos comendo queijo, acomodados na sua liderança, vendo o queijo acabar pouco a pouco e não fazendo nada.

Momento: “Vivemos uma era de inovações, oportunidades em meio a crises continentais, profissionais Millenials, revoluções tecnológicas sem precedentes. Pequenas startups com um link concorrendo com corporações!”

Muitos profissionais, assim como empresas, se utilizam de técnicas obsoletas para tentar perpetuar-se de forma sintética, em busca de sobrevida ao seu negócio, mas não trabalhando para reinventar-se, encontrar o próximo estoque de “queijo”, preferem tentar impor, reclamar, culpar, apenas postergando o inevitável.

Especialmente em períodos de crise, a experimentação voluntária ou pressionada na procura de métodos, técnicas e boas práticas que gerem antecipação, pertença e melhores resultados é benéfico a todos, empresa e profissionais. Conquistado os primeiros ganhos, a tendência é retrospectivas trazerem ao natural os próximos.

Defendo que mesmo a empresa não acreditando, se uma equipe praticar o que está ao seu alcance, como daily e ciclos com retrospectivas, só isto já gerará ganhos na redução do stress, aumento da auto-organização, melhorias dos resultados. Se isso for verdade, ao natural quererão experimentar mais e mais.

Bem-vinda a edição 6, a considero um marco em um processo irreversível de convergência metodológica que defendo a anos nos meus posts. Compartilho a seguir um link da PMTECH, um artigo do Mauro Sotille sobre o que muda na edição 6, com um parágrafo em especial sobre “queijos” ágeis:

pmtech

Teço elogios a iniciativa da TI-BiModal do Gartner neste mesmo sentido, de quebrar o gelo, abrir estradas, porque muitas vezes o mais difícil é dar o primeiro passo, perder o medo. Acredito muito em uma frase do Juan Bernabó, keynote no Agile Brazil de 2016 – “Esperemos que as retrospectivas façam seu trabalho!”

TTalks – Keep Calm and Listen to the Scrum Master

A Luisa Audy foi ao Canal esta noite para ilustrar o evento, imagens que compartilho a seguir em três momentos, o da definição dos principais temas, mais desejados, a combinação da técnica Fishbowl e o debate propriamente dito.

Iniciamos do lado de fora do Canal Café, em pequenos grupos discutiu-se quais os temas mais relevantes a serem discutidos, para em seguida agrupar e estabelecer uma lista e escala de prioridades para  a noite. Estávamos em mais de 30 pessoas, os grupos para sugestão de temas foram de 3 a 6 pessoas, na medida em que iam discutindo, foram colando os postits, agrupando e assim definiram-se os temas:

20170208_230307p

A técnica fishbowl para debates em grandes grupos é bem simples e eficiente ao que se propõe, foram cinco cadeiras a frente, quatro iniciaram ocupadas por quem dispôs-se a iniciar o debate pelo primeiro tópico (Papel e atuação do SM). Na medida em que alguém queria também perguntar, responder, argumentar, qualquer um podia sentar-se na quinta cadeira, mas ao sentar-se, um dos quatro que ali já estavam precisa levantar, mantendo uma cadeira das cinco livres:

20170208_230432p

Iniciamos pelo tema do próprio papel e atuação do SM. Discutiu-se muito sobre alçada e envolvimento, o que diz o Scrum Guide, Curva de Tuckman, sobre o modelo de Fluência Ágil do James Shore, as diferentes maturidades de um time, ágil auto-organizado, conflitos ou não com os muitos e variados papéis existentes em empresas de médio-grande porte, como PMO, GP, Gestores e Lideranças. Este foi o tópico mais pegado e ocupou metade do tempo do evento …

Um tema apaixonante, que não tem respostas categóricas, pois o momento de adoção, piloto, rollout, mudança cultural, o quanto cada um dos profissionais envolvidos direta ou indiretamente podem ou não ter entendido os princípios ágeis e o modelo mental proposto mais que métodos e técnicas. Discutiu-se muito as dificuldades relativas a empresas, gestores ou líderes que ainda não se adaptaram ou não acreditam na mudança.

20170208_230452p

O segundo tema começou já eram 20:30 e pautou a questão da mudança, da maturidade, transição, … discutimos sobre estratégias de mudança, de adoção, de rollout, sobre a dedicação do Scrum Master, retornamos a questões sobre atuação, dedicação e viabilidade. Tangenciamos perfis de empresas e profissionais, idealizações e vida real, métodos híbridos e timing para aculturação.

A primeira metade do debate eu gravei com a ajuda da Alice, mas minha bateria acabou e eu me envolvi mais no debate da segunda metade do evento, então fiquei devendo … para amanhã vou tentar ficar mais na logística e cobrir todo o evento. Hoje eu fui disposto a não entrar no debate, mas o tema é bom demais para ficar de fora, ao natural tem muito tempero e pimenta, por isso é tão relevante:

Para o evento sobre o papel de PO de amanhã foram sugeridas algumas melhorias, como provocar a sugestão de temas pela galera já desde hoje na página do evento no Facebook, definir slots de tempo de 10 minutos para check de troca para o próximo tema, permitir que a galera interaja com perguntas ou provocações sem a necessidade de entrar para uma das cadeiras do fishbowl.

preparando

No final da noite tirei uma foto oficial, uma pena que quando percebi alguns já tinham saído, mas deu tempo de pegar a maioria. Muita gente querida e engajada, váááários Ttalkers de carteirinha. Tinha profissionais de várias empresas, muitas do parque e outras tantas de fora. Amanhã tem mais Açaí com morango e granola, para depois rolar um super debate mais pelo aspecto de PO, escopo, User Stories, ROI, senso de time, senso de pertença, e muitos outros etc 🙂

20170208_214933p

O bordão “Errar é Bom!” é uma faca de dois gumes

Viajo pelo Brasil compartilhando o que aprendi sobre a pratica de metodologias ágeis, principalmente sobre o uso consciente de Scrum e Kanban em uma abordagem racional e equânime, satisfatória a todos, para os times, para a empresa, clientes, colaboradores, parceiros, fornecedores.

Por convicção sigo ao máximo preceitos da psicologia positiva, levo fé em abordagens que potencializem a auto-eficácia, sendo politicamente correto, seguindo linguagem não violenta, com crenças e valores ágeis, porque as pessoas sempre tenderão a fazer o seu melhor neste contexto.

Ao ler o manifesto ágil e seus doze princípios, nas bases do Scrum, Kanban, Lean Startup, Design Thinking, desperdícios Lean (Muda, Mura, Muri) e tantos outros, é preciso não se perder na interpretação, pois não é um risco incomum adotar Agile e levantar escaramuças aos princípios Lean e aos da própria agilidade.

o-erro-e-a-pm-ii

Não é um paradoxo, é LEAN e tem a ver com Albert Bandura, com aprendizado vicariante, trabalhamos para errar o necessário ou inevitável, mas aprendendo com nossos erros passados, presentes e com os erros dos outros, desta forma mitigamos o risco de errar e potencializamos os resultados.

Brinco dizendo que não podemos seguir o exemplo da geração Hippie, que contestou uma sociedade altamente regulada e hierárquica com uma abordagem diametralmente oposta que durou muito pouco, pois se rigidez disciplinar é ruim, a liberdade total, com sexo, drogas e rock’n roll também é o ó do borogodó.

A solução para tudo é a busca iterativo-incremental-articulada pelo equilíbrio:

Se apontar erros e caçar culpados é ruim, ficar repetindo o mantra irracional de que errar é bom, pode atrasar as soluções e não ajudar em nada;

Se MS-Project com antecipação de 12 meses de tarefas e responsabilidade é ruim, não planejar nem documentar nada também não é solução;

Se um chefe carrasco é ruim, evitar contato com a liderança tende a ser insano para quem quer ter seu trabalho reconhecido no coletivo e no individual;

Se comunicação violenta, agressiva, unilateral é ruim, manter uma comunicação sem transparência postergará soluções que podem ser urgentes;

Se pressão e exigências desmedidas é ruim, eliminar qualquer pressão é pressupor que os hippies tinham razão – sexo, drogas e rock’n roll são suficientes.

Acho que essa defesa de tese de errar cedo é mal entendida. “Errar é bom” diz respeito a validar hipóteses, a testar o desconhecido, correr riscos calculados, diz respeito a inovação, não diz respeito a erros conhecidos e que poderiam ter sido evitados com um pouco de discussão e antecipação, pois esse é o mindset Lean.

principios-lean

Dentre os três pilares do SCRUM, um deles é o pilar-mor, o da transparência, que deve ser praticado com realismo, positivismo, franqueza e uma boa dose de bom senso e educação. Qualquer informação relevante que seja escondida, que poderia gerar planos de ação e antecipação para mitigar riscos e aproveitar oportunidades é uma ode à cultura da resignação em prol do desperdício.

Não concordo e acho muito perigosa a defesa de tese de “Errar é bom!” sem contextualizar e lembrar as boas práticas. Alguns evitam melindrar as equipes, porque se errar não for bom vão esconder os erros. É como dizer que, para motoristas não terem medo de buracos na estrada resolve-se colocando uma venda nos olhos deles … decididamente, não entendo e não concordo!

vendas-e-buracos

O maior risco de todos é seguirem o mesmo roteiro de George Orwell em Animal Farm, quando os bichos liderados pelos porcos iniciam uma revolução contra o fazendeiro com o bordão de Duas patas é ruim e Quatro patas é bom! … sem entender, não percebem que as coisas pioraram, pois esqueceram os porques!

revolucao-dos-bichos