Arquivo da tag: transparência

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.

1

As 10 disciplinas organizacionais básicas

|

Comecei a disseminar de forma estruturada a compilação do meu livro TOOLBOX 360° em 2015, lancei o jogo DESAFIO TOOLBOX em 2016, a técnica TOOLBOX WALL em 2017 e finalmente um workshop baseado no jogo em 2018, que foi evoluindo para um baralho com 115 técnicas e boas práticas.

Durante o transcorrer desta estrada foi preciso diferenciar a executivos, gestores e profissionais envolvidos quais seriam as disciplinas envolvidas, já que a angústia sempre era o fato de existirem centenas de métodos, frameworks, técnicas e boas práticas … aos poucos estabeleci 10 delas.

As 10 disciplinas organizacionais por mim propostas foram divididas em 4 disciplinas essenciais – Pessoas, Equipes, Lideranças e Conexões – e 6 disciplinas pragmáticas – Estratégia, Modelagem, Validação, Planejamento, Engenharia e Desafios.

Não tem nada a ver com polarização ou discução sobre qual o método, framework ou corpo de conhecimento ideal, mas ser preciso conhecer ao maior número possível deles, pontos fortes e fracos, especialmente complementares, caso-a-caso, conforme cultura, contexto e pessoas.

Pela visão poética do Pequeno Príncipe, do ócio criativo proposto pelo sociólogo italiano Domenico de Masi, passando por desenvolvimento pessoal, carreira, desenvolvendo projetos e operações, produtos e serviços, uma provocação à frequente miopia organizacional ao focar apenas em uma delas.

Por exemplo, materializando este sincretismo, eu mesmo publiquei alguns livros e ebooks ecléticos sobre SCRUM, Toolbox, Team Building Games, todos com reflexões sobre modelos e teorias, muitas oriundas da filosofia, psicologia, sociologia, ciências sociais, um deles só sobre isso – “Sobre os Ombros de Gigantes!”.

Tudo parte de um modelo mental iterativo-incremental-articulado, um passo de cada vez, com foco naquilo que é mais relevante e voloroso, eliminando ou mitigando todo tipo de desperdício. Isto exige empatia, sinergia e protagonismo, individual e coletivo em seu sentido mais amplo.

As essenciais refletem e provocam a necessidade da mudança pessoal, coletiva, na relação líder-liderados e principalmente na relação entre todos os envolvidos, gerando conexões fortes lastreadas em metas e objetivos comuns ou complementares, convergentes ou coopetidos (*).

(*) “Coopetição é uma estratégia de negócios baseada na Teoria dos Jogos, combinando cooperação e competição, com ganhos percebidos a todos os envolvido”.

As 4 disciplinas que eu batisei de “essenciais”, dizem respeito a base cultural, pessoas e suas relações, desde aspectos de carreira (proteana), passando por equipes (auto-organizadas), lideranças (management 3.0) e as conexões espontâneas, induzidas ou orquestradas.

Não adianta debater metodologias sem antes refletir sobre paradigmas de valores pessoais e coletivos, desenvolvimento de carreira, nossos sonhos e seus reflexos comportamentais, preferencialmente sinérgicos às metas e objetivos organizacionais – Pessoas, Equipes, Lideranças e Conexões:

Nas 6 disciplinas que batisei de pragmáticas, complementares e consequentes às anteriores, estabelece-se a necessidade de alinhamento em seus 360°, desde o mercado, empresa, missão, visão, objetivos, de forma a gerar resultados valorosos em equidade a todos os envolvidos.

O foco aqui é o permanente ajuste do próprio foco, usando de empatia e sinergia, na construção de processos fluidos onde o protagonismo é compartilhado em 360° e constantemente redirecionado à melhoria contínua – Estratégia, Modelagem, Validação, Planejamento, Engenharia e Desafios.

Cada uma destas disciplinas possui dezenas de oportunidades, algumas fundamentais, por vezes complementares, outras divergentes, mas ao todo são centenas de  boas práticas para desenvolvê-las a bom termo. Este substrato garantirá que nossas escolhas não sejam casuais, mas uma opção comparativa e depois evolutiva.

Human Thinking – Das 10 disciplinas básicas de uma organização, quatro delas são essenciais a qualquer objetivo e ao seu sucesso, dizem respeito à pessoas e suas relações, outras seis são mais pragmáticas, relativas a projetos e operações, produtos e serviços, exploitation e exploration. Em uma visão holística, todas são igualmente relevantes, mas em uma visão sustentável e exponencial, pessoas são a base

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

A “nova escola” alemã em jogos de tabuleiro

|

Sempre curti jogos, sem nunca dedicar tempo excessivo a eles é verdade, mas a cada oportunidade eu me dedicava a planejar e preparar para que tudo desse certo – local, jogos adequados à idade da galerinha, atraentes, variados, divertidos, tinha que providenciar material, preparação e facilitação.

Em 2005 fiz uma compilação de JOGOS CLÁSSICOS, de rua, papel, cartas e muitos tabuleiros. Na época achei relevante compila-los em um livreto para usar offline, em qualquer lugar, e distribuir para lobinhos e escoteiros … dos 500 livrinhos, restaram uns 10 que guardei de recordação.

Em 2015 lancei o livro JOGOS 360° com foco em Team Building Games – Icebreakers, warm ups e Agile Games – quase uma centena de jogos para mobilizar equipes, grupos, alunos e pessoas a debaterem assuntos relevantes – conhecimento, pessoas, equipes, processo e ambiente – https://jorgeaudy.com/jogos-360o/.

Não sou um especialista em jogos, mas tenho alguma prática, desde a década de 90 usava em mini-gincanas nos aniversários infantis da família e hoje os compartilho em workshops de Team Building Games. Sempre criei variações e já criei mais de um autoral, recentemente o Desafio Toolbox 360°.

A “nova escola” alemã de tabuleiros (anos ’90)

Eurogames ou “Nova Escola” alemã de jogos de tabuleiro é um estilo surgido nos anos 90 na alemanha, que se disseminou rapidamente pela Europa e ganhou o mundo com jogos de regras simples, fáceis de entender e jogar, privilegiando a interação e interesse de todos até o fim.

* Mantenha regras simples, privilegiando a interação – evite regras complexas, para que qualquer um possa rapidamente entender e jogar, depois a cada jogada ir evoluindo e melhorando;
* Há competição, mas preferencialmente indireta – evite regras em que um jogador elimina o outro, gere objetivos construtivos em que mesmo competitivo a meta seja ganhar e não “competir”;
* Todos interessados e participantes até o fim – evite regras em que os jogadores sejam eliminados precocemente ou torne seus objetivos inatingíveis e assim percam o interesse no jogo;
* Tempo limitado e regras instigantes – evite regras que inviabilizem um jogo divertido e instigante em menos de uma hora, há sugestões que um jogo criativo de 30 minutos é melhor que 4 horas;
* Mitigar o fator sorte (dados|sorteio) – pode incluir fatores de sorte como jogar dados ou retirar cartas, mas o imponderável não pode subjugar completamente uma boa estratégia no jogo;
* Privilegiar a tomada de decisão – dentro do possível cada jogador deve sentir-se instigado a criar estratégias e mudá-las a medida que o jogo avança, tentando mudar os rumos e resultados.

São considerados ícone deste pradigma o jogo Catan, Carcassonne, Ticket to Ride, Puerto Rico, Zombicide, 7 wonders, Dixit, entre muitos outros. Nem melhores nem piores que outros jogos, mas incentivando todos a objetivos passíveis de serem atingidos em um curto espaço de tempo, de forma instigante.

Desenvolvimento de Jogos

Escolher jogos, adaptá-los ou mesmo mudá-los para adequarem-se ainda mais as características do grupo e objetivos é apaixonante, uma atividade divertida por natureza, ainda mais se houver uma boa parceria. A partir dela, seguimos um processo mais estruturado e técnico ou empírico e aleatório, não importa muito.

Mas, pode crer que as mesmas técnicas dos processos criativos de sucesso são aplicadas a qualquer tipo de oportunidade, projeto, operação … são centenas de opções conforme estratégia, negócio, pessoas, contexto e objetivos. Mas, antes de começar, sugiro alguns pontos de atenção:

  • É mais difícil se você não gosta e não joga  😦
  • Quando jogar, discuta os mecanismos com a galera;
  • Exercite pensando algumas mudanças em jogos existentes;
  • Todo jogo tem um objetivo, de pedagógicos a simples diversão;
  • Feito é melhor que perfeito, use sucata e crie uma versão inicial;
  • Realize play tests, convide amigos e colegas, peça feedbacks.

Pense em técnicas oriundas do Lean Startup, nos quatro passos para a Epifania, Design Thinking, com os canvas para modelagem de games e para gamification, business, value proposition e empatia, dinâmicas para brainstorming, criatividade, inovação e empreendedorismo.

Você pode criar um jogo sozinho, like lobo solitário, mas é muito mais divertido e produtivo se tiver parceiros para trocar ideias, prototipação e validação … as vezes não é fácil engajar alguém porque dá muuuuuito trabalho, paciência e perceverança são tão importantes quanto a paixão.

Desafio Toolbox 360°

O jogo que criei e batizei de Desafio Toolbox é um exemplo de mudanças a cada play test, buscando equilíbrio na usabilidade, inicialmente havia um dado, fichas, competição, regras bem sofisticadas que foram simplificando enquanto eu focava mais nas técnicas do baralho e no desafio que na dinâmica.

Desde o início queria algo atraente, divertido, instigante, mas valorizando o pedagógico, seguindo as premissas da nova escola alemã dos jogos de tabuleiros – regras simples, muita interação, competição indireta, todos juntos, rápido, menos sorte ao azar e mais estratégia, com tomada de decisão e estratégia.

Exemplo, um jogo do zero contendo desafio, estratégia, tabuleiro e baralho com foco em debate e aprendizado: https://jorgeaudy.com/desafio-toolbox/

0

Pipeline como gestão visual

|

Esse termo é utilizado em variados contextos, na minha adolescência o usávamos ao discutir sobre Surf, olhando as fotos da revista Fluir, comparando condições do mar com os míticos tubos rápidos, longos e secos, estilosos de Pipeline.

Entretanto, pipeline pode ser uma ferramenta que mostre o fluxo de um processo relevante do cotidiano de áreas e profissionais. Essa abordagem permite a fácil identificação, análise e ações em relação ao andamento, etapas, fluindo em relação ao nosso objetivo.

No RH, por exemplo, temos o pipeline de contratação, é possível explicitarmos em etapas cada passo desde a abertura, divulgação, recepção, avaliação, entrevistas, decisão, documentação, efetivação e integração.

Em vendas, temos análise de mercado, contato, visita, proposta, decisão, minuta, contrato, assinatura, encaminhamento, e assim como no RH, reproduzimos na parede uma visão tática de nosso trabalho.

Outras áreas, como Planejamento, Contratos, Consultoria, Marketing, Eventos, … se beneficiam ao assumir uma abordagem ágil ao materializarem em um quadro sua estratégia, tática e execução. Se falar Kanban eles dizem que não é para eles, mas se falar Pipeline, rola! \o/

Como construir um Pipeline Visual?

Lembre-se que feito é melhor que perfeito, seja ágil, iterativo-incremental-articulado, inicie rapidamente e evolua a cada aprendizado ou retrospectiva.

1. Aquecendo sinapses e conexões – Comece por uma boa técnica sobre “quem nós somos”, “missão”, “o que fazemos”, “como trabalhamos”, se utilizando de alguma das técnicas já compartilhadas e disponíveis no nosso Toolbox, como SWOT, É|Não É, Role Model Canvas, etc;

2. Mapeie seu fluxo de trabalho, foque naquele que queremos modelar no pipeline, como vagas até contratações no RH, como prospects até contratos em vendas, podendo usar Personas, Jornadas, Storytelling, Fluxos de valor, etc;

3. Faça uma checagem do fluxo a luz de passos adicionais de valor significativos a serem explicitados na alçada de “clientes”, parceiros ou “fornecedores”. Isso é importante para não olharmos só para dentro, mas ao fluxo de forma holística;

4. Desenvolva em cada uma de suas etapa mapeadas buscando as tarefas executadas em sua operação, isto permitirá eventualmente não só confirmar o fluxo e a divisão em etapas como alinhar um certo padrão formal ou informal de tarefas x etapas;

5. É muito significativo tentarmos materializar conceitos de WIP (work in progress), tempos médios esperados, baseados em histórico, e Throughput (número de entregas por período) … o que nos oferece cada vez maior auto-conhecimento de nossa capacidade e tática;

6. Registre lições aprendidas em uma linha própria, normalmente a última em destaque, registrando riscos e oportunidades, pontos de atenção. Está alinhado a proposta de regras explícitas do Kanban e ajudarão muito no dia-a-dia;

7. Desde o início explicite suas metas e indicadores, assim o quadro terá um forte apelo a ação, convergência, proporcionando boas reuniões diárias e semanais de alinhamento e geração de micro-planos de ações para maximização de resultados.

Parece muita informação ou em um espaço tão limitado, mas é apenas o caso de usar bom senso e evoluir (Kaizen) permanentemente a cada aprendizado, na prática é como dirigir, no começo parece difícil, mas depois abstraímos e nem percebemos o freio, pisca, acelerador, etc.

0

Tempos líquidos e intempérie exigem de nós um barco e um time ágil

|

O sociólogo polonês Zygmunt Bauman, propôs o conceito de “modernidade líquida” porque o futuro muda permanentemente, no entendimento de um futuro líquido, continuamente mutável, impõe vivermos o agora, termos um plano, fazer o nosso melhor a cada passo, mas ajustando a trajetória.

O livro “Modernidade Líquida” de Bauman é assim descrito: “A modernidade imediata é leve, líquida, fluida, e infinitamente mais dinâmica que a modernidade sólida que suplantou. A passagem de uma a outra acarretou profundas mudanças em todos os aspectos da vida humana. Zygmunt Bauman esclarece como se deu essa transição e nos auxilia a repensar os conceitos e esquemas cognitivos usados para descrever a experiência individual humana e sua história conjunta. Modernidade líquida complementa e conclui a análise realizada pelo autor em Globalização: as conseqüências humanas e Em busca da política. Juntos, esses três volumes formam uma análise brilhante das condições cambiantes da vida social e política.”

Por outro lado, em artigo de 1995, dois signatários do manifesto ágil publicaram “Scrum And The Perfect Storm”, refletindo sobre as desventuras do barco Andrea Gail, diferenciando confiar apenas na leitura dos instrumentos (plano e métricas) e a importância de sempre se olhar pela janela do deck.

Antes disto, Takeushi & Nonaka, fonte de inspiração para o Scrum ao citar a analogia ao Rugbi no antológico artigo “The New New Product Development Game” de 1986 na HBR dissertando sobre times auto-organizados em ciclos iterativos-incrementais-articulados.

Somando Bauman e Scrum, vivemos uma realidade fluida, em permanente mudança, que nos exige multi-ajustes de rumo e posicionamento, que nos exige reposicionar nosso barco de acordo com as ondas, o vento, a chuva e a nós mesmos.

O artigo é um marco arqueológico, nos mostra como eles viam o método lá no início, uma pedra de Roseta que precedeu o “Scrum Guide”, sobretudo, percebemos a beleza da verdadeira natureza ágil que o método tem em seu DNA, por ser ele próprio iterativo e evolutivo.

É pedagógico ver o entendimento, visão inicial e o quanto o método amadureceu desde então. Entretanto, passava o recado, veja alguns pontos que pincei do artigo e invista uma horinha para ler o original, vale a pena:

  • Scrum é apenas um compilado de boas prática e bom senso;
  • O mundo corporativo é caótico, com muitas distrações que podem prejudicar o time e o projeto;
  • Na nossa área é comum complicar, sofisticar, intelectualizar, mas simplicidade é bom e melhor;
  • Scrum ajuda os times a focar no que importa, deixando o menos importante aguardando prioridade;
  • Precisamos escolher entre a ficção dos grandes planos, métricas e reports ou realmente nos envolvermos no projeto;
  • O principal ícone do Scrum é a Daily Meeting;
  • No Scrum todos sabem qual o objetivo principal da iteração e quais os objetivos pontuais de cada participante;
  • Scrum incentiva a interação, contra a tendência ao individualismo;
  • O maior benefício é a humanização do desenvolvimento através de comunicação diária, pactos e foco coletivo na meta;
  • Fazer reviews das viagens anteriores para aprendizado e melhorias das próximas é fundamental.

O Product Owner era Product Manager, não declaravam o papel do Scrum Master e as iterações recomendadas tinham 30 dias: