Um sistema ruim sempre derrota pessoas boas

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

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

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.

 

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

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.
😀