Arquivo da categoria: Sustentabilidade

0

Do Takt Time do Lean ao Tiki-Taka do Barcelona

|

Os conceitos e fundamentos do Lean sobre fluxo são essenciais para entender métodos ágeis. Tem a ver com a percepção de produtividade e efetividade, evitando a sensação de trabalhar muito e não ter os resultados e reconhecimento desejados. Então vamos falar de Takt Time e cadência  \o/

Takt Time é o tempo dividido pela demanda na indústria Lean, um fundamento essencial ao conceito de sistemas puxados, se for rápido demais gerará stress e estoques intermediários, se for lento demais gerará ociosidade e descompasso, ambos induzindo ao erro e desperdícios.

Cadência é o estabelecimento de um ritmo sustentável e equilibrado entre recursos, pessoas, tempo e produção, com valor e qualidade. O segredo é encontrar um ritmo constante que mantenha o fluxo, desafiador mas possível, seguro mas não pessimista.

SCRUM

Equipes que seguem o método SCRUM são impelidas a trabalhar com conceitos e regras que os induzem ao estabelecimentos de seu Takt Time e cadência a cada projeto, de forma iterativo-incremental-articulada, ajustando conforme avançam e aprendem.

Baseado nesta premissa conceitual eu propus o Scrum Setup Canvas antes do planejamento do Release PLan, de forma a levarmos em consideração os vetores e variáveis que influenciam as estimativas em cadência, validando nossa capacidade a cada sprint.

Os instrumentos oferecidos com sucesso pelo método é o DoR (Definition of Ready) e DoD (Definition of Done), o primeiro estabelece os critérios que permitirão o desenvolvimento de cada história de forma eficiente, o segundo são critérios para considerar cada história pronta para o cliente.

o Dor e DoD estabelecem o ritmo de um time, que proporcionará um compasso estabelecendo mínimo desperdício e alta performance sustentável para entrega contínua de valor ao cliente com a qualidade estabelecida e acordada.

A intenção é estabelecer um ritmo cadenciado entre o DoR e DoD, enquanto os desenvolvedores trabalham no desenvolvimento partindo do DoR das histórias do sprint corrente até seu DoD, colegas trabalham para o estabelecimento do DoR do próximo sprint, orquestrando a evolução.

KANBAN

No kanban temos o conceito de fluxo contínuo, método que utilizo muito para equipes de sustentação. Neste caso, não temos o Release Plan, DoR e DoD como no Scrum, pois trabalha foco naquilo que é mais importante a cada momento, não constituindo sprints, mas continuamente.

Mas o mesmo mecanismo é utilizado de forma diferente, priorizadas as alterações corretivas ou evolutivas o time vai puxando conforme escala e trabalhando de forma a entender, executar e atender, entregando valor e qualidade sem o estabelecimento de demandas para cada duas semanas de trabalho.

Neste caso, ao se utilizar de suas boas práticas, teremos um quadro físico ou virtual com a evolução de status até estar pronto, regras explícitas, estabelecimento de quantidades, monitoramento de fluxo com métricas como lead time, cycle time, throughput, burn down, cumulative flow.

Na prática, a essência do conceito de equipes de alta performance diz mais respeito a cadência coletiva que a produtividade individual, quais as técnicas que nos auxiliam a práxis de comunicação ativa, colaborativa e tomadas de decisão a cada dia em prol de eficácia e eficiência em processo e produto.

TIKI-TAKA

Uma analogia descompromissada com o famoso conceito Tiki-Taka do Barcelona e seleção espanhola, definido como um sistema baseado em posse de bola através de passes curtos utilizando todos os espaços do campo e todos os jogadores, a bola não para, cada jogador sempre com múltiplas opções de passe rápido.

No sistema catalão, também usado pela seleção espanhola, todos os jogadores participam direta ou indiretamente da jogada, movimentando-se de forma a serem uma opção para receber a bola e passar a outro colega, mantendo o ritmo, atenção e colaboração ativos sempre, envolvendo o adversário e, com frequência, vencendo.

CONCLUSÃO

Os desperdícios do Lean dizem respeito a tudo o que possa comprometer nosso Takt Time e cadência de valor, produção apressada com estoques intermediários inúteis e de alto risco, movimentação indesejada, execução defeituosa, foco fora da prioridade a cada momento, tudo isso dinamicamente.

Fazer certo a coisa errada é tão ruim quanto fazer errado a coisa certa, é preciso fazer certo a coisa certa, um passo de cada vez, de forma cadenciada, sempre iterativo-incremental-articulada, com pequenos e contínuos ciclos sustentáveis, projetando, executando, validando e corrigindo.

Não é tão difícil assim, é só começar a andar e a cada ciclo ir experimentando, aprendendo e melhorando, deixando as retrospectivas fazerem seu trabalho. Como disse o Bilbo Bolsseiro, “Você pisa na Estrada, e, se não controlar seus pés, não há como saber até onde você pode ser levado …” \o/

0

A equação CAPEX += OPEX é essencial para bons gestores e equipes

|

Quer na vida, empresa, futebol, política, é preciso entender o valor de trabalhar com equilíbrio entre metas de curto, médio e longo prazos, desdobramentos, ganhos e perdas. O brasileiro trata CAPEX e OPEX em suas empresas da mesma forma que gerencia times de futebol ou política, muitas vezes imediatista, oportunista, pró-geração de factóides.

Não entendam o tom de meus posts como acusatórios, são situações que nos circundam em diferentes graus, o que precisamos as vezes é um balde de água gelada para se propôr a debater com mais realismo as consequências de atos nossos (conscientes ou inconscientes). A equação certa é CAPEX += OPEX, significa CAPEX = CAPEX + OPEX.

CAPEX (expenditure) ~ despesas ou investimentos em bens de capital; despesas de capital; aquisições.

OPEX (operational expenditure) refere-se às despesas operacionais, recorrentes, continuadas.

CAPEX é investimento, aquisição, projeto, mas cada tomada de decisão ali pode aumentar ou diminuir sua OPEX, custo recorrente de operação que muitos geram como a maldição da múmia. Um projeto mal feito, imediatista, enrolada em retalhos, terá que ser mantido com doses maciças de recursos super-dimensionados por anos para fazer frente a tudo o que não foi feito em alguns meses mal geridos de projeto.

Sempre cito paradigma e risco da Teoria da Agência, pois ‘empresa’ não existe, existem CEO, VP’s, diretores, gerentes, profissionais, as vezes inconscientemente com foco em objetivos pessoais ou zona de conforto. Projetos precisam ter no radar uma visão de longo prazo, evitando acordos onde todos se beneficiam, menos a empresa.

Reflexão: Estudos sobre Linha de Produto de SW demonstram um custo inicial para a absorção e qualificação, sendo mais oneroso começar a fazer diferente do que fazer mais do mesmo, até um breakeven, quando então passamos a obter os resultados melhores desejados, cumulativamente, cada vez mais – Vale para muitas técnicas e tecnologias!

lps_figura1

CAPEX e OPEX – ESTUDOS DE CASOS HIPOTÉTICOS

Um projeto de software construído sob muita pressão pode gerar elogios, bonificações e promoções pelo CAPEX, mas com práticas inconsequentes afetando sua OPEX. Um projeto construído com muita pressa, pode ganhar elogios, mesmo com tecnologia inadequada, desde que atenda a necessidade. Tem até casos em que não se documenta de forma mínima, não se automatiza o mínimo, nem qualidade ou valor necessários.

Há uma infinidade de histórias hipotéticas, ardilosas ou inconscientes, envolvendo ingenuidade, miopia, interesses, medo de argumentar, zelo pela estabilidade, falta de comunicação, não saber ouvir, vício em protagonismo individual e suas benesses no modelo de gestão 1.0 onde fazer exatamente o que mandam gera recompensas.

Bons indicadores são alto custo de manutenção, dimensionamento absurdo de equipes de sustentação, delay entre identificação de corretivas e evolutivas até a execução e entrega delas, quando ajustes simples exigem desproporcional esforço, novos projetos comprometidos em um ciclo viciosos de legados e deficiências coisas do passado.

Em muitos casos as empresas sequer fazem esta ilação CAPEX += OPEX, como se uma nada tivesse a ver com a outra … mas estes impasses não sobrevivem a um bom estudo de cadeia de valor. Rasgar dinheiro até é possível em tempos de bonança, mas na crise eles estarão tão imersos em soluções mal construídas que sua OPEX irá cobrar o preço.

593861c6-2213-457e-aece-17e588847be7

É fácil ser perdulário e inconsequente durante a bonança, complicado é olhar para trás e perceber que milhões desperdiçados no passado estão fazendo falta. Na hora do aperto é possível reduzir a CAPEX, reduzir sua capacidade em evoluir, mas impossível reduzir uma OPEX contaminada sem comprometer a operação, o cliente e sua imagem.

Há algo tão ruim quanto o alto custo evitável de OPEX, é quando CAPEX gera novas CAPEX, quando a cada par de anos temos que reconstruir soluções mal feitas, que acaba virando uma colcha de retalhos e exige reconstrução. Um projeto que não atende a real necessidade, um produto mal feito que não pôde ser escalado ou evoluído.

Planejamento ágil, sinérgico, ciclos iterativo-incrementais-articulados, em camadas, com boas práticas de engenharia de software, testes automatizados, devops, com equipes auto-organizadas pesando cada decisão quanto ao ponto de equilíbrio entre qualidade e valor para o negócio, geram também valor no médio e longo prazos às partes.

Nosso trabalho encarece ou mitiga a equação CAPEX += OPEX, cada decisão tomada durante um projeto irá tender a uma OPEX mais alta ou mais baixa. As decisões em um projeto com CAPEX bem dimensionada e racional pode levar a uma OPEX recorrente como no cenário #1, #2, #3 ou #4 … isto pode ser uma escolha consciente ou inconsciente.

A pergunta é: Nossas decisões estão economizando tempo ou custo ou mesmo escopo e gerando uma OPEX #1? A brincadeira que faço em meus cursos é: quem ligaria para o diretor presidente da empresa e argumentaria caso isso tornasse-se explícito? Na maior parte das vezes, líderes diriam que não tinha a menor ideia que nossas decisões levavam a tamanho impacto … afinal, no Lean, GEMBA tem direitos e deveres, a responsabilidade de argumentar, advertir sobre a OPEX, por incrível que pareça, também é nossa.

O tom deste post é provocativo, precisamos compreender o oportunismo na Teoria da Agência, o mimetismo na Teoria Institucional, sócio-técnica, trilogia de Juran, capacidade absortiva, contingencial, GC no modelo SECI e de exploitation x exploration, acredito muito em entender Teorias da psicologia e sociologia que tanto nos envolvem e citam, dá uma olhada no eBook “sobre os ombros de gigantes“.

0

Acredite, documentação é muito mais que as tais histórias

|

Acredito muito além das sábias palavras do Neil Ford, keynote no Agile Brazil de 2012, pois temos dois tipos de usuários em cada projeto, aquele óbvio, que utilizará e se beneficiará do produto entregue, mas também há um usuário oculto, aquele que dará manutenção, sustentabilidade, continuidade no que construímos, podendo até ser (feliz ou infelizmente) nós mesmos.

Como Agile Coach, consultor ou professor, insisto na necessidade de distinguir o romantismo de muitos livros e artigos de agilistas da realidade ou momentuum de sua empresa, área, equipe, tecnologia. Enquanto evoluímos no quesito de excelência em engenharia de software, devemos ter clareza do custo x benefício relativo a aceleração e redução do processo e custo de sustentação.

A tempo, a solução não é aquela encontrada pela maioria absoluta das empresa, que mascaram a sua ineficiência e péssimas práticas de desenvolvimento voltadas ao imediatismo da entrega a qualquer custo. Gerar uma alta OPEX recorrente para ter uma CAPEX reduzida amplia uma percepção equivocada de ROI, mas é fogo amigo, equivocado e inaceitável.

CAPEX (expenditure) ~ despesas ou investimentos em bens de capital; despesas de capital; aquisições. OPEX (operational expenditure) refere-se às despesas operacionais, recorrentes, continuadas.

Tenho uma extensão à Teoria da Agência, ou você está trabalhando para ficar amadoramente bem na foto e ser promovido ou tem a responsabilidade e transparência de um profissional? A entrega de hoje está gerando mais um legado a ser mantido com doses maciças de custos recorrentes ou tem baixo custo de operação por ter sido corretamente construído e documentado?

O volume reduz-se conforme a evolução de sua excelência em engenharia de software, você segue DDD, componentiza, usa BDD, especifica e automatiza por exemplos, constrói código limpo, segue boas práticas de desenvolvimento na sua arquitetura e plataforma, automação de testes e integração contínua.

Aos poucos a documentação vai se integrando ao ambiente, projeto e produto, mas não é mágico, não só porque sempre teremos registros importantes a fazer, mas porque muitos leem em um artigo que documentação é do mal e sem ter o menor critério ou escrúpulos, passam a defender um go horse documental e tem a desfaçatez de citar grandes nomes que relatam projetos de excelência …

1. Pré-game

Acredito no valor da existência de conceitos como Funil de ideias, Gestão de portfólio, programas e projetos, comitês gestores. Grandes empresas não podem prescindir disso, tanto quanto contam com os préstimos de uma governança corporativa, governança de TI, PMO, gerentes de projetos ou papel preocupado na transversalidade, em aquisições, alocações, indicadores gerenciais.

Todo o tempo e processo existente antes do projeto iniciar sua etapa de execução ou desenvolvimento é conhecido como pré-game, ideias, discussões, submissões, descartes e aprovações, culminando no planejamento que habilita a fase seguinte de game, composta por sprints, especificação, desenvolvimento, validação e entregas. Eu posso oferecer um mix flexível, mas consistente de planejamento:

1.1. Project Model Canvas – Eu utilizo para a explicitação das informações básicas coletadas, um Termo de Abertura visual em uma folha grande e postits contendo o porque o projeto é necessário, o que ele é em sua essência, quem se envolverá e percepções sobre como será planejado, quando e quanto custará. Chamo a atenção para premissas, riscos, restrições e expectativas;

1.2. Elevator Statement – Um ótimo aquecimento, uma abstrair e entender justificativa, quem são os clientes, qual o desafio, problema ou oportunidade, que tipo de solução imaginamos, qual o valor de negócio esperado, o que é utilizado hoje para atender esta necessidade e quais os diferenciais para que o cliente e usuário deixe a solução atual e apoie e use a nova;

1.3. Personas – Quem são os atores envolvidos, seus perfis, necessidades e objetivos. Caso a caso, de 0 a 100, posso apenas caracterizá-los até utilizar de Value Proposition Canvas para identificar seus interesses, dores e expectativas de ganhos. Uma técnica dedicada a gerar empatia, tentar ver pelos olhos de cada parte envolvida, antecipando percepções de ganhos e perdas;

1.4. Customer Journey Map – Uso variações simplificadas desta técnica de mapeamento, convergente a uma User Story Mapping, para entendermos os fluxos de atividades necessárias para as principais jornadas dos usuários da solução em estudo. Cada jornada, passos manuais ou informatizados. Queremos entender o passo-a-passo das personas, identificar funcionalidades do produto;

1.5. Scrum SetUp Canvas – Artefato proposto para explicitar entendimento, combinações sobre tecnologia e metodologia, necessidades prévias/recorrentes a serem consideradas para efeito de modelagem, planejamento, execução ou entrega. Qual a composição de equipe, mapeamento de tecnologia, boas práticas necessárias, métricas, DoR e DoD, atividades e reservas para start e velocidade;

1.6. Release Plan – É a combinação de diferentes técnicas para o planejamento, usando técnicas de estimativa e capacidade baseadas em valor e cronologia. Ao final teremos metas iniciais para cada sprint em relação a construção do produto. Conceitos como Minimo Produto Viável, histórias do usuário e histórias técnicas, culminando com o product backlog, uma lista priorizada e planejada;

2. Game | Sprints | Construção

A construção de software gera produtos e soluções que se perpetuam por muitos anos, décadas, conheço soluções construídas nas décadas de 80 e 90 que ainda hoje sustentam negócios complexos e críticos com sucesso. A maioria delas possui uma documentação excessiva e abrangente, defasada e inevitavelmente comprometida, a psicologia explica, frente a centenas de páginas a maioria acaba rolando e enrolando e fugindo de se atolar e dedicar dias da semana só a isso.

O segredo não é se amotinar, dizer que documentação é do mal, que ela é inútil, porque inútil é o exagero, redundância, complexidade, dificuldade. Como tudo na vida, o equilíbrio é o ideal e em agilidade as retrospectivas precisam fazer seu trabalho, identificar desperdícios e gargalos (Lean), gerar atitude, proposição de melhorias, sempre baseado em fatos e não em paixões e idealizações.

2.1. Para o DoR (Definition Of Ready):

Importante, o registro documental do nosso DoR é rico demais para não receber alguma atenção, talvez um grupo de trabalho que defina o que, como e onde. A documentação de funcionalidades deve ter esta orientação, uma árvore racional que permita rapidamente localizá-la, a orientação para sprints é temporária, a orientação funcional é permanente e deve deter informações cumulativas úteis.

2.1.1. User Stories – Narrativa e critérios de aceite, incentivando o uso de notações. Como <quem><o que><porque> para a narrativa e <dado que><quando><então> para critérios, que representarão de forma atômica diferentes regras, como as de negócio e integração. Uma linha para cada, ao invés de parágrafos embaralhados com várias regras, preferencialmente seguindo BDD.

user stories - sebastien frechina

2.1.2. Protótipos com explicações – Via de regra, na absoluta maioria dos projetos de que participo, materializando a necessidade, exponenciando o papel de um bom UX (user experience), a oportunidade de termos o desenho das telas com diferentes características de navegação e usabilidade, enxuta, simples e objetiva, que norteará de forma efetiva o desenvolvimento melhor possível;

2.1.3. Documento complementar – Diferentes empresas chamam de diferentes nomes, mas é um documento que explicita questões desde regras de integração, SEO, funcionais, alertas ou lembretes que registram questões intrínsecas que poderão gerar problemas futuros se não forem registradas. A regra é bem simples, escreva somente o que precisa escrever, o melhor documento é aquele curto, que explica o que se desconhece, evite explicar o óbvio e já acordado, conhecido (*);

(*) há quem coloque estas informações e regras complementares no mesmo documento da User Story, inclusive o protótipo, e sai por ai dizendo que só usa a User Story e é suficiente … mas só porque está tudo junto não quer dizer que é uma coisa só.

2.1.4. Cenário(s) de testes – Para mim, e é assim que conduzo em todas as empresas por onde passo, a construção pelo menos do cenário principal de testes é essencial. Este cenário fazer parte do DoR é um importante insumo para os desenvolvedores, que os revisarão antes de liberarem a funcionalidade para testes e homologação. Para o DoR eu recomendo garantir o cenário principal, o SQA ou tester pode trabalhar ou não depois os cenários alternativos a seguir;

2.2. Para DoD (Definition Of Done):

2.2.1. Código auto-explicado – Seguir boas práticas de engenharia de software, potencializada por conceitos básicos de aprimoramento do código gerado como paterns, pair programming, code review em suas diferentes formas. O código gerado por equipes ágeis e conscientes de tudo o que falei acima, esforçam-se para gerar código limpo, legível, componentizado, boa OOP;

2.2.2. Testes automatizados – O uso de boas práticas como BDD com o uso de ferramentas para geração de testes, TDD ou pelo menos testes unitários, testes funcionais. Todas estas boas práticas geram informações e conhecimento rastreável e seguro, vivo, que se mantém atualizado sempre. Bem feitos são um manual dinãmico e explicativo orientado a comportamento e engenharia;

2.2.3. Versionamento e integração contínua – A ideia é seguir uma boa arquitetura e engenharia de software, de forma que crie uma matriz e árvore passível facilmente de ser conhecida a partir de sua navegação. O uso de boas ferramentas integradas geram baixo custo de assimilação, facilita troca de responsáveis, acelera novos integrantes, pesquisas e mesmo refatoração;

2.2.4. Gestão de configuração – É uma prerrogativa inalienável a qualquer equipe, na minha opinião quaisquer scripts ou ações relacionadas a promoção daquilo que está sendo feito carece registro, aglutinação e versionamento. Algumas empresas de diferentes tamanhos deixa esta atribuição a tarefas manuais e pessoais, um erro que gera riscos e impede agilidade em ocorrências;

2.2.5. Métricas, indicadores e Status Report – O uso de boas práticas em métricas também envolvem métricas técnicas e indicadores, que devem ser escolhidos com cuidado, como as taxas de cobertura citadas acima, mas também de softwares responsáveis pelos builds e integração contínua, SONAR, a maioria são automatizadas a partir de scripts e mapas apresentados nas Sprints Review, acompanhando entregas e seus status report.

Cada um dos itens acima em teoria foram construídos dentro do próprio processo e mantidos atualizados, após o projeto encerrado é preciso mantê-los vivos, o que demanda mínimo esforço, quer em uma ferramenta ALM robusta, sharepoint, confluence, na dúvida se isso é possível, me manda uma msg …

Manual – Amaldiçoado por muitos, mas ainda úteis em casos específicos como software de prateleira, quer manuais físicos ou virtuais, conforme negócio. As vezes na forma de uma apresentação para replicação de treinamentos, as vezes vídeos, esporadicamente manuais em pdf, seguidamente virtuais, acessíveis durante a navegação, sensíveis a contexto. Pelo menos um FAQuizinho rola.

2

Assessment (+20) não gera diagnóstico, mas é uma usina de insights

|

Compartilho a seguir alguns assessments que tenho usado na minha estrada como Agile Coach e consultor, a do James Shore eu aprendi com o grande parceiro Alejandro Olchik em 2015, os outros fui  encontrando em meio a milhares de páginas e artigos que fui lendo e compartilhando nos últimos sete anos.

A seguir um mapa geral dos assessments que compartilhei neste post, clique aqui para baixar se quiser te-lo em tamanho A3 como um guia:

ASSESSMENTS

Não acredito em assessments para diagnósticos, mas se bem escolhido frente ao momento do time, é uma ferramenta relevante para ampliar horizontes e fomentar o debate construtivo, aumentar o auto-conhecimento e embasar os próximos passos e planos de ação. Clique nas imagens para ir às páginas e arquivos originais:

1. Roda da Vida

Se você não tem domínio sobre você mesmo, se não dedica algum tempo para auto-conhecer-se, querer fazer isso para o grupo é amadorismo. Pessoas que se conhecem bem pessoal e profissionalmente tendem a se posicionar e propôr soluções mais assertivamente … A roda da vida é uma preliminar pessoal para SWOT, BMY, Johari, CHAx5, antes de discutir sonhos e planos coletivos.

2. Assessment James Shore

Este aqui tem questões muito objetivas sobre valores e boas práticas em áreas como Agile Thinking, Colaboração, Planejamento, Desenvolvimento e Entrega. Em grupos grandes eu divido em sub-grupos de 3 pessoas, que respondem e depois convergimos juntos no entendimento de pontos fortes e fracos, propondo pequenos planos de ação para melhorias:

art of agile - shore map

3. Maturity Assessment Model for Scrum Teams

No site da Scrum Alliance tem este assessment sobre os 12 princípios ágeis, já o utilizei como warmup, antes de uma retrospectiva e gerou bons insights sobre nossos valores ágeis. A proposta original diferencia a opinião de cada um, mas eu normalmente faço uma primeira discussão em sub-grupos de 2 ou 3, depois consolidamos, assim cada coluna passa a representar um grupo e não uma pessoa:

4. Comparative Agility

Eu realizei o assessment online e salvei todas as questões para poder me debruçar e analisá-las com mais calma … até mesmo porque meu objetivo não era nos comparar com outras empresas e equipes, mas proporcionar reflexões sobre quesitos relevantes e montar planos de ações para melhoria contínua:

5. Agilometer PRINCE2

PRINCE2 é um framework tradicional para gerenciamento de projetos que vem se propondo a flexibilizar-se e agregar valor com princípios e boas práticas oriundas do Scrum e Kanban. De toda forma, compartilho um assessment muito simples, é só imprimir colorido e colocar “botões” deslizantes, que podem ser postits:

6. SAFe Team self-assessment

Esse é bem conhecido da galera do SAFe, o que restringe seu uso a poucas e grandes empresas, aquelas que usam o framework para projetos que contam com muitas equipes trabalhando juntas no mesmo release … no início pode parecer um tanto desafiador, e é, mas mais pelo tanto de atitude e realismo que exige de todos:

7. Squad Health Check Model

Esse é muito legal e seu uso é bem mais amplo, podendo ter nas colunas a auto-avaliação do time a cada sprint, uma forma de manter no radar os resultados obtidos com os planos de ação e iniciativas realizadas no transcorrer do projeto. O pdf já disponibiliza os cartões e semáforos, usamos as setas para dar a tendência – www.barryovereem.com/how-i-used-the-spotify-squad-health-check

8. The Unoficial Check-list SCRUM

Já fiz posts sobre este e outros, mas os links são para as páginas originais. Este eu achei muito legal e já usei com bons resultados, lembrando que o meu objetivo nunca é diagnóstico, mas reflexão pelo próprio time durante uma retrospectiva, que decide a partir disto quais as ações melhores a serem priorizadas:

Há uma lista com sugestões de assessments listadas por Barry Overeem, que relaciono abaixo, para estes sugiro o post original e seguir os links abaixo:

20. SCHNEIDER’S CULTURE ASSESSMENT – Para terminar compartilho um assessment lastreado na teoria sobre cultura organizacional de Schneider para descontrair e lembrar do que eu disse no início sobre tudo iniciar na pessoa, sendo assim, também é preciso lembrar que pessoas e times estão imersos em um contexto organizacional que pode ajudar ou atrapalhar se não estiver em equilíbrio. Ela é muito intuitiva e busca estabelecer o debate acerca da orientação cultural em equilíbrio ou não:

0

Carreiras e empresas equilibram-se entre kaizen e kaikaku

|

Alta performance tem a ver com domínio, já inovação tem a ver com aprendizado, quer profissionais ou empresas, é preciso equilibrar o que sabemos e o novo. Como em um Eurotunel, precisamos de uma galeria para a produção e outra para a inovação, que mesmo possuindo diferentes bitolas são interligadas por tuneis de serviço, para equalização da pressão entre elas e assim avançar continuamente.

O perfil T ou Pi proposto para profissionais do século XXI, com profundidade e domínio, mas também amplitude de conhecimento, equivale a teoria da Capacidade Absortiva – “conjunto de procedimentos e rotinas pelas quais as empresas adquirem, assimilam, transformam e exploram conhecimento para produzir uma capacidade organizacional dinâmica” (Zahra e George, 2002).

Há quem pense em inovação como sendo algo pertinente ao lançamento de novos produtos ou serviços por empresas, mas a capacidade absortiva vai além desta percepção de inovação. Perceber oportunidades de evolução, melhoria, mudanças, quer em nossas carreiras, quer em processos, trabalho, relacionamentos, produtos ou serviços, tudo isso depende de visão, criatividade, inspiração, de inovação.

Autofagia / Zona de Conforto

Sou um profissional de TI, quando entrei no curso de análise de sistemas em 1981 eu ainda não sabia de fato que teria uma vida profissional que exigiria atualização e adaptação em um ritmo atípico comparado a outras profissões. A cada ano é possível perceber novas tecnologias, hard e soft skills surgindo e mudando, entre elas eu preciso decidir constantemente por novos aprendizados e domínios.

Se Darwin fosse de TI, não precisaria ter viajado a Galápagos para concluir que a sobrevivência não é do mais forte ou mais rápido, mas daquele que se adapta. Força e agilidade servem para lhe tirar de um apuro, mas olhando para o passar dos anos, precisamos perceber quais as mudanças e oportunidades melhor nos convém ou nos exigem para nos adaptarmos a elas.

charles-darwin-quote

Profissionais que se acomodam em fazer bem feito aquilo que é pago para fazer vivem a ilusão de que sendo excelentes em determinado conhecimento, serão reconhecidos e regiamente pagos por isso. São profissionais de perfil I, satisfeitos com o que aprenderam e conquistaram, esquecendo que o mundo dá voltas, muda sem parar, novos conhecimentos, tecnologias e habilidades surgem e crescem.

Empresas conseguem liderar segmentos de mercado, agigantam-se para então apenas entrar para a história como um exemplo de falta de visão, incapacidade de se reinventar, não é porque não geraram bilionários, mas por falta desta percepção de continua evolução do mundo que não para de girar, apequenam-se e algumas até desaparecem porque alguém com menos recursos e mais visão as ultrapassa.

Kaikaku x Kaizen

Nossa vida e de nossas empresas fluem, equilibram, pendulam entre alta produtividade e inovação significativa. Enquanto em alta produtividade pode ser que pequenas melhorias e ajustes surjam, mas de tempos em tempos teremos mudanças de alto impacto. É como Kaikaku e Kaizen, o Kaizen é fazer bem o que sabemos fazer, com pequenas melhorias eventuais, para então termos o Kaikaku, que é um grande salto evolutivo.

O Kaizen é um continuo evolucionário, Kaikaku é revolucionário, sendo que o processo de melhoria quando praticado de forma consciente, orquestrada, tende a consumir cada vez menos energia e gerar melhores resultados. Não podemos esquecer o que Schein, Argyris ou Tofler preconizaram quanto ao desafio de aprender algo novo, ação que consome energia e deve ser entendida e dominada:

Exploration x Exploitation

Insisto muito a quem se interessou por este assunto, dá uma olhada no meu post de 2014 sobre uma resenha do artigo seminal de James G March de 1991 e minha interpretação – https://jorgekotickaudy.wordpress.com/2014/06/19/vale-a-pena-entender-o-exploitation-e-exploration/

exploration_exploitation
n2a03fig13

0

Savana Scrum – Use a receita, experimente, aprenda e melhore

|

Uma equipe ágil de alta performance deve estar sempre aberta a discutir e experimentar novas ou mesmo velhas receitas na intenção de melhorar, trata-se de um modelo mental voltado a melhoria contínua, redução de zonas de conforto.

Novas e talvez velhas receitas, porque nunca somos os mesmos, como a parábola do rio no ditado chinês, pode ser que técnicas tentadas antes agora tenham sucesso, porque desde então aprendemos, crescemos e talvez agora dê certo.

Pedra que rola não cria limo!

Uma equipe que “acha” que já faz o seu melhor e recusa sugestões para tentativa de melhoria indica haver uma grande zona de conforto ágil, uma trincheira ágil, o mundo de software precisa de profissionais de olhos abertos a inquietos.

É como uma receita típica, algumas perpetuam-se, mas sempre estarão sujeitas a serem o ponto de partida para novas receitas, com novos ingredientes, não porque a receita mudou, mas porque nós mudamos e queremos experimentar.

Não é incomum ver equipes ditas ágeis entrincheiradas, alheias a percepção ou acomodadas com seus pequenos e inevitáveis desperdícios. Todo o substrato ágil baseia-se no Lean, em princípios como Gemba e Kaizen … em continuum.

Por isso ciclos iterativo-incrementais-articulados, para nos lembrar que pequenas experimentações, uma dose quinzenal de inquietação nos faz lembrar o quanto ainda temos pequenos desperdícios ou oportunidades de crescimento.

Já falei sobre a inevitabilidade de ter um formador de opinião em cada time, é importante que ele tenha consciência de que o time não é seu, que sua experiência e influência deve ser do bem, aberto, incentivando e apoiando outras opiniões.

O ideal é equilíbrio, sempre com foco em adequado valor entregue em equidade, atendendo o negócio, com qualidade e excelência, sustentável, transparentes e realistas … inspiradas em missão, visão e objetivos acordados e monitorados.

Em TI é inevitável jamais estarmos no estado da arte, esta condição não é para gerar frustração, mas engajamento ao se ter consciência do mix de oportunidades que ainda não aproveitamos. Dinâmicos em baby steps, cadenciado, confortável.

Por essas e outras é que SCRUM continua sendo o método ágil mais utilizado no mundo, porque ele  não pressupõe idealizações, mas sugere ciclos, timeboxes, que bem aproveitados manterão a equipe ligada, alerta, disposta a experimentar.

Small Project Philosophy, um pequeno projeto de cada vez, cliente e fornecedor de outros projetos em programas e portfólios. Com releases plans, sprints, experimentando, curtindo, atendendo, entregando, aprendendo e melhorando.

0

Time Ágil ou Time Ágil de Alta Performance?

|

Estamos atingindo um virtual ponto de saturação do termo “Times Ágeis”, cada vez mais diluído, frequentemente mal entendido. Creio fazer-se necessária uma mudança para reforçar e quebrar vícios inerentes a banalização de um termo que per si sempre teve múltiplas interpretações: O que é Ágil no dicionário?

No dicionário, ágil é aquilo que se move com facilidade, ligeiro, veloz; Algo desembaraçado, vivo, rápido; Eficiente, diligente, trabalhador.

Eu prefiro “Times Ágeis de Alta Performance“. Acho sinceramente que só o termo Ágil está carecendo de uma ajudinha explícita, para não mascarar ou confundir o amplo mix de equidade que queremos atingir – cliente, empresa, profissionais, tecnologia, valor, Lean, excelência, ambiente, satisfação, …

No dicionário, Alta Performance diz respeito a atingimento de todo seu potencial, poder desfrutar de tudo que suas habilidades possam proporcionar.

Tenho visto muita facilidade em nos considerarmos ágeis, mas ao mesmo tempo temos dificuldade em nos considerarmos equipes de alta performance.

É preciso idealizar menos, esforçar-se mais, agilidade é trabalho duro, persistente, de alta performance e sustentável. Vejo muitas convicções e trincheiras sobre agilidade, muita retórica, resignações, impedimentos, desmotivação porque o mundo não é o que deveria ser ou porque a lua não é de queijo.

A essência do mindset ágil diz respeito a geração de um ecossistema propício a geração de valor a todos os envolvidos, nasceu fundamentado nos princípios Lean, eliminação de todo e qualquer desperdício sem propósito. Por isso a pirâmide Lean, porque é preciso considerar estratégia, tática e técnica.

Tem uma brincadeira que faço em meus cursos, eu pergunto a alguém se ele se considera um bom profissional? Sempre dizem que sim, daí eu pergunto porque? Sempre me dizem que é porque entregam, são reconhecidos. Eu concluo pedindo para se compararem com equipes reconhecidas como de alta performance? A resposta sempre é um sorriso, um nem tanto, um sim mas!

Inexiste agilidade se estamos nos acomodando em meio a trincheiras: Se há retrabalho, se há desperdício, se falta poke-yoke e kaizen com cenários, automações, pair, peer review, se falta comunicação ativa e eficaz, se existem silos, trincheiras, ações motivadas pela busca de culpados e responsáveis, está na hora de sermos mais transparentes e realistas, puxando para nós o que é de nossa alçada.

Proponho uma reflexão, através de um auto-questionário:

  • 1ª – Você e sua equipe são ágeis?
  • 2ª – São uma equipe de alta performance?
  • 3ª – A resposta é que a culpa é dos outros?
  • 4ª – Você continua aprendendo e tentando ou se entrincheirou?

Há um exercício que promovo em equipes que já praticam e possuem muitas barreiras organizacionais, dificuldades, equipes que já encontraram defesas e explicações sobre cada desvio e causas de cada problema recorrente: Crie um quadro análogo ao abaixo, bem grande, na vertical temos “valor” à agilidade aumentando de baixo para cima e na horizontal a alçada. Para cada postit colocado a esquerda (responsabilidade do cliente ou da empresa/status quo), é preciso colocar um adicional a direita com o que estamos ou poderíamos estar fazendo para eliminar ou mitigar aquela carência.

É um warmup, um exercício de brainstorming, de ToolBox, visando encontrar técnicas de mitigação, de argumentação, de ações que nos levem adiante, mais um passo na eliminação de desperdícios, geração de maior valor e construção de um ecossistema sustentável no qual estamos inseridos. O desenho abaixo é ilustrativo, tentando ser didático, a direita podem ser variados tipos de ações, pró-ativas, engajadas, focadas em kaizen, assumindo protagonismo e fugindo dos silos:

É fácil culpar o cliente, o diretor, o gerente, outras áreas da empresa, o que é difícil é assumir o papel de agente da mudança, esse é o mote do conceito por tras do livro e jogo TOOLBOX 360°: Se nós estamos na vanguarda do entendimento do que ser ágil, ao invés de culpar alguém ou transferir e lavar as mãos, nosso papel é buscar técnicas, boas práticas, abordagens que ajudem a contornar o problema, mostrar para quem ainda não entendeu ou trazer a luz informações e conhecimentos que ajudem a darmos o próximo passo.

Você ainda é um agente da mudança? Ou desistiu em algum momento? Se alguém não entendeu e não contribui, você continua sendo ágil e tentando mudar ou em algum momento desmotivou e desistiu, se entrincheirou em explicações e justificativas?

Últimos posts sobre mindset