Kanban

Negociando a implantação de métodos ágeis com o Capitão Kirk e o Mr. Spock

~ Marco Mendes ~ Deixe um comentário

Jornada nas Estrelas foi uma série fora do seu tempo. Lançada no meio dos anos 60, essa série discutia guerra e paz, lealdade, autoritarismo, imperialismo, economia, racismo, existencialismo, metafísica, religião, direitos humanos, sexismo, feminismo e o papel da tecnologia. E tudo isso contado de forma leve e épica dentro do propósito da frota estelar de “audaciosamente ir onde nenhum homem jamais esteve”.

Esse série apresentava dois icônicos personagens, o capitão da nave James Tiberius Kirk e seu oficial Spock (o segundo em comando).

Kirk é passional, emotivo, intuitivo e com uma incrível facilidade para improvisar. Já Spock, filho de mãe terráquea e pai Vulcano, é racional, analítico, dedutivo e busca sempre ponderar e analisar todas as possibilidades antes de tomar as suas decisões.

Na série, eles tem diálogos que mostram suas naturezas distintas tais como:

– “Algumas coisas são impossíveis até o momento onde elas não são mais”, James. T. Kirk

– “Isso é altamente ilógico”, Spock

Para alguns fãs de ficção científica, Star Trek foi maior e mais importante que Star Wars. Mas não vamos iniciar uma guerra interplanetária aqui.

O Cérebro Humano – Spock e Kirk Juntos

Durante séculos, filósofos, psicólogos e cientistas distinguiram entre raciocínio intuitivo e o consciente. Platão, por exemplo, já falava em seu livro Psyche entre o nosso cérebro consciente (Logos), do nosso cérebro emocional – aquele dos desejos e apetite (Eros) e do afeto (Thymos).

Mais recentemente, Daniel Kahneman criou os termos sistema 1 e sistema 2 em livro “Rápido e Devagar”, que popularizou a distinção entre processos de pensamento automáticos e deliberados. O modelo de Kahneman divide os processos da mente em dois sistemas distintos:

O sistema 1 “é a abordagem rápida, automática e intuitiva do cérebro”, que apelido aqui de modo Capitão Kirk. A atividade do sistema 1 inclui as atividades mentais inatas com as quais nascemos, como uma preparação para perceber o mundo ao nosso redor, reconhecer objetos, orientar a atenção, evitar perdas. Outras atividades mentais tornam-se rápidas e automáticas através da prática prolongada.

O sistema 2 é “o modo analítico mais lento da mente, onde a razão domina”, que chamo aqui de modo Spock. Geralmente, a atividade do sistema 2 é ativada quando fazemos algo que não ocorre naturalmente e requer algum tipo de esforço mental consciente.

Daniel Kahneman fornece um exemplo comum usado para demonstrar os dois sistemas. Um taco e uma bola juntos custam US$ 1,10. O taco custa US $ 1 a mais que a bola. Quanto custa a bola? Diante desse quebra-cabeça, a maioria das pessoas adivinha instantaneamente 10 centavos. A resposta correta, no entanto, é de 5 centavos – o que, novamente, a maioria das pessoas pode resolver depois de passar mais tempo pensando sobre a questão.

Minimizando a resistência a mudanças

Quando buscamos implantar métodos ágeis, temos que ter atenção extrema às respostas dos outros. Peter Senge, exímio pensador sistêmico, já falava:

“As pessoas não resistem às mudanças. As pessoas resistem a serem mudadas”.

Ao reconhecer uma mudança, as pessoas podem trazer objeções no modo Kirk (Sistema Tipo 1 em ação) ou no modo Spock (Sistema Tipo 2 em ação).

O primeiro modo são receios emocionais tais como:

  • Dignidade
  • Respeito
  • Status
  • Identidade
  • Desejos
  • Confiança
  • Orgulho

O segundo modo está ligado a receios de natureza intelectual e aspectos que desafiam o seu modo de pensar. Busque reconhecer as objeções as mudanças quando você se depara como uma resistência.

David Anderson, líder da comunidade Kanban, nos apresenta as duas regras de ouro para lidar com objeções.

  1. Nunca combata uma objeção racional com um argumento emocional.
  2. Nunca combata uma objeção emocional com um argumento racional.

Trabalhar a primeira regra é menos complexo. Se você enfrenta objeções racionais, você pode desenvolver argumentos, trazer fatos e dados para criar um debate. O Spock que habita o cérebro racional da pessoa eventualmente fará as conexões.

A notícia ruim é que na grande maioria das vezes as objeções são emocionais. E enfrentar o capitão James T. Kirk não é tarefa simples. Se você enfrenta uma objeção emocional, você precisa trazer uma emoção ainda mais forte para lidar com a resistência. Emoções mais fortes podem ser aquelas que irão gerar neurotransmissores positivos como dopamina, oxitocina, serotonina e endorfinas ou mecanismos de urgência gerados por descargas de adrenalina e cortisol.

Cito aqui um caso extremo onde pude observar que um gerente de projeto que não aceitou uma mudança de papel para um novo papel de Scrum Master. Se uma mudança de papel afeta a dignidade ou identidade de um funcionário e ele resiste, uma ação que gera uma emoção mais forte (embora negativa) seria uma ameaça de demissão. E foi isso que o diretor fez. Ele ameaçou o gerente de projeto e disse que a mudança era mandatória. O medo de não ter comida ou casa é mais forte (gera adrenalina e cortisol) e sobrepuja o receio da sua mudança de identidade.

Não queremos, óbvio, fazer a mudança pelo medo. Até porque agile coaches não são, normalmente, ou donos das organizações. E mudanças baseadas em medos podem gerar efeitos colaterais muito ruins. Encontrar uma emoção mais forte pode ser difícil e demorado nesses casos, mas é o caminho para combater objeções emocionais. O método Kanban, por exemplo, não busca trabalhar reorganizações ou mudanças de papel na sua introdução pois esses tipos de mudanças estão mais suscetíveis a mudanças que ativem caminhos límbicos de pavor, medo ou perda da identidade.

Um exemplo positivo que pude observar em um time estava ligado a troca do trabalho empurrado para trabalho puxado em um time ágil. Havia uma cultura Scrum de assumir um lote de funcionalidades de uma única vez em uma reunião longa e demorada de Planejamento de Sprint. No final da reunião as funcionalidades já eram atribuídas aos desenvolvedores dessa organização. A gerente percebeu que esse modelo levava a falhas contínuas de entrega. As promessas eram continuamente quebradas. E isso minava a confiança dos diretores e clientes nesse time. Inicialmente a gerente tentou introduzir a mudança para um sistema puxado onde as demandas seriam trazidas uma por vez apenas quando houve capacidade disponível do time. Ao tentar propor a mudança, o time resistiu. Havia uma identidade muito forte ligada a papéis e práticas do Scrum.

Ela então buscou uma abordagem alternativa baseada em princípios Kanban. Primeiro, ela não atacou a identidade do time. Ela teve paciência. Durante algumas semanas ela melhorou a gestão à vista mostrando o trabalho em andamento, impedimentos e bloqueios. Ela também construiu métricas de fluxo como histogramas de tempo de ciclo e fluxos cumulativos de valor. Isso permitiu que as retrospectivas mudassem de momentos de pura lamentação para conversas mais ricas. A gerente também teve cuidado de apontar os problemas sobre o trabalho e não sobre os trabalhadores. A partir de conversas mais ricas e um ambiente seguro para falhar, o time desenvolveu uma base emocional mais sólida para lidar com os problemas de previsibilidade. Depois de poucos meses o time estava emocionalmente preparado para fazer a mudança de um trabalho empurrado para um trabalho puxado. E com o suporte de histogramas de tempo de ciclo o time agora era capaz de trabalhar previsibilidade sobre demandas novas para o seu sistema de trabalho.

Definitivamente, um caminho longo e duro. Mas é necessário quando um agente de mudança enfrenta objeções emocionais no seu caminho e queira criar mudanças consistentes e perenes.

A mensagem aqui é que criar uma cultura de agilidade de negócio é complexo. Não existem receitas de bolo. Ao mesmo tempo, existe hoje uma ampla base sociológica e de práticas de gestão para orientar agentes de mudanças ou agile coaches.

“Live long and prosper”, Mr. Spock.

As 10 práticas de agilidade mais populares do planeta em 2020

~ Marco Mendes ~ Deixe um comentário

Métodos e frameworks ágeis como Scrum, Safe, LESS, DevOps ou Kanban não são atômicos. Eles são compostos por várias práticas de processo. Uma prática é uma estrutura pequena, uma parte do todo. E as partes organizadas em uma coleção ajudam a criar a essência e o comportamento do todo.

Entretanto, um método ágil não é apenas a soma de suas práticas constituintes. Quando examinamos partes e seus coletivos podemos ter arranjos muito interessantes.

  1. Por exemplo, podemos ter partes individualmente estúpidas e coletivos muito inteligentes. A epidemia do CoVid-19 é um exemplo de um organismo coletivo muito inteligente (e perverso) formado a partir de partes individuais estúpidas.
  2. Podemos ter também coletivos inteligentes formados por partes individualmente inteligentes. Por exemplo, uma matilha de orcas caçando um cardume de atuns é um exemplo desse arranjo.
  3. Um outro arranjo são coletivos poucos inteligentes formados por partes inteligentes, como uma carreata de pessoas, individualmente boas, defendendo uma ideologia política dogmática. O mesmo acontece em torcidas organizadas em estádios de garbo e elegância por todo o Brasil.
  4. Finalmente, temos também arranjos coletivos ruins formados por partes individualmente ruins. Se você já tentou fazer bom prato de comida com ingredientes ruins você entendeu a mensagem aqui.

Uma boa prática de processo não irá garantir um bom método (o nosso coletivo de práticas). Mas você não terá um bom método ágil com práticas pouco adaptadas na sua realidade prática. Ou seja, um ponto de partida ainda melhor que métodos quando pensamos em implantações ágeis é o conceito de práticas de processo. Práticas são recombináveis e podem ser experimentadas em virtualmente qualquer ambiente.  Práticas são seguras para falhas pois podem ser facilmente abandonadas se não se mostrarem viáveis.

E, principalmente, práticas são muito mais robustas do que grandes frameworks ágeis inerentes frágeis e que exigem pesados investimentos em treinamentos e reorganização de empresas.

As 10 Práticas de Agilidade Mais Populares em 2020

O Relatório do Estado da Agilidade publicou em 2020 as práticas ágeis mais adotadas por mais de 1100 entrevistados. Os resultados foram:

  1. Reunião Diária – 85% dos entrevistados.
  2. Retrospectivas – 81%
  3. Planejamento de Sprints – 79%
  4. Demonstrações/Revisão de Sprints – 77%
  5. Iterações Curtas – 64%
  6. Kanban – 63%
  7. Estimativas de Time – 60%
  8. Product Owner/Cliente Dedicado – 54%
  9. Planejamento de Releases – 51%
  10. Time integrado (Devs e Testers integrados) – 51%

Algumas interpretações a partir desses dados seguem abaixo.

1.As quatro primeiras práticas estão ligadas a cadências (ou ritos). Cadências formam um tipo de ciclo de feedback fundamental para que sistemas de trabalho possam ser melhorados em ambientes complexos. Muito vezes subestimadas ou tratados com desdém, devemos ter extrema atenção à execução dessas práticas.

Quando facilito essas cadências,  por exemplo, sempre uso um quadro Kanban (prática #6), com o uso da seguinte heurística: foco no trabalho e não nas pessoas. Para a retrospectiva, foco no trabalho entregue na coluna Terminado. Para a reunião diária, sempre pergunto ao quadro o trabalho que está em execução (Work In Progress). E para reuniões de reabastecimentos como o Planejamento de Sprints sempre olho para a coluna de histórias e pronto para iniciar.

2. A prática #5 está ligada a ciclos curtos, também propriedade fundamental de sistemas complexos adaptativos. Times ágeis normalmente trabalham com ciclos entre 1 a 4 semanas. Ciclos menores

3. A prática #6 está ligada a transparência, gestão à vista e gestão de riscos. Quadros Kanban também são um alicerce importante para observar sobrecarga e criar um ambiente de discussão para a introdução de políticas de melhoria.

4. A prática #7 mostra que quase dois terços do mercado ainda definem compromissos baseado em estimativas. É um sinal que existe muita oportunidade de avanço com o uso de elementos mais maduros e robustos que envolvem previsibilidade, métricas de fluxo e o movimento #noestimates. Tenho a esperança que essa prática não apareça mais aqui quando o mercado ganhar mais maturidade.

5. A prática #8 mostra que metade dos times já conseguem ter pontos focais dedicados para interagir com seus clientes. Isso é positivo em minha opinião pois mostra que a interface com áreas clientes está em franca melhoria.

6. A prática #9 exibe que metade dos times estabelecer planos de lançamento no mercado com produtos mínimos viáveis e entregas parciais. Me parece ser um passo de maturidade quando comparamos com abordagens de construção de elefantes em projetos que demoravam muitos anos.

7. Finalmente, a prática #10 mostra esforços de reorganização para a quebra de silos funcionais em metade das organizações. O uso de times multidisciplinares é sem dúvida um facilitador para times operarem e melhorar suas eficiências de fluxo. Vale apenas o ponto de atenção que não é uma receita de bolo que possa ser aplicada em qualquer contexto e não precisar estar no caminho obrigatório de qualquer implantação de agilidade.

Estudar e aplicar práticas é robusto. Quando você combina boas práticas em bons arranjos você poder criar, por emergência sistêmica,  um método muito mais poderoso que as práticas individuais.

 

Um sistema ruim sempre derrota pessoas boas

~ Marco Mendes ~ 1 comentário

Brasil e Alemenha em 2014 - 7 x1

O dia era 8 de Julho, do ano de 2014. Era uma terça-feira com um céu azul e tempo agradável, como todo fim de outono em Belo Horizonte. Brasil e Alemanha iriam se enfrentar pela semifinal da copa do mundo. Nunca um jogo dessa magnitude havia acontecido na região das alterosas. E por todo o  Brasil havia uma grande expectativa da sua seleção estar em uma final de copa do mundo.

Só que não! A história, contada e recontada, você conhece bem. Não preciso repeti-la aqui.

Avancemos para o dia seguinte. Um vexame esportivo como nunca visto na história Brasileira. Jornais de todo o mundo destacam a excepcional vitória da Alemanha, nunca antes vista em uma semifinal.  E para o brasileiro comum, eu inclusive, restava erguer os dedos e apontar culpados. Afinal, é mais fácil culpar pessoas quando alguma coisa vai mal.

O mito dos heróis e vilões

Tendemos a supervalorizar o talento individual. Acreditamos que as maiores e piores coisas que acontecem são obras de pessoas; iluminadas ou amaldiçoadas. Fazemos isso o tempo todo, culpando aquele jogador, aquele político ou aquele colega de trabalho pelo insucesso das iniciativas que estamos observando ou participando.

Esse pensamento é ingênuo. Muito. E para piorar, somos programados a insistir nessa ingenuidade. Psicólogos já catalogaram esse viés, chamado de Viés de Atribuição. Esse viés cognitivo se refere aos erros sistemáticos cometidos quando as pessoas avaliam ou tentam encontrar razões para seus próprios comportamentos e os dos outros.

Se você corta alguém abruptamente no trânsito, você cria uma justificativa no seu cérebro. Estou atrasado para pegar meu filho na escola. Foi mal.

Mas se alguém faz o mesmo com você duas semanas depois, aquele sujeito é um babaca ignorante sem nenhum escrúpulo e educação. Ele merece morrer empalado em praça pública, sem sombra de dúvida.

O mito dos heróis e vilões nas empresas

Em muitas organizações, é inútil preocupar-se indevidamente com variações entre indivíduos. Tipicamente, a  cultura organizacional, políticas e a liderança tornam irrelevantes as diferenças entre indivíduos.

Por quê? Empresas não “criam” coisas pois elas são seres sencientes. Ao invés, empresas executam, competem e coordenam esforços de muitas pessoas. As empresas mais bem-sucedidas nestas tarefas são aquelas em que o sistema de trabalho é a estrela.

W. Edwards Deming já nos mostrava empiricamente na metade do século XX que a performance das instituições  é dirigida muito mais pelos sistemas de trabalho do que pelo talento individual.  Empresas são sistemas adaptativos complexos. E, em sistemas adaptativos complexos, os resultados são multifatoriais e não são óbvios. Se o fossem, todo empreendedor chefiaria uma Apple, Google ou Amazon nesse exato momento.

O que são sistemas de trabalho?

Vou trazer um relato de um caso que experienciei. Um trabalhador em uma organização era vilanizado por ser alguém que cometia muitos defeitos em suas tarefas. A área de qualidade dessa empresa o satanizava e discussões pesadas aconteciam com a área de engenharia por causa dessa pessoa.

A área de engenharia dessas organização trabalhava com políticas de remuneração variáveis. E essa pessoa, em particular, era premiada por cumprir tarefas no prazo; mesmo que a qualidade não fosse endereçada. Afinal, havia uma área de qualidade para “pegar” os defeitos. Com tais incentivos, ele se adaptou. E realmente o foco dele era apenas a velocidade de entrega das tarefas.

O efeito prático das políticas de otimização local do trabalho e da atribuição de problema para as pessoas contribuiu para que essa empresa tivesse tempos de resposta enormes para as demandas do time do tal garoto enxaqueca. Era um cenário destrutivo e todos perdiam. Um verdadeiro 7×1.

Quando um novo gestor entrou e começou a mudar as engrenagens do sistema (não as pessoas), as políticas foram mudadas e também os sistemas de incentivos. A cultura agora foi mudada de competição local para ganhos globais ou nada feito. Os incentivos financeiros valorizam de forma balanceada a velocidade e fatores de qualidade. Depois de alguns meses, a pessoa que era culpada por tantos defeitos passou a entrega tarefas com índices de qualidade excelente, na visão das outras áreas.

O que houve aqui? O sistema foi ajustado, gradativamente. E ajustes no sistema com políticas corretas ajudam a incentivar bons comportamentos. E bons comportamentos, repetidos em base diária, cultivam culturas de sucesso. E culturas de sucesso criam espaço para que oportunidades aleatórias catapultem organizações para o sucesso.

Como posso criar sistemas de trabalho na minha organização?

  1. Primeiro, combata a sua programação mental ingênua.Quando um erro grave acontecer, você vai querer a cabeça do infeliz que a cometeu. Em uma bandeja de prata. Esse é o seu modo lagarto em ação, tomando o controle mental do seu neocortex cerebral. Ao invés, pare e respire. Faça uma análise das fragilidades do seu sistema de trabalho. Se erros graves então acontecendo, o sistema de trabalho está frágil.Nada é verdadeiramente bom ou ruim, mas o pensamento faz com que o seja, já dizia William Shakespeare.
  2. Combata as fragilidades. E não as pessoas.Examine as políticas em curso, explícitas ou implícitas.  Examine a cultura e o efeito das políticas em curso no comportamento das pessoas. Finalmente, analise os sistemas de incentivos. Realize análises de causa raiz com instrumentos como o processo A3. E descubra com profundidade os fatos geradores dos comportamentos ruins que provocam erros danosos na sua organização.
  3. Mude o sistema de trabalho, um grão de area por dia. 

    Envolva as pessoas nas mudanças e busque atos de liderança. Em base  periódica, introduza mudanças evolucionárias na sua organização. Essas mudanças devem introduzir estressores de melhoria na sua organização e tornar os seus sistemas menos frágeis, resilientes, robustos e eventualmente anti-frágeis.Por exemplo, o Método Kanban possui um amplo catálogo de ideias de melhorias ligada a gestão visual, limitação do trabalho em progresso, políticas explícitas, gestão do fluxo, sistemas de feeback, entre outros. Somado a um mecanismo de mudanças evolucionárias e atos de liderança, ela pode ajudar você na mudança da sua organização para criar agilidade de negócio e mais robustez.Um outro exemplo é a cultura DevOps. Através de práticas evolucionárias de colaboração, automação, medição e gestão de fluxo, ela promove que empresas de TI possam reduzir tempos de entrega, melhorar feedbacks técnicos e promover mais experimentos.

    Um terceiro exemplo é o modelo mental do Management 3.0, que busca operar na energização de pessoas, empoderamento de times, alinhamento de restrições e desenvolvimento de competências em ambientes de gestão complexos.

    Então, pessoas são irrelevantes?

    Lógico que não. O oposto é verdade. Você deve energizar pessoas todo o tempo e de todas as formas possíveis. Fornece-las propósito, autonomia e oportunidades contínuas de desenvolvimento é fundamental para desenvolver e aprimorar os seus sistemas de trabalho.

    Aqui entra o papel da liderança. Quando um líder é fraco e cultiva sistemas de trabalho ruins, a colheita será pífia. Mesmo com pessoas brilhantes.

    Ao invés, se você como líder desenha bons sistemas de trabalho, você abre espaço para o desenvolvimento das pessoas e você terá resultados positivos para a sua gestão e a sua organização.

Os gerentes não são confrontados com problemas independentes entre si, mas com situações dinâmicas que consistem em sistemas complexos de problemas de mudança que interagem entre si. Eu chamo essas situações de bagunça. Os problemas são extraídos das bagunças pela análise. Os gerentes não resolvem problemas, eles gerenciam bagunças, Russel Ackoff

 

 

 

 

 

 

 

 

 

Retrospectivas ágeis sem frescuras

~ Marco Mendes ~ Deixe um comentário

Avaliar se projetos e times estão indo bem é uma ideia já antiga, popularizada em corpos de conhecimento como o PMBOK (Project Review) ou RUP (Iteration Review). E com o crescimento dos métodos ágeis e do SCRUM, o termo retrospectiva ganhou muito popularidade nesse século (Sprint Review).

No Brasil vemos muitos times praticar retrospectivas. Ao mesmo tempo, vemos que muitas dessas reuniões estão focadas puramente em avaliar aspectos motivacionais das pessoas e capturar sentimentos de ansiedade, irritação, desespero ou melancolia.

O foco está primeiro nas pessoas e depois no trabalho. E essa abordagem é perigosa por vários motivos. Enumero alguns motivos aqui:

  1. Se você enquanto Agile Coach não tem formação em psicologia, você pode fazer mais estragos do que melhorias ao tentar promover mudanças comportamentais baseadas em percepções de problemas do campo do subjetivo.
  2. Tentar “melhorar” aquele garoto enxaqueca do seu time não é algo que possui receita, resultado garantido e muito menos tempo definido. O contrário é verdade. Converse com qualquer psicologo sobre o assunto e se surpreenda com o tempo necessário para trabalhar frustrações do campo do subjetivo. Definitivamente, não é algo que você possa colocar em um cartão e executar em uma sprint.
  3.  A sua reunião pode virar uma sala de lamentação, onde desenvolvedores passivo-agressivos vão ficar expondo lamúrias e riscando post-is sem parar para lidar com a agressividade reprimida.
  4. O papel conceitual de uma retrospectiva é o melhorar o seu sistema de trabalho. Se a reunião não cumpre esse objetivo, ela não é um ciclo de feedback de verdade para o sistema adaptativo complexo de trabalho.

Veja. Não estou dizendo que pessoas não são importantes. O contrário é verdade. E é justamente por isso que precisamos respeitar os adultos que estão ali convidados por você e honrá-los com uma reunião que funcione.

Retrospectiva Sem Frescura

Para isso vamos apresentar a Retrospectiva Sem Frescura, centrada no trabalho e respeitando as pessoas ali presentes.

Você deve conduzir uma retrospectiva olhando para o seu quadro Kanban de histórias. Observe a coluna de trabalho realizado. Para cada história ali depositada, pergunte:

  1. Os nossos clientes ficaram satisfeitos com essa história?
  2. Esse história atendeu aos parâmetros de qualidade, custo, e demais critérios de aptidão dos clientes internos e diretoria.
  3. Essa história fluiu bem ao longo do nosso quadro Kanban? O tempo de entrega dessa história foi boa? Ou tivemos impedimentos, bloqueios ou esperas em filas?

Observe também que essas perguntas vão trazer as insatisfações pessoais, com certeza. Por exemplo, se um desenvolvedor precisou esperar 3 dias para ter uma permissão em um banco de dados específico, a insatisfação concreta irá emergir e poderemos ter atos de liderança para endereçar essa situação específica. Mas a agenda é motivada pelo trabalho e para o trabalho, respeitando as pessoas e buscando soluções objetivas para melhorar aquele trabalho.

E se você nem consegue responder ao item 1 do roteiro acima, o seu trabalho está com problemas graves. Você está conduzindo uma retrospectiva onde não houve entrega de valor para os seus clientes. É um sintoma de empresas que focam mais em iniciar coisas do que terminar. Ao invés, pare de começar e comece a terminar.

O passo a passo – Retrospectiva Sem Frescuras

  1. A revisão é feito em frente ao quadro Kanban. Ela foca nos itens completados.
  2. Ela coleta observações, ocorrências, falhas, ideias a serem exploradas e políticas atuais.
  3. Ela categoriza o feedback coletado e define ações de melhoria no sistema de trabalho.

Gerencie o trabalho e não as pessoas

Corpos de conhecimento com o método Kanban e o Management 3.0 nos ensinam que a gestão deve ocorrer sobre o trabalho e não sobre as pessoas.

Ao focar no trabalho, você cria pragmatismo e honestidade com a sua empresa. Você cria foco também para lidar com os problemas e frustrações. E você respeita também o direito das pessoas estarem irritadas e ainda assim entregar um trabalho honesto e apto para o propósito da sua organização e seus clientes.

 

Scrum ainda mais medíocre – Mais disfunções ágeis e mais antídotos

~ Marco Mendes ~ Deixe um comentário

Publiquei na semana passada um post sobre disfunções ágeis comuns na implementação do framework Scrum.

São elas.

  1. Reunião diária Zombie
  2. Trabalho empurrado
  3. Métricas míopes
  4. Servidão ao backlog
  5. Escopo fixo e prazo aberto

Apontamos também alguns antídotos para essas disfunções, que são:

  1. Pergunte ao quadro Kanban
  2. Trabalho puxado
  3. Métricas acionáveis
  4. Gestão do upstream
  5. Fluxo contínuo e MVPs

Caso ainda não tenha lido recomendo a leitura para contexto.

Dando sequência ao tema de disfunções ágeis, relato aqui mais disfunções ágeis que podem drenar todo o dinheiro da sua iniciativa ágil como um chupa-cabra de métodos ágeis. Mais à frente, apresentamos antídotos para esses problemas.

Mais 5 disfunções ágeis

  1. Critério de preparado (Ready) ausente ou mal especificado

Um problema comum em vários times que operam Scrum é não estabelecer um acordo claro para aceitar um requisito e iniciar a sua construção. Isso se manifesta com reuniões de planejamento longas e cansativas e, pior, problemas de entendimento que acompanham a sprint e um número excessivo de defeitos de negócio em ambientes de produção.

  2. Critério de aceite (Acceptance) ausente ou mal especificado

É também comum quando POs novatos ou que estendem a confiança ingenuamente não definem os critérios de aceite funcionais e não-funcionais externos, como por exemplo a usabilidade, performance ou segurança.

“O óbvio é individual”, já disse um sábio certa feita. Assumir que o time de engenharia de produtos irá incorporar aspectos de qualidade porque aquilo é óbvio é uma decisão ingênua.

3. Critérios internos de qualidade ausentes

Quando desenvolvedores e QAs olham apenas para os requisitos funcionais, uma dívida técnica será naturalmente introduzida dentro do sistema. A razão é a entropia crescente nesses sistemas complexos.  Exemplos incluem:

  • Ausência de automação de testes
  • Códigos-fonte sujos (mal-cheiros)
  • Arquiteturas de software erodidas
  • SQLs ineficientes
  • Problemas de segurança

Se um time não age proativamente e introduz políticas para pagamento permanente da dívida técnica, os sistemas irão apenas degradar ao longo do tempo e eventualmente gerarem problemas gravíssimos para suas áreas de negócio.

4. Ausência de folgas (Slack) e previsibilidade inconsistente

Tom de Marco escreveu um livro muito instigante em 2001 (Slack) mostrando a estupidez da hiper-otimização dos trabalhadores do conhecimento e os seus efeitos ruins para as pessoas e também para a própria organização em médio e longo prazo.

Nicholas Taleb também nos adverte, de forma ainda mais contundente no seu livro Antifragilidade – Coisas que se beneficiam do caos, da fragilidade inerente de organismos hiper-otimizados. A natureza e os sistemas complexos amam redundâncias.

Donald Reinertsen, outro grande pensador, nos mostra também que sistemas de trabalho ocupados afetam brutalmente e negativamente a previsibilidade de entrega de novas funcionalidades.

Livro Slack - Tom de Marco

Livro Antifragilidade - Taleb

Princípios de Fluxo no Desenvolvimento de Produtos

Assumir que alguém trabalha exatamente 7 ou 8 horas por dia e tentar alocar o esforço de pessoas como se fossem máquinas é ruim economicamente para a organização, psicologicamente para as pessoas e também para a previsibilidade de entregas.

Em linguagem simples, você observa essa disfunção através de sprints “que falham”, i.e, não entregaram todo o “escopo” porque as pessoas não “trabalharam” de forma eficiente. Ou titica de galinha sobre esterco de vaca.

5 – Heroísmo. Ou síndrome de Tanus.

Outra disfunção comum é esperar que pessoas e times ágeis irão ter comportamentos heróicos e irão fazer o que for necessário para bater as “metas” definidas pela gerência.

O heroísmo na construção de produtos digitais é um fenômeno estudado há décadas. E a “má notícia” é que não existem heróis. Você não está em um filme de espionagem onde hackers com “intelecto avançado” teclam um monte de comandos mágicos e o sistema começa a operar. E até nos filmes mais recentes, basta alguém estalar os dedos e metade dos heróis vai embora.

Modelos de maturidade mais modernos, como por exemplo o excelente Kanban Maturity Model, mostram que o heroísmo é um sintoma de serviços de baixa maturidade (ML1). Não é algo sustentável em médio e longo prazo e impede a criação de serviços previsíveis e aptos para o propósito de negócio.

Mais Antídotos

1. Gestão do Upstream (para o critério de Preparado  mal especificado)

A gestão de upstream é uma técnica descrita no KMM (Kanban Maturity Model) e assunto central do livro Essential Upstream Kanban.

Livro Essential Upstream Kanban

Entre o Upstream (território do PO) e o Downstream (território da engenharia e Scrum Masters) existe o ponto de compromisso que precisa ser bem estabelecido através de políticas explícitas, prática geral de todo sistema Kanban maduro.

2. Compromisso em duas fases (Two Phase Commit)

Sistemas de trabalho bem estruturados devem ter não apenas o ponto de compromisso bem estabelecido para iniciar o trabalho. Devem ter também o ponto de compromisso onde o trabalho seja aceito. E para isso precisamos ter políticas explícitas indicam como o trabalho deve ser entregue para ser considerado como finalizado.

Se você quer que o seu copo de água seja servido em copo de vidro, com duas pedrinhas de gelo e uma rodela de limão siciliano, explicite isso no começo do jogo. O combinado não é caro.

O Two Phase Commit é uma técnica Kanban que reduz, semana após semana, a ambiguidade para iniciar e fechar um trabalho do conhecimento. Ela permite que você crie critérios de preparado e de aceite incrementais e que funcionem na sua realidade objetiva.

3. Critérios internos de qualidade

Ninguém em sã consciência pede para um cozinheiro não lavar as verduras para apressar o preparo dos pratos. E provavelmente cozinheiros profissionais não aceitariam essa proposta estranha. Lavar as verduras é dever ético e de higiene em uma cozinha profissional.

Da mesma forma, nenhum desenvolvedor deveria negociar aspectos básicos da higiene do seu código no dia a dia. Refatorar e fazer testes de unidade devem ser parte integrante e diária do trabalho. Como tomar banho e escovar os dentes. E não um trabalho adicional que deveria ter permissão gerencial.

Lógico. Falar isso é fácil. E reconheço que isso é ainda muito difícil em ambientes abusivos onde metas de prazo são impostas de cima para baixo e não descobertas pela vazão do time.

Mas é dever ético de qualidade de um time expor e brigar por seus critérios internos de qualidade. Git Pull Requests, Pair Programming, Mob Programming, Testes de Unidade, Refatoração, entre outras práticas, são exemplos nesse sentido.

E se você quiser se armar com argumentos sólidos para conversar com a sua chefia, recomendo dois clássicos a respeito do sempre incansável Uncle Bob, um dos signatários do Manifesto Ágil de 2001.

4. Limitar o trabalho em progresso, políticas explícitas e gestão do fluxo (para atacar o problema de previsibilidade)

Times sem políticas de limitação do trabalho e outras políticas explícitas são facilmente abusados no seu dia a dia. Um dos papéis de um sistema de trabalho é conhecer e estabelecer a capacidade de trabalho apropriada para um time em um contexto real de forma a:

  • Reduzir os prazos de entrega
  • Reduzir a variabilidade.

Fato curioso é que o tempo médio de entrega é inversamente proporcional ao volume de trabalho em progresso, como já nos mostrou John Little ainda nos anos 60 na sua Lei de Little.

Quando você introduz sistemas Kanban sobre times que estão operando o framework Scrum, você ganha consciência da utilização de trabalho mais apropriada para aquele time e evita problemas de sobrecarga que se manifestam como engarrafamentos (muita coisa para fazer, muito estresse, pouca vazão e resultados pífios).

5. Limitar o trabalho em progresso, políticas explícitas e gestão do fluxo (para atacar o problema de heroísmo)

O heroísmo é sintoma de um sistema de trabalho frágil, i.e., onde as metas são impostas de cima para baixo sem conhecer a vazão possível e ideal dos times. É um sintoma de um sistema desequilibrado, onde medições não são realizadas consistentemente, onde políticas corretas estão ausentes e sistemas de feedback não estão instalados.

Novamente, o mesmo antídoto aplicado no item 4 pode ser usado para identificar as causas raízes que levam aos atos de heroísmo, introduzir hipóteses de melhoria e com base no pensamento científico testar e manter as hipóteses que melhorem o sistema de trabalho. Através de um processo contínuo de melhorias através da abordagem de mudanças evolucionárias, criamos um sistema robusto de trabalho em médio e longo prazo.

A mensagem desse post é simples. Faça uso do sistema de gestão de mudanças Kanban para melhorar o seu trabalho como Scrum Master.

 

Scrum Medíocre – 5 Disfunções ágeis e seus antídotos

~ Marco Mendes ~ 1 comentário

O Scrum é o framework ágil mais usado na comunidade ágil. Desenhado ainda nos 90, ele trouxe um guia acionável para organizar e entregar projetos com ideias muito boas tais como:

  • Ciclos PDCA de curto prazo (Sprints) e ritos para sistematizar esses ciclos (planejamento de sprint, reunião diária, revisão e retrospectiva)
  • Papel de facilitador do método, combinando funções de processo e de gestão (Scrum Master)
  • Papel de interface com áreas de negócio e conceito mais claro de produto (Product Owner)
  • Times multidisciplinares (ao invés de pessoas que trabalham sozinhas e não colaboram).

Entretanto, a forma como o Scrum foi implementado em muitas organizações lá fora e no Brasil criou um monstrinho que apelido aqui de Scrum Medíocre. É fácil reconhece-lo através de disfunções comuns. Enumero 5 dessas disfunções ágeis aqui.

Reunião diária zombie

SM: – João, o que você fez ontem?
SM: – E você, Maria, o que fez ontem?
SM: – José, meu filho, me fala o que fez ontem?

João, Maria e José, como zombies, respondem de forma catatônica às perguntas do Scrum Master comando e controle. Eles estão com sono, não querem estar ali em pé, detestam aquele momento e estão contando os minutos para voltar às suas mesas e colocar o fone de ouvido.

Qual o problema aqui? Foco nas pessoas e não no trabalho.

Trabalho empurrado

Primeiro dia da Sprint 
PO: – Time, nos temos 7 histórias que devem ser completadas em 10 dias úteis. Ordens da chefia. João, você pega as histórias 1 e 2. Maria, você que é sênior irá trabalhar nas histórias 3, 4 e 5. José, conto com você para cuidar das histórias 6 e 7.

Ultima dia da Sprint
O time não entrega nem 50% do trabalho empurrado e é culpado pela sua performance ruim. Uma reunião de retrospectiva é chamada onde o time tem a sua atenção chamada pelos problemas de desempenho.

Primeiro dia da próxima sprint
A mesma história se repete.

Métricas míopes

Tudo o que o time conhece são sprints e suas métricas locais. O time estima com planning poker, tamanho de camisa e afins. E ele mede a sua produtividade local com gráficos de burndowns.

Mas se você pergunta a qualquer um, até mesmo o PO, quanto tempo demora em média uma demanda para fluir da chegada até a produção, a resposta é nula. Nenhuma métrica acionável de cliente é usada pelo time.

Servidão ao backlog

O backlog é cultuado como se os desejos ali colocados fossem ordens de Deus. O PO e o time não fazem nenhum engenharia de valor e o foco é puramente centrado na entrega de funcionalidades. O % de completude de backlog é usado como métrica de sucesso da iniciativa, centrada puramente em escopo.

Projetos centrados em escopo fixo e prazo aberto

O escopo, ao invés do tempo, é o principal guia para organizar quando um projeto deve terminar. Se um time trabalha 3 meses e o escopo não foi cumprido, novos sprints são abertos até que o escopo seja completado. O conceito de prazo fechado e MVPs são completamente ignorados. O dinheiro é drenado como em projetos tradicionais pelo modelo mental da fixação ao escopo.

Muitas dessas disfunções tem sido amplamente debatidas por agilistas que assinaram o Manifesto Ágil como Martin Fowler, Robert Martin (Uncle Bob) e Allistair Cockburn.

Juntas, essas disfunções criam um cenário terrível de agilidade burocrática que drenam o dinheiro do seu time como um tipo de chupa-cabra do mal.

chupacabra

Antídotos ao Scrum Medíocre

A boa notícia é que você pode incorporar ideias antifrágeis ao seu sistema de trabalho para sair da mediocridade Scrum.

Pergunte ao quadro (Antídoto para a Reunião Diária Zombie)

Ao invés de perguntas para as pessoas sobre o que elas fizeram ontem, pergunte ao quadro. Faça a reunião diária com o quadro Kanban aberto. Navegue da direita para a esquerda (e não da esquerda para a direita). Você quer terminar itens mais que começar novas coisas e aumentar de forma ingênua o trabalho em progresso.

Para cada cartão navegado, pergunte se existem gargalos. Exemplos de gargalos incluem itens bloqueados, tarefas que estão há muito tempo no quadro ou limites ao trabalho em progresso. Quando um gargalo é encontrado, você incentiva ações do time para desbloquear itens bloqueados ou atuar sobre itens parados. Mostre ao time que estamos interessados em fazer o trabalho fluir.

Em resumo. Não pergunte o que o João, Maria e José fizeram ontem. Queremos gerenciar o trabalho e não as pessoas. Essa pequena mudança de comportamento faz o time perceber que você está preocupado com a entrega. E não microgerenciamento do trabalho deles.

Trabalho puxado (Antídoto para o trabalho empurrado)

Ao invés de um trabalho empurrado de forma comando e controle para o time, o PO deve apenas alimentar uma coluna de pronto para começar.

E o time deve puxar o trabalho sob demanda, um item por vez. Ou seja, o time se compromete com poucas coisas. Isso cria foco para o time e reduz sua ansiedade. O compromisso estabelecido cria um trabalho que deve fluir pelo sistema e com a ajuda de reunião diária efetiva irá fluir.

O PO observa a vazão média de itens por  quinzena ou mês. E essa vazão permite que ele comece a compreender a dinâmica do time e a sua capacidade de entrega. E então ele fornece itens dentro da vazão possível pelo time. A realidade deve guiar o PO e não fantasias imaginárias de produtividade.  O trabalho puxado é o melhor aliado do PO para aumento da eficiência do seu time.

Métricas Acionáveis (Antídoto para métricas míopes)

O PO, SM e time devem observar duas métricas centrais na ótica dos clientes que são:

  • O tempo de ciclo das entregas (lead time)
  • A vazão das entregas (taxa de entrega de demandas em base semanal ou quinzenal)

Por quê?

Porque clientes querem saber quanto tempo um time vai demorar para fazer um trabalho e quantos itens são entregues por período (ou sprint).

Em última instância, essas métricas observam se o seu sistema de trabalho é solido, i.e, como o trabalho flui desde o momento do compromisso até o momento do aceite. Como o tempo médio, sua distribuição e a vazão estão se comportando dentro de cada etapa do seu fluxo de trabalho.

Ou seja, essas métricas permitem que você analise gargalos, critérios de aptidão para os seus clientes e lhe permitem estabelecer previsibilidade de trabalhos futuros. Se um time descobre, por exemplo, que o seu time demora 9 dias para entregar um trabalho comprometido, você consegue estabelecer compromissos baseados na realidade objetiva do histórico do seu time.

Gestão do Upstream (Antídoto para a Servidão ao Backlog)

A gestão do upstream é uma técnica onde o PO pode organizar um quadro Kanban específico para identificar, realizar processos de triagem, engenharia de valor e entregar itens prontos para a execução para o time de desenvolvimento de produtos.

Os processos de “triagem” de ideias podem eliminar demandas antes de irem para o time. Essa mortalidade é positiva. Isso gera economia de tempo e consequentemente de custo.

Além disso, o upstream também busca entender a melhor cadência para entregar os itens para o time de desenvolvimento de produtos e qual deve ser a taxa de entrega de itens em base periódica conforme a taxa de consumo viável do time de desenvolvimento. Um quadro de upstream que entrega trabalho além da capacidade de vazão do time de execução (chamado de downstream) gera um backlog  extenso. E essas demandas se tornam obsoletas enquanto aguardam serem atendidas

Fluxo Contínuo e MVPs (Antídoto para projetos centrados em escopo fixo e prazo aberto)

O conceito de fluxo contínuo é um antídoto que pode ser usado em times de maior maturidade. E é incrivelmente poderoso. Ao invés de fixação em projetos com escopo fixo que levam invariavelmente a conflitos terríveis entre times e clientes, buscamos entregas de fluxo contínuo.

Trabalhar em fluxo contínuo significa que um time pega um item quando tem capacidade disponível, se organiza para entregar o item de ponta a ponta dentro do menor tempo de ciclo possível e agrega valor de negócio incrementalmente.

Trabalho com fluxo contínuo em TI não é trivial e requer também que o custo de transação para implantar em produção seja baixo. Isso muitas vezes requer arquiteturas centradas em microsserviços e práticas DevOps CI/CD bem estabelecidas. Mas se você tem as premissas apropriadas, pode ser uma abordagem muito interessante.

O Catálogo de Antídotos do Método Kanban

Cada um desses antídotos faz parte do método Kanban. O método Kanban não é uma alternativa ao Scrum. Ao invés, ele é uma ferramenta para você introduzir mudanças no seu sistema de trabalho centrado em Scrum. Ele é uma lente de análise para você observar o trabalho do seu time, detectar fragilidades e melhorar continuamente o seu sistema de trabalho. Da fragilidade para a resiliências, robustez e então antifragilidade.

O método Kanban lhe fornece esteróides naturais para você introduzir estressores no seu Scrum e sair de um Scrum medíocre para um Scrum de alta maturidade.

Quer melhorar o seu Scrum? Adote práticas Kanban.

“The fragile wants tranquility, the antifragile grows from disorder, and the robust doesn’t care too much”, Taleb.

 

O novo pós-normal do gestor e líder de times – Complexidade, Caos e Contradição

~ Marco Mendes ~ 1 comentário

Se você é um gestor ou líder de time e tem mais de 30 anos, provavelmente você foi educado em métodos de gerenciamento modernos. Esses métodos são baseados em conceitos chave como progresso, eficiência e modernização.

Algumas consequências desses pressupostos mentais podem ser sintetizadas nas dimensões abaixo:

  • Visão de sistemas: Os fenômenos são complicados, i.e., possuem muitas partes interconectados mas a relação entre elas é conhecida e pode ser descrita a priori.
  •  Planejamento: O planejamento é possível e pode ser realizado por ferramentas como cronogramas e redes que avaliam interdependências.
  • As relações possuem causa e efeito óbvias e instrumentos clássicos de gestão de risco são de grande auxílio para prever e evitar riscos.
  • Os prazos podem ser determinados por estimativas.
  • As pessoas precisam ser monitoradas para que a sua eficiência possa aumentar. A ociosidade no trabalho é danosa e buscamos portanto eficiência de recursos.
  • Relações de trabalho: São estáveis e baseadas na CLT.
  • Os processos são prescritivos, i.e, temos receitas claras do que fazer em termos de atividades, passos, etapas e papéis envolvidos.
  • O avanço ocorre fundamentalmente através das melhores práticas da indústria.
  • As mudanças são tipicamente revolucionárias, i.e., conduzidas através de iniciativas de grande porte conhecidas como projetos.
  • Empresas são organizadas em equipes com especialistas funcionais.
  • Os sistemas de informação de TI são monolíticos e feitos para durar, resultados de grandes projetos.
  • Aquisição de informações: Entrevistas um-para-um e documentação abrangente.
  • Profissões de gestão: Gerentes de projetos, gerente de qualidade, superintendentes.

Pare por um momento. Lembre como corpos de conhecimento como ISO, COSO, COBIT, CMMI, RUP, ITIL, PMBOK são organizados. A própria profissão e identidade do gerentes de projetos foi moldada por esses mecanismos.

De repente,  2020

O espírito do nosso tempo, aquela palavra legal do alemão chamada zeitgeist, não é mais do progresso, eficiência e modernização absolutos. Avançamos do moderno para o pós-moderno e do pós-moderno para o pós-normal.

Se o progresso, eficiência e modernização eram os lemas do mundo moderno, no mundo pós-moderno temos a relativização, pluralidade de conceitos e a individualidade com conceitos dominantes. E no mundo pós-normal temos a complexidade, caos e contradição como conceitos dominantes.

_89646838_hi020115854

Complexidade 

Sistemas complexos tem incertezas substanciais que não podem ser gerenciadas como ‘riscos’. Eeles tem uma multiplicidade de perspectivas legítimas.

Um sistema complexo em rede está cheio de incertezas, múltiplas perspectivas e propenso a comportamentos turbulentos que às vezes podem resultar em caos.

O clima, epidemias como o COVID-19, organismos biológicos, ecossistemas, organizações sociais, culturas humanas, a linguagem, o cérebro, serviços de saúde e até mesmos sistemas de informação de TI são exemplos de sistemas complexos.

Caos 

O caos não significa aleatoriedade. O caos é o resultado de muitas variáveis ​​independentes interagindo de várias maneiras diferentes em um sistema complexo em rede. Pequenas perturbações no sistema podem levar a consequências imprevisíveis e que somente podem ser estuados a posteriori.

Por exemplo, alguém pode comer um morcego em uma cidade na China e o seu emprego é ameaçado porque você e sua empresa estão em distanciamento social forçado. Isso é  o chamado “Efeito Borboleta”.

Contradição

Um sistema complexo tem muitas posições que são logicamente inconsistentes. Sistemas complexos à beira do caos ainda mais. As contradições não podem ser resolvidas. Elas só podem ser integradas e transcendidas. Em outras palavras, as contradições precisam ser sintetizadas e requerem a formulação de uma nova posição que incorpore a maioria das várias posições diferentes.

A contradição geralmente fornece os primeiros sinais de que um sistema está se movendo em direção à complexidade, caos e, eventualmente, para a pós-normalidade.

A gestão no tempo pós-normal

Em áreas onde o trabalho do conhecimento é dominante, não vemos mais ofertas abundantes de vagas para “Gerente de Projeto” ou “Gerentes de Qualidade”. Observo várias pessoas da minha rede, especialmente acima de 40 anos, perplexas e indignadas com esse movimento.

E, pior, aqueles que são demitidos de suas empresas simplesmente não conseguem se reposicionar. Ou precisam se reposicionar vários meses depois por salários menores do que tinham anos atrás. Algo mudou nas profissões do trabalhador do conhecimento.

As coisas nos tempos pós-normal não podem ser “gerenciadas” no sentido clássico da palavra.  Elas precisam ser, ao invés,  navegadas.

Para entender isso, vamos observar as consequências dos pressupostos da pós-normalidade podem ser sintetizados nas dimensões abaixo:

  • Visão de sistemas: Os fenômenos são complexos, i.e., possuem muitas partes interconectados e a relação entre elas não é conhecida a priori. Ela somente pode ser descrita em retrospectiva.
  •  Planejamento: O planejamento não é possível e agora precisa ser acomodado por instrumentos dinâmicos que absorvem fluxos variáveis e contínuos como por exemplo um Sistema Kanban.
  • As relações não possuem causa e efeito óbvias. O uso de narrativas é fundamental para entender como atuar em cenários de imprevisibilidade
  • Os prazos não são determinados por estimativas. #NoEstimates é o novo pós-normal. Ao invés, trabalhamos com previsibilidade (Forecasting).
  • As pessoas não devem  ser gerenciadas. Ao invés, devemos gerenciar o sistema de trabalho e permitir que as pessoas se auto-organizem. Ao invés de eficiência de recursos humanos, buscamos eficiência de fluxo.
  • Os processos não são prescritivos, eles são descritivos. O contexto é chave para saber o que fazer.
  • O avanço ocorre fundamentalmente através de práticas contextuais e de aprendizados por retrospecto através de narrativas.
  • As mudanças são evolucionárias, i.e., devem reduzir a resistência a mudança e incorporar visões contraditórias para permitir a criação de antifragilidade. A noção de grandes transformações e projetos está morrendo.
  • Empresas são organizadas em equipes com generalistas especialistas. Os papéis são fluidos e não mais fixos.
  • Os sistemas de informação de TI são baseados em serviços ou microsserviços, resultados de entregas de fluxo contínuo. Eles são desenhados para mudar.
  • Aquisição de Informações: Oficinas, Open Spaces, Aprendizado 3.0, Design Thinking e espaços que permitam que a contradição surja e possa ser integrada.
  • Relações de Trabalho: Dinâmicas, baseadas em empreendimentos, contratos e resultados ganha ganha.
  • Profissões de gestão: Empreendedores, Líderes, Mentores, Agentes de mudança e Agile Masters. As profissões clássicas da gestão estão morrendo e as pessoas que se agarrarem a elas podem talvez sejam varridas do mercado de trabalho.

Corpos de conhecimento como o Management 3.0, desenhado para gestão em ambientes complexos, e o Método Kanban, desenhado para gestão de mudanças evolucionárias, estão mais bem preparados para lidar com os tempos pós-normais.

Para o trabalhador do conhecimento e da inovação, é o momento de reflexão e questionar os seus pressupostos. O caminho que nos trouxe até aqui pode ser não ser o caminho que nos levará para o futuro.

Como já dizia Alvin Toffler ainda no século passado.

Os analfabetos do próximo século não são aqueles que não sabem ler ou escrever; mas aqueles que se recusam a aprender, esquecer, reaprender e voltar a aprender.

 

Kanban e Devops: Bons sozinhos e ainda melhor se juntos.

~ Marco Mendes ~ Deixe um comentário

Dois movimentos que tem ganhado muita tração nos últimos anos na TI são a Cultura DevOps e o Método Kanban.

Já falei sobre a Cultura DevOps aqui nesse espaço em vários posts organizados nessa página. Mas é sempre bom reforçar o conceito de DevOps. Vamos lembrar dos seus três caminhos essenciais.

O Tao do DevOps

  1. O princípio do fluxo, que acelera a entrega do trabalho do Desenvolvimento para Operações e então para os nossos clientes
  2. O princípio do feedback, que nos permite criar um sistema de trabalho cada vez mais seguro;
  3. O princípio de aprendizado contínuo e experimentação, que promove uma cultura de alta confiança e uma abordagem científica para a melhoria organizacional como parte de nosso trabalho diário.

Já o Kanban é um método de gestão de mudanças que busca promover a melhoria de maturidade para o trabalho do conhecimento. No caso particular da TI, um tipo de trabalho de conhecimento, o método Kanban te ajuda a entregar e sustentar software com menor fragilidade.

Gene Kim, um dos autores do excelente livro e bíblia do DevOps chamado O Manual do DevOps  fez uso de várias práticas gerais do método Kanban para definir os princípios e guiar como devemos adotar DevOps na práticas nas nossas organizações.

O purgatório do DevOps

Em algumas empresas onde já rodei diagnósticos de maturidade DevOps vi desenvolvedores muito habilidosos insistindo em implementar ferramentas DevOps pelo culto à tecnologia.

Frases que já ouvi se parecem com o seguinte:

“Temos pipelines de CI implementados para todo o nosso código .NET”

“Temos aqui o JUnit, Jenkins, Terraform e Ansible nos ajudaram em nossos fluxos CI/CD. Nosso DevOps está acelerado”

“Estamos criando automação de testes de unidade em nossos branches. E olhe só, eles são disparados automaticamente quando um commit é feito no branch principal”. 

Quando pergunto sobre como isso ajudou a reduzir o tempo de entrega (Lead Time) ou a taxa de defeitos, ouço um silêncio abissal. Os times não tem medições e não tem a mínima preocupação com isso em suas implementações.

DevOps … de verdade

A mensagem é clara. Se alguém ainda acredita estar fazendo DevOps porque apenas criou um pipeline de uma ferramenta CI/CD  ou um conjunto de testes automatizados, essa pessoa está equivocada.

Qualquer ação que façamos e que não esteja conectada ao Tao do DevOps é ilusão (ou sendo bem rude; pura masturbação técnica).

Um teste Litmus para você avaliar a saúde da sua implantação DevOps é o seguinte:

  1. Se você não evidencia como o seu tempo médio de entrega das demandas está sendo reduzido, o seu movimento DevOps está meia boca.
  2. Se você não evidencia como você está criando sistemas mais seguros (menos frágeis), como por exemplo a redução de problemas graves em produção, o seu movimento DevOps continua meia boca.
  3. Se você não evidencia como a sua TI está cada vez mais preparada para suportar hipóteses de negócio do conceito à produção, o seu movimento ainda estará meia boca.

O Método Kanban para acelerar Implantações DevOps

O método Kanban tem no seu núcleo as ferramentas conceituais para você acelerar a sua iniciativa DevOps.

Ele se baseia no mecanismo de mudanças evolucionárias, i.e, pequenas mudanças que são aplicadas continuamente sobre um sistema de trabalho para aumentar a robustez desse sistema.

O método Kanban possui seis práticas genéricas. Todas elas são úteis para implantação DevOps, mas destaco três aqui nessa postagem.

1. Gestão do fluxo

O fluxo é o movimento do seu  trabalho de TI (demandas, projetos, incidentes, erros). O método Kanban diz que devemos gerenciar o trabalho através de entregas previsíveis e suaves. E sempre usar dados para medir a sua maturidade.

Essa prática Kanban está profundamente conectada com o primeiro caminho do DevOps. E uma métrica central do sistema Kanban, o Lead Time, pode te ajudar claramente a mostrar a eficiência de sua implementação DevOps.

Quando medimos continuamente o Lead Time e a variabilidade dessa medida em nossas implantações DevOps, você passa a ter uma ferramenta poderosa para mostrar valor e agilidade de negócio de forma concreta. No wishful thinking!

Como exemplo, pude acompanhar uma empresa que reduziu o seu lead time das demandas de 30 para 20 dias ao longo de alguns meses com a introdução consistente de estressores DevOps no seu sistema de trabalho. Até o mais céticos dos gerentes envolvidos deu o braço a torcer.

2. Laços de Feedback

O método Kanban estimula que tenhamos cadências específicas para avaliar a nossa maturidade, sempre dirigidas por dados. Essas cadências promovem a colaboração entre as pessoas, aprendizado e melhorias.

Por exemplo, em reuniões como a retrospectiva de time discutimos como está a nossa previsibilidade das nossas demandas, variabilidade do tempo de entrega e taxa de defeitos. Com isso, podemos avaliar, periodicamente, se as nossas ações tecnológicas e ferramentas estão ajudando o nosso sistema a fluir. A colaboração aumenta e isso é pilar central para a criação de uma cultura DevOps.

3. Políticas explícitas

Quando encontramos um sistema de trabalho ruim, podemos descobrir e introduzir políticas que nos ajudam a reduzir as fragilidades nesse sistema.

Por exemplo, pense em algumas dessas ideias DevOps:

  • Revisões por pares;
  • Git Merge Requests;
  • Automação de testes de unidade
  • Critérios de aceite para promoção de builds;
  • Testes de estresse na infraestrutura.

Essas ideias podem ser representadas no sistema Kanban a partir de políticas de trabalho. Essas e outras políticas podem ser introduzidas sob demanda para eliminar as fraquezas no seu ambiente e criar um organismo cada dia mais forte.

Como um outro exemplo, pude acompanhar um time com baixa maturidade de arquitetura e qualidade que avaliou as fragilidades o seu sistema de fluxo e introduziu uma política de revisão obrigatória do código por pares. Essa política, tornada obrigatória pelo próprio time, conseguiu trazer estabilidade para as decisões arquiteturais e iniciar o pagamento da dívida técnica que esse time introduziu ao longo de seis meses de trabalho indisciplinado. O sistema Kanban ajudou o time a implementar a política e medir o efeito prático dessa política no lead time e taxa de defeitos em produção.

Resumo – Esteróides Naturais

Assim como o hormônio do crescimento ou a testosterona, anabolizantes naturais que ajudam humanos a se tornarem mais fortes e resilientes, podemos pensar que o sistema Kanban introduz formas legítimas de você melhorar a sua implementação DevOps.

Times DevOps que introduzem práticas Kanban no seu sistema de trabalho tem muito mais chance de sucesso. Eles reduzem a resistência à mudança, trabalham em práticas que fazem sentido no seu contexto, criam hipóteses de melhoria dirigidas pelo pensamento científico e operam sob o manto da antifragilidade.

 

 

Um panorama de métodos para aumentar a agilidade de negócios

~ Marco Mendes ~ Deixe um comentário

A agilidade de negócios se tornou um imperativo para muitas organizações. Inovar, criar produtos melhores, engajar mais clientes, encurtar o tempo de ciclo e reduzir desperdícios são alguns dos desafios que atormentam muitos gerentes nas empresas do Brasil e do mundo.

Os métodos ágeis tem sido usados, nos últimos 20 anos, para buscar entregar agilidade de negócios e apoiar gestores e times em linhas gerais. Mas se em 2001 podíamos enumerar os tipos de métodos ágeis em uma única mão, hoje o ecossistema ficou muito mais complexo. Os métodos, frameworks e práticas se multiplicaram e a simples escolha de qual método usar para apoiar as iniciativas de agilidade de negócio se tornou um desafio.

Nesse contexto, trago aqui uma compilação de 11 métodos ligados à agilidade de negócios e que tem obtido alguma visibilidade nos últimos anos.

Método Kanban

O método Kanban é uma abordagem de gerenciamento e melhoria de sistemas de fluxo e que busca criar um modelo evolucionário de aumento de maturidade nas organizações. Ele é uma alternativa a abordagens pesadas que introduzem mudanças radicais, reestruturações organizacionais e modelos prescritivos desconectados da realidade objetiva de cada organização.

O método Kanban foi criado por David Anderson a partir das suas experiências na Microsoft no começo do século e hoje é um dos métodos mais promissores na comunidade ágil.

Ele é mantido pela Kanban.University, que fornece uma trilha de cursos de formação e uma coleção de práticas provadas em centenas de organizações nos últimos 15 anos.

O método Kanban é acelerado por duas ferramentas conceituais poderosas:

  1. STATIK, que é uma abordagem sistêmica para introduzir sistemas Kanban em organizações. Um excelente artigo sobre ele pode ser encontrado aqui no LinkedIn do David Anderson.
  2. KMM, que é um modelo de maturidade organizacional baseado em sistemas Kanban.

Livro chave:

Management 3.0

O Management 3.0 é uma coleção de jogos, ferramentas e práticas em constante mudança para ajudar qualquer trabalhador do conhecimento a gerenciar o seu trabalho em organizações. Ele é uma maneira de ver os sistemas de trabalho em contextos complexos e melhorar esse sistemas.

O Management 3.0 é centrado em seis pilares.

  1. Energizar Pessoas: As pessoas são as partes mais importantes de uma organização e os gerentes devem fazer de tudo para manter as pessoas ativas, criativas e motivadas.
  2. Empoderar Equipes: As equipes podem se auto-organizar, e isso requer empoderamento, consentimento e confiança da gestão.
  3. Alinhar Restrições: A auto-organização pode levar a qualquer coisa e, portanto, é necessário proteger as pessoas, compartilhar recursos, dar às pessoas um propósito claro e metas definidas.
  4. Desenvolver Competências:  As equipes não podem alcançar seus objetivos se os membros da equipe não forem suficientemente capazes, e os gerentes devem, portanto, contribuir com o desenvolvimento de competências.
  5. Crescer a Estrutura: Muitas equipes operam em um contexto de uma organização complexa. E assim é importante considerar estruturas que favoreçam a comunicação.
  6. Melhorar Tudo: Pessoas, equipes e organizações precisam melhorar continuamente.

Publicado oficialmente em 2010 em Jurgen Appelo, o M3.0 teve grande receptividade no Brasil e hoje conta com uma forte comunidade de facilitadores e praticantes.  O portal Management 3.0 contém informações oficiais sobre esse método.

Livro Chave:

DevOps

O DevOps é um movimento cultural habilitado por práticas, técnicas e ferramentas e que tem por objetivo reduzir tempos de ciclo na entrega de produtos de TI, reduzir retrabalhos e habilitar a inovação organizacional.

O DevOps é baseado nos princípios do acrônico CALMS.

  • Cultura
  • Automação
  • Lean
  • Medições
  • Sharing (Compartilhamento de informações)

Na perspectiva mais pragmática, o DevOps é conhecido pelas seguintes práticas técnicas:

  • Automação de Testes
  • Integração Contínua
  • Entrega Contínua
  • Infraestrutura como código
  • DevSecOps
  • Engenharia do Caos

O portal IT Revolution, mantido por Gene Kim, um dos líderes desse movimento, possui uma coleção rica de informações e livros para você se aprofundar nessas práticas.

Mantenho também no meu blog diversos artigos sobre DevOps acessíveis a partir desse link: https://marco-mendes.com/devops/

Livro chave:

OKR – Objetivos e Resultados Chave

Esse é um método para lidar com o problema de definição e execução de metas. A definição de metas tradicional em exercícios de planejamentos estratégicos anuais, geralmente envolve declarações de objetivos criados em torres de marfim desconectadas da realidade operacional, mal comunicadas e cascateados de cima para baixo. Como consequência, a taxa de fracasso é alta.

O OKR, ao invés, é uma estrutura leve para definir e rastrear objetivos e seus resultados baseada em ciclos curtos (até 3 meses), envolvimento de todos na definição de metas e uma abordagem colaborativa para resolver e integrar dependências e conflitos.

O OKR traz como benefícios:

•Foco e disciplina: Poucos objetivos, gerando foco na organização;
•Alinhamento entre equipes: Interdependências funcionais entre os times integradas e resolvidas pelo método;
•Transparência: Todos os OKRs são públicos e possibilitam um alinhamento entre os objetivos e a visão da empresa;
•Gestão e Performance : Os OKRs são acompanhados em base periódica pelos próprios times que definiram as metas;
•Accountability: Todos passam a ser responsáveis por seus objetivos, com critérios claros de sucesso, conhecidos por toda a empresa;
• Centrado em dados: Os resultados chave são quantitativos e centrados em métricas acionáveis (ao invés de métricas de vaidade).
O portal What Matters traz uma rica coleção de recursos sobre OKR. No Brasil, recomendo também o portal do Felipe Castro, pioneiro de OKR no Brasil.

Livro Chave:

Modelo de Fluência Ágil

O modelo de Fluência Ágil ajuda os times a entender onde eles estão em termos de seus próprios objetivos, e entender o que é relevante para o seu contexto e necessidades específicas.
Esse modelo é resumido no seguinte esquema e define um conjunto de práticas e ferramentas que podem tornar uma organização fluente em um dos  possíveis níveis do modelo (nível 1 a 4).
O modelo de fluência ágil não é um modelo de maturidade, mas um mecanismo que permite que empresas possam escolher uma jornada de agilidade apta aos seus propósitos. Esse modelo usa outros métodos como Kanban, Scrum, XP ou DevOps dentro das suas jornadas específicas.
Um excelente artigo sobre o modelo é descrito aqui e foi escrito pelos seus criadores, James Shore and Diana Larsen. E você encontra muito material legal aqui no portal do Agile Fluency também.

Agile BOSSA Nova

O BOSSA é uma abordagem para agilidade organizacional, combinando as seguintes práticas de agilidade de negócio.

  • BB – Beyond Budgeting (orçamentos adaptáveis e flexíveis). Esse é um método de orçamentação moderno que habilita a tomada rápida de decisões em contextos complexos. Recomendo esse portal aqui com mais informações sobre o BB.
  • Open Space (abordagem para habilitar o poder da inovação de todos os funcionários),
  • Sociocracia 3.0 (estrutura organizacional flexível que permite a tomada de decisão descentralizada). Mais informações podem ser encontradas aqui no portal oficial.
  • Agilidade (aprendizado contínuo por meio de experimentos e feedback).
O portal Agile Bossa Nova traz uma rica coleção de recursos para quem quiser conhecer essa abordagem em mais detalhes.
Livro Chave:

Estruturas Libertadoras (LISA ou Liberating Structures)

As estruturas libertadoras são micro-estruturas narrativas que aprimoram a coordenação e a confiança entre as pessoas de uma empresa. Eles rapidamente estimulam a participação ativa de grupos de qualquer tamanho, tornando possível incluir e liberar o potencial de todos os participantes. Estruturas libertadoras são uma alternativas a abordagens de reuniões mais controladoras ou restritivas.
Em termos objetivos, elas são práticas para você conduzir encontros de trabalho no seu dia a dia. São técnicas de facilitação poderosas para apoiar grupos de trabalho a alcançar objetivos específicos em períodos curtos de tempo.
Um resumo dessas estruturas é mostrada na figura abaixo.
O portal do LISA contém uma explicação detalhada dessas estruturas. Existe também um APP móvel que considero muito útil e que disponível aqui na loja da Google Play.
Livro Chave:

Cynefin (leia Kinevin)

Esse modelo foi desenvolvido ainda em 1999 por Dave Snowden para ajudar líderes a compreender melhor o ambiente organizacional onde estão inseridos, e com base nisso, tomar decisões mais apropriadas.
Em termos práticos, o Cynefin é uma ferramenta de análise situacional e que permite qual o tipo de domínio onde as narrativas da sua empresa ocorrem. Os domínios possíveis estão listados abaixo (simples, complicado, complexo ou caótico). Dentro de cada domínio, o Cynefin sugere ferramentas apropriadas para aquele contexto.
O portal Cognitive Edge, mantido pelo Dave Swoden e associados, possui uma rica coleção de recursos e ferramentas ligadas ao ecossistema do Cynefin.

Modern Agile

O Modern Agile é uma comunidade para pessoas interessadas em descobrir melhores maneiras de obter resultados melhores para potencializar a agilidade de negócio. Ele aproveita a sabedoria de muitas indústrias, é orientado por princípios e não possui uma estrutura prescritiva.
Os princípios fundamentais dessa abordagem são resumidos na figura abaixo.
O site oficial do Modern Agile apresenta também as práticas emergentes dessa abordagem.

Heart of Agile

O Heart of Agile é um movimento liderado por Allistair Cockburn e que compila a experiência duas décadas de práticas ágeis dentro do modelo minimalista abaixo.
Esse movimento é um retorno à essência do manifesto ágil e pode ajudar você a descobrir a essência do Scrum, sem cair nas complicações e regras excessivas que foram adotadas pelos guias Scrum nos últimos anos.
O portal Heart of Agile conta também com uma coleção rica de recursos sobre esse movimento e apresentações do Cockburn.

Shiftup

O movimento Shiftup é uma nova marca de workshops, criada por Jurgen Appelo, que abraça a inovação contínua e a agilidade dos negócios como ponto de partida para a mudança organizacional.

O Shiftup é um programa para inovação contínua. Ele oferece um conjunto dinâmico de regras e modelos simples para as organizações se transformarem continuamente. Duas de suas regras fundamentais são colocadas abaixo.

  1. Cada idéia inovadora que evolui para um negócio de sucesso (seja um fluxo de valor individual ou um modelo de negócios inteiro) segue uma progressão natural dos estágios do ciclo de vida ou dos níveis de maturidade.

2.  A abordagem iterativa e incremental da inovação contínua (promovida pelos métodos Agile, Lean, Design Thinking e Lean Startup) se aplica a todos os fluxos de valor e modelos de negócios em todos os estágios do ciclo de vida.

O modelo conceitual é apresentado no esquema abaixo e esse e outros recursos de apoio se encontram no portal Shiftup.Work

Livro chave:

Lean Inception

O Lean Inception é um workshop colaborativo para alinhar um grupo de pessoas sobre o produto mínimo viável a ser construído. Ele é inspirado nos seguintes conceitos, modelos e processos:

  • Lean Startup e MVP
  • Iniciação do Processo Unificado da Rational
  • Design Thinking
  • User Centric Design

Similar à ideia do Design Sprint popularizada pela Google, o Lean Inception obteve uma boa tração no Brasil e tem sido usado por muitas empresas para realizar iniciações ágeis mais efetivas.

O portal do Paulo Caroli, pai do Lean Inception, contém muito mais informações ricas sobre esse workshop.

Livro Chave:

Vejo essa diversidade com bons olhos pois nenhum método é completo e perfeito.

“Não desenvolva apego a nenhum arma ou escola de combate”,
Samurai Miyamoto Musashi, Século 17

Eles são abstrações apenas e uma combinação efetiva deles pode ser interessante dentro da sua realidade. Espero que alguns desses modelos lhe possam ser úteis.

Existem muitos mais modelos de agilidade de negócio e ficaria feliz com feedbacks de outros modelos que não foram contemplados aqui.

Um feliz 2020 repleto de agilidade de negócio para você e até a próxima.
😀

Como usar o Método Kanban no Inferno com a ajuda do KMM

~ Marco Mendes ~ Deixe um comentário

Talvez você, leitor, trabalhe em um ambiente infernal. No trabalho do submundo podemos observar os seguintes sintomas.

  • Tudo é prioridade;
  • Você sempre tem mais trabalho para fazer do que a sua capacidade;
  • As entregas são sempre para ontem;
  • Ninguem assume responsabilidade e a cultura da culpa é permanente;
  • Existem brigas diárias de vaidade entre os velhos demônios que criaram o inferno onde você trabalha;
  • Todo dia aparece um diabo novo para satisfazer.

Se você nao se identificou, que bom. Você não trabalha no inferno. Você pode sair da leitura e voltar a tocar harpa por toda a eternidade.

Mas se você se identificou, continue lendo para aprender como gerir o seu trabalho no inferno.

Princípios Gerais 

Antes de aprendermos a usar a ferramenta do modelo de maturidade Kanban, o KMM, precisamos estar cientes de alguns princípios.

  1. O inferno continuará sendo o inferno. Você não irá transformar o inferno em um paraíso, mas pode controlar o seu cercadinho intelectual. Os seus pensamentos são seus e você pode organizar como você irá responder a cada desafio trazido.
  2. O inferno continuará sendo habitado por capetas, ogros e trolls. Mas isso não quer dizer que você precise reagir de forma ruim aos eventos que ocorrem com você. A resposta a cada evento é sua responsabilidade, como reafirmei acima.
  3. Você é o principal responsável. Enquanto quiser trabalhar onde está, você é responsável por fazer o melhor trabalho possível mesmo em cenário de adversidade. Se estiver realmente infeliz e não quiser organizar o seu trabalho, seja honesto com você. Peça contas e deixe a empresa onde está viver na sua própria miséria.

Aplicando o KMM no Inferno

Já descrevi o KMM aqui em um post anterior. Caso não tenha lido, deixo o link aqui.

“O Kanban Maturity Model consolidada mais de 10 anos de experiência na implementação do Kanban em diversos setores, em empresas de pequeno a grande porte. Use-o para obter um melhor senso de realização, fornecer melhores produtos e serviços, encantar seus clientes e obter resultados de negócios superiores.”, David Anderson

Vamos explorar aqui as práticas do nível inicial do KMM, resumida na figura abaixo. No nível zero, que pode ser livremente traduzido como Desatento ou Absorto, temos o nosso trabalho muito desorganizado e precisamos fazer sentido do que fazemos dia após dia. Na dimensão cultural, estamos buscando propósito (Achievement).

Para isso, vamos trazer as práticas ao longo de cinco colunas que se aplicam nesse nivel.

  • Visualização do Trabalho
  • Limitação do Trabalho em Progresso
  • Gestão do Fluxo
  • Políticas Explícitas
  • Laços de Feedback

Visualização do Trabalho

Você deve explicitar o seu trabalho e para isso vai criar um quadro pessoal. Comece simples e tenha três colunas (A Fazer, Em Execução, Finalizado).

Cada pedido, seja de quem vier e pelo modo que vier, deve ser explicitado.

Chegou um telefonema do seu chefe demônio nível 2? Sem problemas. Coloque no seu Kanban.

Chegou uma solicitação do seu cliente mefistóteles nível 4. Sem problemas. Ouça com atenção e registre o pedido dele no seu Kanban.

Chegou agora um pedido no meio do cafézinho do satanás nível 6. Sem problemas. Escreva o pedido em um guardanapo. Ao voltar para a sua mesa, registre o seu pedido.

As regras são simples:

  • Cada pedido é registrado como um cartão.
  • Todo pedido é explicitado. Nada fica opaco e perdido em algum email.

Você pode operacionalizar o Kanban em uma ferramenta simples com o Trello. Mas se possível use uma folha A3 e a deixe na sua mesa. Ou afixe na parede se você tiver permissão para tanto. Afinal, em muitos infernos as paredes são imaculadas e não podem ser usadas. Mas, seja como for, o seu trabalho está agora visível e explicitado para todos.

Limitação do Trabalho em Progresso (WIP)

Você (e ninguém no planeta terra) não consegue fazer muitas coisas simultaneamente.  Não apenas isso é impossível devido como o nosso cérebro foi desenhado pela evolução. Mas isso é também danoso para a sua saúde intelectual e responsável por estresses crônicos e perdas massivas de produtividade.

O método Kanban nos ensina que limita o trabalho simultâneo é bom para sua produtividade. E então você deve limitar a quantidade de trabalho simultâneo que você aceita fazer. Comece com um número pequeno (exemplo. WIP LIMIT = 3) e busque descer para o celestial número 1.

Por exemplo, se você tem WIP LIMIT 1 e um diabo importante chega como uma urgência muito urgente, você cita que todo o trabalho em curso será impactado. Se isso for realmente urgente e confirmado pelo seu gestor, você cria um cartão para isso, coloca o cartão no topo da sua lista, interrompe o trabalho em curso e informa a todos que os outros trabalhos foram paralisados devido a urgência.

Ao ser cobrado pelo trabalho que estava em curso anteriormente, você irá ser metódico e reportar as interrupções que dragaram a sua atenção. E se você for muito interrompido durante um dia, a perda de produtividade será uma consequência natural e isso deve estar muito claro para o seu gestor. Que fique claro para ele como o sistema de interrupções no seu trabalho está afetando a sua produtividade.

Ao mesmo tempo, não devemos ser hipócritas em culpar nossa chefia pela interrupções e depois virar para o lado e abrir o Facebook e Whatsapp a cada 10 minutos. A autossabotagem não é legal e você não pode culpar a sua empresa se você mesmo está criando o seu inferno particular. Se precisar de ajuda, te recomendo esse livro aqui.

Gestão do Fluxo

Você pode ter 30 tarefas para fazer, mas deve ficar claro qual a mais importante nesse exato momento. E esse sistema de classificação deve ser acordado com todas as pessoas da sua organização.

Por exemplo, você pode começar um sistema simples onde você identifica o que é urgente. Ou você pode usar um sistema de priorização com classificação Alta, Média e Baixa. Uma outra técnica é a Matriz de Einsenhower, mostrada abaixo e popularizada no excelente livro Os Sete Hábitos, do Stephen Covey.

Seja qual for o seu sistema, deve haver uma priorização explícita em todo o seu trabalho e acordos claros com suas chefias.

Cuidado. Você terá a sua fé testada e será tentando.a quebrar o seu próprio sistema. Faça isso e você irá queimar em óleo quente por sua própria fraqueza moral. Defina e acorde o seu sistema de priorização e jogue pela regras que você mesmo definiu.

Políticas Explícitas

“O combinado não é caro”, Ditado Popular

Crie e publique as políticas do seu trabalho pessoal. Vou trazer exemplos reais de pessoas da minha rede que definiram:

  • Horários e tempo para horário de almoço.
  • Saída do horário de trabalho
  • Intervalos de descanso durante o trabalho
  • Formas de receber trabalho (e para muitos, whatsapp e conversa de corredor não é uma delas)
  • Tempo para responder a emails. (Email é mecanismo assíncrono de comunicação, afinal de contas)
  • Políticas de priorização de trabalho
  • Atendimento do trabalho (ou não) durante horários no final de semana.

Explicite as políticas e as deixe visíveis no seu Kanban pessoal.

Ou não e seja um profissional “passivo agressivo”. Eles não explicitam seus acordos de trabalho, fazem coisas que não querem, comprometem o seu trabalho e a sua vida pessoal e depois ficam reclamando na rádio peão igual a meninos birrentos de 5 anos. Conheço muitos deles,  que nunca dizem não para seus clientes internos e chefes e culpam as empresas porque nunca conseguem entregar nada.

Laços de Feedback

Se você faz sempre as mesmas coisas, não espere resultados diferentes, Albert Einstein

Todo profissional deve periodicamente observar o seu trabalho em nível pessoal e perguntar:

  • O que está bom?
  • O que está ruim?
  • O que posso melhorar?

Mas não faça isso em pensamento. Abra o seu caderno de anotações, Evernote, One Note, Notepad ou qualquer outro meio e registre isso.

Eu faço isso em base diária por 10 minutos antes de sair de casa. E recomendo que você faça o mesmo, mesmo que seja em base semanal. Ao sistematizar e anotar o que podemos melhorar, tornamos a melhoria contínua um hábito, geramos melhor consciência situacional no nosso cérebro (sistema reticular) e estamos menos sujeitos a cometer os mesmos erros em situações do dia a dia.

E não se preocupe com o tamanho da melhoria. Melhorias, mesmo que incrementais, se aplicadas sistematicamente geram grandes retornos. É o famoso efeito de juros compostos, já demonstrado na teoria de sistemas econômicos.

Resumo – Como controlar o trabalho infernal no nível pessoal

O KMM no nível zero traz bons aprendizados para você domar o seu trabalho e lidar com os capetas que trabalham com você.

Resumo as lições abaixo

  • Visualização do Trabalho. Crie um quadro Kanban para o seu trabalho. Deixe ele visível. Registre tudo que chegar lá.
  • Limitação do Trabalho em Progresso. Controle o paralelismo e interrupções pessoais. Crie foco no seu trabalho. Comunique a todos o impacto das interrupções nos seus acordos. Não entube a desorganização alheia ou você irá fritar.
  • Gestão do Fluxo. Crie priorização para tudo. Acorde o seu sistema de prioridade. Siga suas regras.
  • Políticas Explícitas. Explicite como você trabalha, como você recebe o seu trabalho e quando você não está disponível. Combinado não é caro, certo?
  • Laços de Feedback. Periodicamente pare e reflita sobre como você pode melhorar. Registre seus aprendizados e crie um hábito de Journaling.

“Entre o estímulo e a resposta, existe um espaço. Nesse espaço existe o poder de escolher a nossa resposta. Na nossa resposta está o nosso crescimento e nossa liberdade”, Victor Frankl, o Sentido da Vida.