Organizando o Trabalho em Squads – Morrem os projetos e nasce o fluxo contínuo de produtos

Na maioria das empresas que possuem áreas de TI, existe uma dicotomia muito bem estabelecida entre pessoas que entregam produtos de software através de projetos e pessoas que sustentam esses softwares, cuidando das manutenções corretivas, adaptativas e pequenas demandas evolutivas.

Muitas pessoas que trabalham na TI nunca viram um outro modelo e acreditam que isso é a forma natural de organizar o trabalho.  Se você é uma dessas pessoas, pare e pense na consequência desse desenho organizacional. Provavelmente você deve lidar com alguns problemas tais como:

  • Os seus times de projetos nunca se tornam especialistas em anda pois eles estão continuamente mudando de assunto devido a orçamentação centrada em projetos e a consequente alocação e deslocação das pessoas dos projetos tão logo eles terminem.
  • Os times de projetos são incentivados a entregar seus projetos no prazo, custo e com o escopo acordado. E ao tentar fazer isso, eles são naturalmente incentivados a “flexibilizar” a qualidade do produto. “Testes de unidade automatizados? Não tenho tempo para isso. Código limpo? Então. Também não tenho tempo. BDD. Nem pensar.. estou atrasado!”.
  • A área de projetos não se responsabiliza pela qualidade do produto. Como o seu papel é entregar software o mais rápido possível nos ambientes de produção. a qualidade é “problema” da sustentação e da infraestrutura.
  • Existe um gasto enorme de dinheiro com incidentes em sustentação. Acompanho empresas com TIs enormes e ainda fico impressionado com o montante financeiro gasto em incidentes e defeitos.
  • Começam a surgir conflitos entre times de desenvolvimento, times de sustentação e times de infraestrutura. Dedos são apontados de lado a lado e as atribuições de culpa pelos software de baixa qualidade pipocam. O desenho da organização, e não as pessoas, cria esse conflito.
  • Existem times distintos que alteram o código fonte do produto e isso provoca a criação de complexidade acidental na forma de branches desnecessários, sistemas de lotes e filas, que reduzem o tempo total de entrega e baixa a percepção de valor para os usuários finais.

 

As Squads como alternativas para a cultura projetizada

photo-1523266433356-91a22e6f18ed.jpeg

Uma Squad deve ser estruturado como um time coeso que esteja alocado no desenvolvimento e sustentação de um produto ou fluxo de valor de uma organização. Ao fazer isso você redesenha o sistema tático da sua TI e provoca o seguinte:

  • Todos são agora responsáveis pela qualidade. Se você codificou mal e não testou, é sua responsabilidade. E você vai pagar por isso daqui a algumas semanas em produção. Quando você, enquanto líder, desenha a sua cozinha para fazer com que os cozinheiros comam a comida que eles estão cozinhando, você muda a percepção deles sobre o impacto dos atalhos.
  • Não existem mais dedos apontados para fora. A Squad, inclusive com o seu líder, é responsável pelos eventos que ocorrem. Incidentes vão ocorre, obviamente, mas é papel da Squad rodar suas retrospectivas para lidar com o aprendizado e melhorar continuamente.
  • O aprendizado e a produtividade aumentam. Se você mantém pessoas juntas durante um longo tempo com ritos kaizen periódicos, isso habilita o aprendizado organizacional e com isso a produtividade desses times na implementação de novas funcionalidade.
  • Você incentiva o estabelecimento da cultura de times. Times são estruturas poderosas para lidar em ambientes complexos. Atribuir metas a times e reforçar a cultura de times promove um senso de equipe e permite também atenuar as nossas fraquezas individuais.

Squads sim, mas do jeito correto

photo-1508591360875-10163ed98c8e

O conceito de fluxo contínuo de valor é fundamental para implementarmos Squads da forma correta. E isso significa que:

  • Você tem um PO e pessoas da área de negócio que estão permanentemente priorizando o que é valor de negócio. Fixar o escopo por 6 meses porque o gerente mandou não é mais a forma apropriada de trabalhar. Ao invés, você tem um backlog que é permanentemente repriorizado e o item de maior valor é puxado pelo time quando o item que estava em trabalho foi entregue em produção. No Lean, chamamos isso de sistemas puxados (Pull Systems).
  • Você deve medir continuamente o retorno de valor de negócio trazido pela sua Squad. E isso é fundamental para avaliar se o investimento que está sendo realizado na sua Squad faz sentido. E, na prática, se o seu produto de negócio ou fluxo de valor não tem tração no mercado, a Squad é reduzida ou desmobilizada.
  • Você deve entregar em produção em ciclos curtos. Entregas semestrais ou anuais em produção, portanto, não fazem mais sentido. E portanto os “itens” de trabalho, na forma de histórias ou features, devem ser pequenos. Idealmente, cada história deveria caber em uma semana (ou duas). E as tarefas do time devem ser estruturadas em não mais que 6 horas diária. No mundo Toyota/Lean, chamamos isso de “One Piece Flow” e foco implacável no “Lead Time”.
  • A qualidade contínua se torna parte do processo. Para isso, você usa técnicas diversas hoje estruturadas em corpos de conhecimento DevOps tais como: Automação de Testes de Unidade, Automação da Verificação do Código, Smoke Tests, Automação de Builds, Integração Contínua e Entrega Contínua. Esses conceitos DevOps são a forma moderna da TI implementar o conceito Lean/Toyota chamado de Jidoka.
  • Qualquer decisão de otimização deve avaliar o efeito sobre todo o fluxo de valor de negócio. Metas locais para o time de testes como remoção de defeitos perdem sentido. E esse também um dos princípios Lean.

Ao fazer isso, você ganha um desenho da sua TI que irá lidar melhor em um mundo complexo, não determinístico e imprevisível.

O Manifesto Ágil das Squads

Se houvesse uma manifesto ágil das Squads, ele seria parecido com isso.

Fluxo de valor e produtos de negócio mais que projetos de software.
Entregas contínuas  mais que longos ciclos de desenvolvimento e homologação.
Qualidade contínua nos produtos de negócio mais que foco míope em prazos.
Otimização do fluxo de valor mais que sub-otimização do trabalho de desenvolvimento, testes ou infraestrutura.

Mas… e o meu escritório de projetos?

Você pode estar pensando. Isso parece legal, mas o meu escritório não me deixa fazer isso.

Confesso que isso realmente é tenso. Em várias implementações que participei, temos que destacar tempo de qualidade para evangelizar o escritório de projetos. E em várias vezes, não funciona mesmo.

O que tenho observado são abordagens diversas para lidar com isso, tais como:

  1. Operar abaixo do radar do PMO (mais conservadora e provavelmente mais inteligente). 

    Quando você tem um PMO arcaico ou resistente, pode ser impossível buscar uma mudança de abordagem. Operar abaixo do radar implica que você possui Squads internamente dentro da sua TI com o propósito de evoluir produtos de negócio, mas a linguagem de comunicação com a empresa e interessados de negócio ainda será a linguagem de projetos. Isso exige que você faça uma prospecção ativa de projetos para conseguir garantir a orçamentação do seu Squad ou de pelo menos uma parte das pessoas do seu Squads.  E isso pode implicar em que sua Squad precise cuidar de mais de um produto para que seja possível financiá-la.

  2. Negociar a orçamentação anual por produtos de negócio, mas estabelecer uma lógica de desembolso centrada em projetos.Nessa abordagem o PMO tem ciência dos Squads e do seu propósito. E ao mesmo tempo você não quer mudar a lógica de funcionamento de um PMO, que poderia gerar muita resistência. Em conjunto, vocês e a diretoria buscam estabelecer um limite orçamentário para um produto ao longo de um ano fiscal. E esse orçamento será investido através de projetos do PMO que irão financiar uma Squad durante esse ano fiscal.Observe que nessa abordagem não basta medir o sucesso financeiro baseado em métricas míopes de projetos como o CPI ou SPI. Devemos ir além e medir o retorno financeiro trazido para a organização no investimento em um produto de negócio. Squads devem ser medidas, primordialmente, pelos resultados de negócio que seus produtos trazem.
  3. Transcender o conceito de projetos, introduzir o conceito de fluxo de valor e orçamentação relativizada e convencer o seu escritório dissoAlgumas empresas  sublimaram o conceito de projetos e trabalham com o conceito de fluxo continuado de valor de negócio. Nessa abordagem você estabelece em base periódica (ex. trimestre) uma orçamentação para uma Squad. Você prioriza os itens mais importantes do bacilo que cabem naquele período de tempo. E você mede periodicamente como foi a agregação de valor de negócio por essa Squad. Se a agregação de valor foi frutífera, você coloca mais investimento naquela Squad. Se os resultados na perspectiva de negócio são ruins, você reduz ou desmobiliza a Squad e reorienta o seu dinheiro para onde fizer mais sentido.

    O método ágil em escala organizacional chamado SAFE trabalha com essa   abordagem e tem sido muito usado em algumas grandes empresas para facilitar a transição para esse modelo.

 

Referências Adicionais:

 

“We have minds that are equipped for certainty, linearity and short-term decisions, that must instead make long-term decisions in a non-linear, probabilistic world.”
Paul Gibbons, The Science of Successful Organizational Change: How Leaders Set Strategy, Change Behavior, and Create an Agile Culture

 

 

Os três princípios fundamentais dos métodos ágeis e do DevOps

Muitos times já aprenderam que fazer Scrum não é (apenas) colocar um conjunto de pessoas em uma sala e executar ritos como um planejamento de sprint ou uma retrospectiva. Se observamos por exemplo que o gerente determina as tarefas do time e interrompe as falas de um colaborador que traz uma sugestão, sabemos que não estamos vivendo um ambiente ágil.  É como se estivéssemos observado um animal que possui penas e bota ovos, mas você percebe que não se trata de um pássaro verdadeiro ao olhar a boca dele.

feathered-dinosaur-beipiaosaurus-exhibition-museum-natural-history-vienna-foto-taken-february-th-39609374
Archaeopteryx lithographica

Acompanhei um caso em uma empresa em 2016 onde um determinado analista, muito bem intencionado, me disse que eles possuíam o DevOps muito bem implementado. E então ele me mostrou todo um conjunto de pipelines de gestão de builds e releases implementados no Visual Studio Team System. Ele também me mostrou painéis técnicos dos vários projetos no Sonar Source e muitas estatísticas geradas.

E então eu perguntei como os times estavam usando isso para melhorar suas práticas. E a resposta foi que ele não tinha autorização do seu gerente para buscar intervenções de melhoria nos times. (!?) E mais um bicho estranho me veio à cabeça – um animal com bico de pato, que bota ovos, nada muito bem, mas que não é um pássaro.

1024px-Ornithorhynchus
Ornitorrinco – Platypus Ornithorhynchus anatinus

 

Um dos maiores riscos à adoção do ágil e do DevOps é que as pessoas não compreendam os princípios que levaram à criação dessas práticas. Isso porque os times e os resultados não irão melhorar realmente sem que os princípios fundamentais da agilidade sejam internalizados. E então podemos ter conclusões precipitadas na esfera gerencial que podem levar ao descrédito nos métodos e o retorno ao modo anterior de trabalho.

A Origem dos Princípios Ágeis e DevOps – Sistemas de Produção Lean

Um dos conceitos fundamentais no Lean é o fluxo de valor (Value Streams). Vamos defini-lo primeiro no contexto da manufatura e depois extrapolar como ele se aplica ao DevOps e ao fluxo de valor de TI. Podemos definir o fluxo de valor como “a sequência de atividades que uma organização empreende para atender a uma solicitação do cliente” ou “a sequência de atividades necessárias para projetar, produzir e entregar um bem ou serviço a um cliente, incluindo os fluxos de informação e material.

Nas operações de manufatura, o fluxo de valor é geralmente fácil de ver e observar. Ele começa quando um pedido do cliente é recebido e as matérias-primas são liberadas no chão-de-fábrica. Para permitir tempos de execução rápidos e previsíveis em qualquer fluxo de valor, normalmente há um foco implacável na criação de um fluxo leve e uniforme de trabalho, usando técnicas como pequenos tamanhos de lote e redução do trabalho em progresso (WIP). Buscamos também evitar o retrabalho para garantir que não transmitamos defeitos para as próximas etapas do processo. Finalmente, buscamos otimizar continuamente nosso sistema em direção aos nossos objetivos globais.

Os mesmos princípios e padrões que permitem o fluxo rápido de trabalho em processos físicos são igualmente aplicáveis ​​ao trabalho de tecnologia de informação ou qualquer outro trabalho de natureza de conhecimento. No mundo Agile e DevOps, normalmente definimos nosso fluxo de valor de tecnologia como o processo necessário para converter uma hipótese de negócios em um serviço habilitado por tecnologia que agregue valor ao cliente.

A entrada para o nosso processo é a formulação de um objetivo de negócio, conceito, ideia ou hipótese. El começa quando aceitamos o trabalho em Desenvolvimento, adicionando-o ao nosso backlogde trabalho. A partir daí as equipes de desenvolvimento que seguem um processo ágil ou iterativo típico provavelmente transformarão essa ideia em histórias de usuários e em algum tipo de especificação de recurso, que é implementada em código no aplicativo ou serviço que está sendo construído. O código é então guardado no repositório de controle de versão, onde cada alteração é integrada e testada com o restante do sistema de software.

Como o valor é criado somente quando nossos serviços estão sendo executados na produção, devemos garantir que não apenas fornecemos fluxo rápido, mas que nossas implantações também podem ser realizadas sem causar caos e interrupções, como interrupções de serviço ou deficiências de atendimento a requisitos de performance, segurança e usabilidade, entre outros.

O Foco Implacável no Tempo de Entrega

usain-bolt-atleta-0816-1400x800-3

Em implantações Ágeis DevOps, nossa atenção deve estar no tempo total de entrega dos itens do backlog a até a produção (Lead Time). Esse fluxo de valor começa quando qualquer analista em nosso fluxo de valor verifica uma alteração no controle de versão e termina quando essa alteração é executada com êxito na produção, fornecendo valor ao cliente e gerando feedback útil e telemetria.

Em empresas tradicionais muitas vezes nos encontramos em situações em que os prazos de implantação exigem meses. Isso é especialmente comum em organizações grandes e complexas que trabalham com aplicativos monolíticos muito acoplados, geralmente com ambientes de teste de integração escassos, longos períodos de teste nos departamentos de qualidade, alta dependência de testes manuais e muitos processos manuais de aprovação.

Quando temos longos tempos de implantação, precisamos de super-heróis em quase todos os estágios do fluxo de valor. Podemos descobrir que nada funciona no final do projeto quando integramos todas as alterações da equipe de desenvolvimento, resultando em códigos que não são mais compilados corretamente ou que não passam em nossos testes. A correção de cada problema requer dias ou semanas de investigação para determinar quem quebrou o código e como ele pode ser corrigido e ainda resulta em resultados insatisfatórios para os clientes.

Ao falar de ágil e DevOps, os desenvolvedores recebem feedback rápido e constante sobre seu trabalho, o que permite que implementem, integrem e validem seu código de maneira rápida e independente e com isso implantem o código no ambiente de produção sem efeitos colaterais.

Conseguimos isso verificando continuamente pequenas alterações de código em nosso repositório de controle de versão, realizando testes automatizados e exploratórios e implementando-o na produção. Isso nos permite ter um alto grau de confiança de que nossas alterações funcionarão conforme projetado na produção e que quaisquer problemas podem ser rapidamente detectados e corrigidos. Isso é mais facilmente alcançado quando temos uma arquitetura modular, bem encapsulada e fracamente acoplada, para que as pequenas equipes possam trabalhar com alto grau de autonomia, com falhas pequenas e contidas, sem causar interrupções globais.

De fato, times DevOps desenvolvem um sistema de trabalho que os permitem entregar software em produção em base diária. Exemplos de empresas que publicados relatos impressionantes dessa agilidade de negócio incluem a Amazon, Netflix, WalMart, Target, Nordstorm, Facebook, Adobe e Sony, entre outras.

Mas, afinal, que princípios são esses que permeiam o ágil e o DevOps e o que eles dizem de tão importante?

Yoda_7
“Os três princípios deve você usar para habilitar a força dos métodos ágeis e DevOps”

Princípio #1 – Fluxo Contínuo

No fluxo de valor de TI, o trabalho normalmente flui de Desenvolvimento para Operações. O primeiro princípio demanda o fluxo rápido e suave do trabalho desde o Desenvolvimento até as Operações para entregar valor aos clientes rapidamente. Nós otimizamos esse objetivo global mais que metas locais, como taxas de conclusão de tarefas de desenvolvimento, taxa de correção de testes ou medidas de disponibilidade de operações.

Aumentamos o fluxo tornando o trabalho visível, reduzindo o tamanho dos lotes e os intervalos de trabalho e criando qualidade, evitando que os defeitos sejam transmitidos aos estágios anteriores de trabalho. Ao acelerar o fluxo através do fluxo de valor da tecnologia, reduzimos o tempo de espera necessário para atender às solicitações dos clientes internos e externos, aumentando ainda mais a qualidade do nosso trabalho, tornando-nos mais ágeis e capazes de superar a concorrência.

Nosso objetivo aqui é diminuir o tempo necessário para que as mudanças sejam implantadas na produção e aumentar a confiabilidade e a qualidade desses serviços. Dicas sobre como fazemos isso no fluxo de valor da tecnologia podem ser obtidas a partir de como os princípios do Lean foram aplicados ao fluxo de valor na indústria e incluem:

  • Tornar o trabalho visível;
  • Limitar o trabalho em progresso;
  • Reduzir o trabalho em lotes;
  • Reduzir os repasses;
  • Identificar e limpar impedimentos e
  • Reduzir a dificuldade do trabalho diário.

Princípio #2 – Feedbacks Frequentes

O segundo princípio descreve os mecanismos que permitem feedbacks rápidos da direita para a esquerda em todos os estágios do fluxo de valor. Como exemplo, feedback dos times de operações para implantadores e feedbacks dos analisas de testes para implementadores. O nosso objetivo é criar um sistema de trabalho cada vez mais seguro e resiliente.

Na TI, o trabalho acontece quase inteiramente dentro de sistemas complexos com risco alto de defeitos e paradas em produção. Como na manufatura, geralmente descobrimos problemas apenas quando ocorrem grandes falhas, como uma interrupção de produção em massa ou uma violação de segurança que resulta no roubo de dados do cliente.

Iremos tornar o nosso sistema de trabalho mais seguro através da criação de fluxo de informações rápido, frequente e de alta qualidade em todo o fluxo de valor e em nossa organização, o que inclui feedback frequente entre toas as pessoas e funções. Isso permite detectar e corrigir problemas enquanto eles são menores, mais baratos e mais fáceis de consertar; evitar problemas antes que causem catástrofe; e criar aprendizado organizacional que integramos no trabalho futuro. Quando fracassos e acidentes ocorrem, devemos trata-los como oportunidades de aprendizado, em oposição a uma causa de punição e culpa.

Uma das características que define um sistema complexo é que ele desafia a capacidade de qualquer pessoa de ver o sistema como um todo e entender como todas as partes se encaixam. Os sistemas complexos normalmente possuem um alto grau de interconectividade de componentes fortemente acoplados, e o comportamento no nível do sistema não pode ser explicado meramente em termos do comportamento de cada componente individual do sistema.

Falhas são inerentes e inevitáveis em sistemas complexos. E então devemos projetar um sistema de trabalho seguro onde possamos executar o trabalho sem medo, confiantes de que quaisquer erros serão detectados rapidamente, muito antes de causarem resultados catastróficos como danos aos trabalhadores, defeitos no produto ou impacto negativo no cliente.

Projetar sistemas perfeitamente seguros está além da capacidade de qualquer time, mas podemos tornar mais seguro trabalhar em sistemas complexos quando as quatro condições a seguir são atendidas:

  • O trabalho complexo é gerenciado para que os problemas no design e nas operações sejam revelados;
  • Os problemas são tratados coletivamente e resolvidos, resultando na rápida construção de novos conhecimentos;
  • Novo conhecimento local é explorado globalmente em toda a organização;
  • Os líderes criam outros líderes que continuamente aumentam as capacidades da organização.

Em um sistema de trabalho seguro, devemos testar constantemente nossas premissas de projeto e operação. Nosso objetivo é aumentar o fluxo de informações em nosso sistema de tantas áreas quanto possível, mais cedo, mais rápido, mais barato e com tanta clareza entre causa e efeito quanto possível. Quanto mais suposições possamos invalidar, mais rápido podemos encontrar e corrigir problemas, aumentando nossa resiliência, agilidade e capacidade de aprender e inovar.

No fluxo de valor de TI, muitas vezes obtemos resultados ruins devido à ausência de feedback rápido. Por exemplo, em um projeto de software em cascata, podemos desenvolver código por semanas ou meses e não obter feedback algum sobre qualidade até começarmos a fase de testes – ou, pior ainda, quando lançamos nosso software para os clientes. Quando o feedback é atrasado e pouco frequente, é pouco eficaz para permitir evitar resultados indesejáveis.

No mundo DevOps, o nosso objetivo é criar feedback rápido em todos os estágios do fluxo de valor de tecnologia, abrangendo Gerenciamento, Desenvolvimento, Controle de Qualidade, Segurança da Informação e Operações do Produto. Isso inclui a criação de processos automatizados de criação, integração e teste, para que possamos detectar imediatamente quando uma alteração foi introduzida que nos tire de um estado de funcionamento e implementação corretos.

Também criamos telemetria abrangente para que possamos ver como todos os nossos componentes de sistema estão operando no ambiente de produção, para que possamos detectar rapidamente quando eles não estão operando conforme o esperado. A telemetria também nos permite medir se estamos atingindo nossas metas pretendidas e, idealmente, é irradiada para todo o fluxo de valor, para que possamos ver como nossas ações afetam outras partes do sistema como um todo.

Os loops de feedback não apenas permitem a rápida detecção e recuperação de problemas, mas também nos informam sobre como evitar que esses problemas ocorram novamente no futuro. Isso aumenta a qualidade e a segurança de nosso sistema de trabalho e cria aprendizado organizacional.

O Terceiro Princípio – Aprendizado Organizacional

Enquanto o Primeiro Caminho aborda o fluxo de trabalho da esquerda para a direita e o Segundo Caminho aborda o feedback rápido e constante recíproco da direita para a esquerda, o Terceiro Caminho foca na criação de uma cultura de aprendizagem e experimentação contínua. Esses são os princípios que permitem a criação constante de conhecimento individual, que é então transformado em conhecimento de equipe e organizacional.

Diversas empresas tem aprendido que a formação de times de alta performance depende da promoção da segurança psicológica e do estabelecimento de clareza de propósitos. A segurança psicológica é a crença compartilhada pelos membros de uma equipe que a equipe é segura para assumir riscos interpessoais. Em outras palavras, é uma crença que as pessoas não serão repreendidas ou humilhadas por trazer ideias, questões, preocupações e por simplesmente errarem. Afinal, errare humanum est! 

Pesquisadores de eficiência organizacional na Google descobriram que indivíduos em equipes com maior segurança psicológica são menos propensos a sair do Google, são mais propensos a aproveitar o poder de ideias diversas de seus companheiros de equipe, trazem mais receita e são classificados como duas vezes mais eficazes por seus líderes.

Empresas de TI de alto desempenho exigem e promovem ativamente o aprendizado. Em vez de o trabalho ser rigidamente definido, o sistema de trabalho é dinâmico, com os times realizando experimentos em seu trabalho diário para gerar novas melhorias, possibilitadas pela rigorosa padronização dos procedimentos de trabalho e documentação dos resultados.

No fluxo de valor de TI, nosso objetivo é criar uma cultura de alta confiança, reforçando que somos todos aprendizes ao longo da vida que devem assumir riscos em nosso trabalho diário. Ao aplicar uma abordagem científica para a melhoria de processos e o desenvolvimento de produtos, aprendemos com nossos sucessos e fracassos, identificando quais ideias não funcionam e reforçando aquelas que funcionam. Além disso, qualquer aprendizado local é rapidamente transformado em melhorias globais, de modo que novas técnicas e práticas possam ser usadas por toda a organização.

Reservamos tempo para a melhoria do trabalho diário e para acelerar ainda mais e garantir a aprendizagem. Nós constantemente introduzimos estresse em nossos sistemas para forçar a melhoria contínua. Podemos até simularmos e injetamos falhas em nossos serviços de produção sob condições controladas para aumentar nossa resiliência. E ao criar esse sistema contínuo e dinâmico de aprendizado, possibilitamos que as equipes se adaptem rápida e automaticamente a um ambiente em constante mudança, o que, em última análise, nos ajuda a vencer no mercado.

Quando trabalhamos dentro de um sistema complexo, por definição, é impossível prevermos perfeitamente todos os resultados de qualquer ação que tomemos. É isso que contribui para resultados e acidentes inesperados, ou mesmo catastróficos, em nosso trabalho diário, mesmo quando tomamos precauções e trabalhamos com cuidado.

Quando esses acidentes afetam nossos clientes, procuramos entender por que isso aconteceu. A causa raiz é muitas vezes considerada como erro humano, e a resposta gerencial muito comum é “nomear, culpar e envergonhar” a pessoa que causou o problema. E, de forma sutil ou explícita, a gerência sugere que a pessoa culpada cometer o erro será punido. Em seguida, eles criam mais processos e aprovações para evitar que o erro ocorra novamente. No fluxo de valor da TI, estabelecemos as bases de uma cultura generativa, esforçando-nos para criar um sistema de trabalho seguro.

Quando acidentes e falhas ocorrem, em vez de procurar por erro humano, procuramos como podemos redesenhar o sistema para evitar que o acidente aconteça novamente.

Por exemplo, podemos realizar uma análise post-mortem após cada incidente para obter o melhor entendimento de como ocorreu o acidente e definir quais são as melhores contramedidas para melhorar o sistema, evitando de maneira ideal que o problema volte a ocorrer e permitindo uma detecção e recuperação mais rápidas.

O resultado de eliminar a culpa e colocar o aprendizado organizacional em seu lugar é que as organizações se tornam cada vez mais autodiagnosticas e auto aperfeiçoadas, hábeis em detectar problemas e resolvê-las”.

Muitos desses atributos também foram descritos pelo autor Peter Senge como atributos das organizações que promovem aprendizado continuado. No excelente livro chamado A Quinta Disciplina, ele escreveu que essas características ajudam os clientes, garantem a qualidade, criam vantagem competitiva e uma força de trabalho comprometida e motivada.

Resumo dos Três Princípios

Os métodos ágeis e o DevOps não são processos fechados ou um conjunto de ferramentas. Ao invés, eles são uma cultura baseada nos sistemas Lean e que busca reduzir o tempo da entrega de valor em produção, aumentar o feedback entre o time e fornecer um ambiente seguro para experimentações e inovações de negócio.

Ao realizar o seu próximo planejamento de sprint, ao pensar em automações de testes, ao criar pipelines DevOps ou contêineres Docker, pare e pense:

  • Como estou ajudando o meu time a entregar software mais rapidamente em ambiente de produção?
  • Como estou melhorando os feedbacks entre os membros do time e também o time e os nossos clientes?
  • Como o nosso ambiente está ficando mais seguro para habilitar que as pessoas aprendam e melhorem continuamente?

Se você identificou as relações, muito bom! Ajude o seu time a internalizar os princípios ágeis e DevOps e prospere continuamente no aumento da maturidade do Scrum, XP, Kanban e DevOps na sua empresa.

“Are you too busy for improvement? Frequently, I am rebuffed by people who say they are too busy and have no time for such activities. I make it a point to respond by telling people, look, you’ll stop being busy either when you die or when the company goes bankrupt.”
— Shigeo Shingo, Pai do Sistema Toyota de Produção

 

 

Cultivando Squads – Dicas Práticas para Gerentes de Projeto e Líderes Técnicos

Conversando com um colega do mundo ágil, ouvi um relato interessante sobre um time que estava buscando introduzir práticas ágeis e foi denominado como um “Squad”. No meio de uma retrospectiva em uma sprint onde a performance foi baixa, uma analista que estava particularmente irritada começou a trazer incômodos pessoais e sugestões para o time aprender com alguns erros. No meio da sua fala essa pessoa foi abruptamente interrompida pelo gerente do projeto, que o repreendeu em público pela sua postura negativa. Esse comportamento se repetiu algumas vezes e gerou as seguintes consequências nessa analista: (1) medo de se posicionar publicamente, (2) silêncio sepulcral nas reuniões, (3) desmotivação e depois de alguns meses (4) demissão voluntária da empresa onde ela trabalhava. Ao ouvir esse relato, comecei a me lembrar dos casos similares que também presenciei em empresas onde trabalhei. E também de como também pude experimentar na pele esse sentimento em uma empresa cujo modelo gerencial era bastante autocrático.

Squads não são apenas pessoas trabalhando juntas. Existe uma grande diferença entre um grupo de trabalho e times de alta performance, que reside no conhecimento e aprendizado que emerge das relações entre os seus indivíduos. Esse conhecimento emergente cria uma dinâmica poderosa e permite que o desempenho do todo seja maior que as partes individuais. E essa dinâmica é necessária para conseguirmos operar em ambientes complexos. [1]

Diversas empresas tem aprendido que que a formação de times de alta performance depende da promoção da segurança psicológica e do estabelecimento de clareza de propósitos.

A segurança psicológica é a crença compartilhada pelos membros de uma equipe que a equipe é segura para assumir riscos interpessoais. Em outras palavras, é uma crença que as pessoas não serão repreendidas ou humilhadas por trazer ideias, questões, preocupações e por simplesmente errarem. Afinal, errare humanum est! 

Pesquisadores de eficiência organizacional na Google descobriram que indivíduos em equipes com maior segurança psicológica são menos propensos a sair do Google, são mais propensos a aproveitar o poder de ideias  diversas de seus companheiros de equipe, trazem mais receita e são classificados como duas vezes mais eficazes por seus líderes. [2]

A clareza de propósitos é a garantia que o time esteja plenamente alinhado sobre qual o propósito do trabalho sendo realizado e os mecanismos necessários para realizar esse trabalho. A esse respeito, um interessante relato de caso da gerente de engenharia de infraestrutura da empresa Slack mostrou que conflitos não construtivos normalmente ocorriam quando pessoas tentavam resolver problemas diferentes quando eles acreditavam que se tratava do mesmo problema. Quando temos clareza de propósito, as chances aumentam para que a agenda seja dominada pelos conflitos construtivos, que é muito saudável para o crescimento das pessoas e times.

A figura abaixo resume os nossos objetivos então, que são: (1) promover alta segurança psicológica e (2) criar clareza e alinhamento de propósitos. Sem um desses fatores, teremos times ineficientes, desmotivação trazida pelo modelo comando e controle ou anarquia.

Squads são times de alta performance. E três fatores críticos para isso requerem que o gerente:

  1. Enquadre o trabalho do seu time como um problema de aprendizagem, não um problema de execução. Sabemos que projetos dominados por alta atividade intelectual tem um alto nível de incerteza e variabilidade [1]. Se você, como gerente, cria um ambiente que tolera erros e que os erros são usados para melhorar o sistema, você incentiva que as pessoas se manifestem. Não à toa, a pesquisadora Amy Edmonson [3] mostrou que hospitais com times mais eficientes reportaram taxas de erros maiores que hospitais menos eficientes. Isso desafia o senso comum, e é um relato que atividades complexas como a gestão hospitalar requerem uma abordagem de aprendizado e experimentação, mais que um problema de planejamento e execução.
  2. Reconheça sua própria falibilidade. Ao fazer isso, você demonstra humildade e encoraja que pessoas argumentem livremente com você e com seus pares.
  3.  Estimule a curiosidade e faça muitas perguntas. Incentivar uma cultura de perguntas vai estimular diálogos e o aprendizado organizacional.

Finalmente, listo abaixo dicas gerenciais atestadas na prática de várias empresas que estão correlacionados com a criação de ambientes que estimulam a segurança e estão relacionados com a efetividade de times.

  1. Demonstre engajamento
    ● Esteja presente e concentre-se na conversa. Por exemplo, não fique lendo email durante reuniões. Isso passa uma mensagem ruim para as pessoas que estão tentando serem ouvidas.
    ● Faça perguntas com a intenção de aprender com seus colegas de equipe.
    ● Ofereça informações, seja interativo e mostre que você está ouvindo.
    ● Responda verbalmente para mostrar engajamento (“Isso faz sentido para mim. Conte-nos mais. Pode me dar um exemplo.”).
    ● Esteja ciente de sua linguagem corporal; certifique-se de inclinar-se para a pessoa que está falando, mas sem parecer agressivo.
    ● Faça contato visual para mostrar conexão e escuta ativa
  2. Mostre compreensão
    ● Recapitule o que foi dito para confirmar o entendimento e alinhamento mútuo (por exemplo, “O que eu entendi foi…”).
    ● Reconheça áreas de concordância, discordância e esteja aberto a perguntas dentro do grupo.Valide os comentários verbalmente (“Eu entendi”. “Eu compreendo o que você está dizendo”.)
    ● Evite atribuir culpa (“Por que você fez isso?”). Ao invés, concentre-se nas soluções. “Como podemos trabalhar para evitar esse problema da próxima vez? ”.
    ● Pense nas suas expressões faciais. Elas são involuntariamente negativas? Estudos já mostraram que cerca de 70% da nossa comunicação é expressa pela linguagem corporal.
    ● Acene com a cabeça para demonstrar compreensão durante conversas e reuniões
  3. Seja inclusivo nas relações interpessoais
    ● Compartilhe informações sobre seu estilo de trabalho pessoal e preferências e incentive colegas de equipe a fazer o mesmo. Pessoas são diferentes e entender essas diferenças é importante para criar ambientes produtivos.
    ● Esteja disponível e acessível aos colegas de equipe (por exemplo, reserve tempo para conversas um-para-um ou conselhos de carreira).
    ● Expressar gratidão pelas contribuições da equipe.
    ● Intervenha se os membros da equipe falarem negativamente sobre outro membro da equipe.
    ● Tenha postura corporal aberta (por exemplo: não vire as costas para parte do grupo).
    ● Construa rapport (por exemplo, converse com seus colegas de equipe sobre suas vidas fora do trabalho ou afinidades além do trabalho).
  4. Seja inclusivo na tomada de decisões
    ● Solicite opiniões e comentários de seus colegas de equipe.
    ● Não interrompa nem permita interrupções (por exemplo, intervenha quando alguém é interrompido e garanta que as ideias de todos sejam ouvidas).
    ● Explique o racional por trás de suas decisões (i.e., mostre para a equipe como você chegou a uma decisão)
    ● Reconheça a opinião de outras pessoas (por exemplo, destaque quando os membros da equipe contribuíram para o sucesso de entregáveis)
  5. Mostre confiança e convicção sem parecer inflexível
    ● Gerencie discussões em equipe (por exemplo, não permita conversas paralelas em reuniões da equipe, verifique se o conflito não é pessoal)
    ● Use uma voz clara e audível em um ambiente de equipe
    ● Apoie e representar a equipe (por exemplo, compartilhe o trabalho da equipe com a liderança sênior e dê crédito aos colegas de equipe)
    ● Convide a equipe a desafiar sua perspectiva.
    ● Incentive os colegas de equipe a assumir riscos e demonstrar riscos em seu próprio trabalho

 

Referências

[1] Snowden, David. “Cynefin: a sense of time and space, the social ecology of knowledge management.” (2000).

[2] Edmondson and Lei (2014). “Psychological Safety: The History, Renaissance, and Future of an Interpersonal Construct,” Annual Review Organizational Psychology. Um vídeo excelente no TedTalk com o relato dos hospitais está disponível aqui no YouTube.

[3] Mendes, Marco.  O que faz o gerente na minha Squad?

Como operacionalizar Squads na sua empresa

O conceito de Squads foi popularizado na Spotify ainda em 2012 e tem sido experimentado em muitas empresas Brasileiras como um facilitador para a escalar a agilidade.

Squad (do francês: esquade)

Um Squad é semelhante a um time Scrum, mas é projetado para se sentir como uma mini-startup. Eles se sentam juntos e têm todas as habilidades e ferramentas necessárias para projetar, desenvolver, testar e  liberar aplicações para produção. Eles são uma equipe auto-organizada e decidem sua própria maneira de trabalhar – alguns usam sprints do Scrum, alguns usam o Kanban, alguns usam uma mistura dessas abordagens.

Se o termo ainda é novo para você e você gostaria de estabelecer uma fundação conceitual, recomendo a leitura do excelente artigo de Henrik Kniberg & Anders Ivarsson  publicado ainda em 2012.

Nesse post, vou discutir algumas das implicações da adoção de Squads e como lidar com isso na sua realidade.

DESAFIO 1: Orientação por produto e os desafios com o PMO da sua organização

Em empresas tradicionais, times são mobilizados através de projetos. A criação de um projeto é o que forma um time. E quando um projeto termina o time é desmobilizado.

Quando falamos de Squads, buscamos times permanentes que constroem e sustentam produtos de negócio. Enquanto o produto de negócio existir, haverá uma ou mais Squads que irão cuidar desse produto de negócio.

Observe que temos aqui uma impediência entre a nova linguagem (de produtos) versus a linguagem antiga (de projetos). E como podemos lidar com essa diferença?

Algumas abordagens para lidar com essa questão incluem:

  1. Operar abaixo do radar do PMO (mais conservadora).

    Quando você tem um PMO muito arcaico ou resistente, pode ser impossível buscar uma mudança de abordagem.Operar abaixo do radar implica que você possui Squads internamente dentro da sua TI com o propósito de evoluir produtos de negócio, mas a linguagem de comunicação com a empresa e interessados de negócio ainda será a linguagem de projetos. Isso exige que você faça uma prospecção ativa de projetos para conseguir garantir a orçamentação do seu Squad ou de pelo menos uma parte das pessoas do seu Squads.  Isso pode implicar em que sua Squad precise cuidar de mais de um produto para que seja possível financiá-la.
  2. Negociar a orçamentação anual por produtos de negócio, mas estabelecer uma lógica de desembolso centrada em projetos.

    Nessa abordagem o PMO tem ciência dos Squads e do seu propósito. E ao mesmo tempo você não quer mudar a lógica de funcionamento de um PMO, que poderia gerar muita resistência. Em conjunto, vocês e a diretoria buscam estabelecer um limite orçamentário para um produto ao longo de um ano fiscal. E esse orçamento será investido através de projetos do PMO que irão financiar uma Squad durante esse ano fiscal.Observe que nessa abordagem não basta medir o sucesso financeiro baseado em métricas míopes de projetos como o CPI ou SPI. Devemos ir além e medir o retorno financeiro trazido para a organização no investimento em um produto de negócio. Squads devem ser medidas, primordialmente, pelos resultados de negócio que seus produtos trazem.

  3. Transcender com o conceito de projetos. #NoProjects  (mais agressiva).

    Algumas empresas  sublimaram o conceito de projetos e trabalham com o conceito de fluxo continuado de valor de negócio. Nessa abordagem você estabelece em base periódica (ex. trimestre) uma orçamentação para uma Squad. Você prioriza os itens mais importantes do bacilo que cabem naquele período de tempo. E você mede periodicamente como foi a agregação de valor de negócio por essa Squad. Se a agregação de valor foi frutífera, você coloca mais investimento naquela Squad. Se os resultados na perspectiva de negócio são ruins, você desmobiliza a Squad e reorienta o seu dinheiro para onde fizer mais sentido.O excelente eBook chamados #NoProjects , publicado em 2016, traz casos reais e como esse polêmico princípio poderia ser discutido em organizações mais ousadas.

DESAFIO 2: Construção e Sustentação de Produtos

Em empresas tradicionais, a área de desenvolvimento desenvolve produtos. E uma outra área, chamar de sustentação, sustenta produtos. Isso parece natural, mas é uma dicotomia que gera um sistema de incentivos que leva que:

  • uma parte das pessoas busque entregar código o mais rapidamente possível em produção, mesmo que seja lixo.
  • e uma outra parte que é paga para atender incidentes em produção.

Esse modelo cria dedos apontados para os “culpados” pelos problemas de qualidade e incidentes.

Em Squads, temos um time que cuida do desenvolvimento de novas funcionalidades e da sua sustentação. Mas isso não é fácil. Isso exige muita maturidade.

Algumas abordagens que podem ajudar na implementação desse modelo incluem:

  1. Possuir uma pessoa dedicada para sustentação na Squad (mais conservadora)

    Temos aqui em uma Squad uma ou mais pessoas que irão cuidar da evolução do produto na perspectiva de negócio. E teremos outras pessoas que irão cuidar do atendimento a incidentes de produção e manutenções adaptativas.

  2. Possuir uma ou mais pessoas dedicadas para sustentação na tribo.

    Nessa abordagem temos uma pessoa dedicada, mas ela é da tribo e é compartilhada pelo conjunto de Squads que compõem essa tribo. Isso dilui o custo da sustentação entre Squads e permite que a pessoa da sustentação lide com mais assuntos.
  3. Possuir pessoas dedicadas para sustentação em uma Squad, mas com rotação de papéis.

    Se uma pessoa que não foi contratada como analista de suporte ficar muito tempo cuidando de defeitos ele pode ter o seu moral reduzido e perder a motivação. E então você pode experimentar o “motorista da rodada”, i.e., alguém que ficará apenas alguns dias ou semanas cuidando da sustentação. Depois dessa período, outras pessoas assuem o papel da sustentação.

  4. Estabelecer que todas as pessoas criam novas funcionalidades mas também sustentam os produtos da Squad. (mais agressivo)

    Isso é complexo e requer que:

    • O time entregue já código de excelente qualidade em produção, de foram que os incidentes sejam eventuais e o time seja pouco impactado por mudanças emergenciais.
    • O tamanho da mudança evolutiva seja pequena. Grandes mudanças evolutivas trazem impacto maior em ambiente de produção e isso acarreta em um maior número de incidentes, que impacta o planejamento e o moral do time.
    • O time use estratégias modernas de implantação como Implantações Canário. Discuti essa técnica aqui no contexto de práticas DevOps.

 

DESAFIO 3: Time de especialistas generalistas

Na maior parte das TIs os arranjos são funcionais. Isso é, existe a área de analistas, a área de desenvolvimento. Existe a área de qualidade ou a área de implantação. E eles se comunicam primordialmente pela ferramenta inventada pelo capeta corporativo, o famoso e-Mail. É mais que provado que essa separação de funções é ruim financeiramente falando e cria apenas silos gerenciais, disputas de poder e burocracia desnecessária.

Squads não operam de forma funcional. Em Squads maduras, temos todas as competências necessárias para criar e sustentar os nossos produtos de negócio.

Mas não é fácil chegar aqui e precisamos de abordagens intermediárias. Algumas delas incluem:

  1. Estabelecer Squads de Suporte globais para funções raras na organização. (mais conservadora) Por exemplo, poucas TIs possuem uma profusão de especialistas de segurança. E isso pode impedir que na prática tenhamos Squads com um especialista dedicada para segurança da informação.Um Squad de suporte é um tipo particular de Squad que oferta funções especializadas para outros Squads. Esses squads podem possuir modelos de trabalho baseados em sistemas Kanbans, que lidam com demandas em base diária e promovem a vazão e o aumento da velocidade no atendimento a essas demandas.Outros exemplos de funções que normalmente podem ser acomodados nesta configuração incluem Squads de Infraestrutura, Squads de Designers Gráficos ou Squads de Arquitetura.
  2. Estabelecer Squads de Suporte em tribos para funções com baixa disponibilidadeVamos assumir que você tenha uma tribo com 25 pessoas, mas possua apenas 3 analistas de testes, Nesse cenário você estabelecer uma Squad de Suporte de Testes que irá ofertar funções para a sua tribo. Como a sua tribo cuida de produtos de negócio correlatos, não é difícil que analistas de testes possam transitar entre essas Squads e com isso ofertar uma economia de custos sustentável.
  3.  Aceitar os limites da sua Squad conforme o orçamento da sua organização.
    No mundo ideal,  a sua Squad terá analistas de requisitos, engenheiros de usabilidade, arquitetos, desenvolvedores, testadores, especialistas em segurança da informação e analistas de infraestrutura.No mundo real, você provavelmente terá muito menos papéis disponíveis. Aceite a realidade e cresça a maturidade da sua Squad ao longo do tempo.

    DESAFIO 4: Vencer o “modelo comando e controle”

Tradicionalmente, os gerentes estão envolvidos em decidir qual é o trabalho real e na decisão de como fazê-lo.No contexto de Squad, a decisão do que a equipe está trabalhando não está mais sob o controle do gerente, mas é decidida pelo Product Owner. O PO  tem uma visão geral do produto e o que é mais valioso para os clientes, e ele prioriza o trabalho que a equipe realizar.E a decisão sobre como a equipe deve funcionar é delegada à equipe. A equipe é focada no autogerenciamento e, juntos, precisam refletir sobre o que deve ser feito e decidir como farão isso e como vão melhorar.Mas o que faz o gerente no mundo ágil?

Os gerentes atuam como construtores de capacidade. O papel da gerência intermediária é enxergar o todo e construir a capacidade da organização de construir ótimos produtos. Ele deve ajudar a equipe e o Scrum Master na remoção de obstáculos e melhorias. O Gerente deve ensinar a equipe a melhorar e resolver problemas, além de verificar formas para entender o que realmente está acontecendo no local de trabalho e ver como ele pode ajudar melhor a equipe a melhorar seu trabalho.

Algumas abordagens para vencer o modelo “comando e controle” incluem.

  1. Definir o gerente de projeto como SM (mais conservadora)Como o SM participa em base diária do trabalho do time, isso pode acalmar o ímpeto do comando e controle de gerentes mais centralizadores. Ao mesmo tempo, devemos ficar atento e impedir que os gerentes façam micro-gerenciamento (decidir como um participante do time deve fazer o seu trabalho técnico).
  2. Definir o gerente de projeto como PO
    O PO tem controle sobre o backlog e isso também pode ajudar que pessoas mais centralizadoras topem participar dentro de uma dinâmica ágil.
  3. Adotar práticas do Management 3.0 (mais agressiva)O Management 3.0 é um conjunto de práticas gerenciais centradas em uma mentalidade moderna de gestão.. Essas práticas podem ser adotadas individualmente ou em conjunto e permitem que o modelo de autonomia seja gradativamente instalado na Squad.Listamos aqui esse conjunto de práticas com os links para a sua descrição e uso.
    1. Business Guilds & Communities of Practice
    2. Celebration Grid
    3. Copilot Programs
    4. Competency Matrix
    5. Corporate Huddles
    6. Culture Books
    7. Delegation Board
    8. Exploration Days
    9. Feedback Wraps
    10. Happiness Door
    11. Identity Symbols
    12. Improvement Dialogues
    13. Improv Cards & Storytelling
    14. Internal Crowdfunding
    15. Kudo Box
    16. Meddlers
    17. Merit Money
    18. Metrics Ecosystem
    19. Moving Motivators & CHAMPFROGS
    20. OKRs (Objectives & Key Results)
    21. Personal Maps
    22. Project Credits
    23. Problem Time
    24. STAR Behavioral Recruitment Questions
    25. 12 Steps to Happiness
    26. Salary Formula
    27. Scoreboard Index
    28. Unlimited Vacations
    29. Value Stories
    30. Visual Goal Setting
    31. Work Expos
    32. Work Profiles
    33. Yay! Questions

A implantação de Squads é um movimento importante na evolução da agilidade em organizações. Ao mesmo tempo, os modelos de implantação não são únicos e é fundamental você conduzir experimentações dentro da realidade da sua organização.

E, dentro da sua realidade, o que tem funcionado no contexto de Squads? Quais tem sido os seus desafios? Compartilhe aqui com a gente.

O trem ágil chegou! Em qual estação você vai embarcar?

Gosto muito do conceito da difusão de inovações de Rogers, que mostra como inovações são adotadas ao longo do tempo por uma audiência potencial. A figura, reproduzida abaixo a partir do trabalho original de Everett Rogers de 1962, traz a hipótese que existem cinco perfis no ciclo de adoção de uma nova tecnologia, processo ou produto.

curva-de-adoção-de-novos-produtos-receita-x-tempo
Fonte: blog.cicloagenciadigital.com.br

Os dois primeiros públicos, ou mercado inicial, são os perfis desbravadores que experimentam um novo processo, produto ou tecnologia. Se os seus relatos e resultados obtidos forem bons, a inovação vence o abismo e avança para a maioria inicial e com nova confirmação de sucesso ela avança posteriormente para a maioria tardia.

Por curiosidade, comparei a tendência de pesquisa de termos comuns na esfera gerencial como PMBOK, Scrum e Lean. Os resultados estão abaixo mostraram ao longo dos últimos anos uma inversão da procura ao longo dos últimos anos. Os números mostram um que o Scrum ou o Lean trazem mais curiosidade que o PMBOK no Brasil.

Captura de Tela 2018-05-07 às 16.30.03

Fonte: Google Trends

Baseado também no que tenho observado na minha rede de gestores, arrisco dizer que o método ágil já venceu o abismo da incredulidade no Brasil no público gerencial. A aceitação dos métodos ágeis está cada vez maior e mesmo aqueles que ainda não estão usando estão querendo se informar.

Ao mesmo tempo, não devemos confundir métodos ágeis com Scrum. Existem muitos tipos de métodos ágeis e cada empresa pode se beneficiar de um tipo distinto de método para a sua realidade. Não é porque o método ágil venceu o abismo que ele vai ser aceito pela maioria tardia, que é um público muito mais cético.

Para lançar alguma luz nos diversos métodos ágeis, compilei um mapa ferroviário com as linhas onde correm alguns três ágeis populares no mercado.

O mapa está abaixo  e disponível aqui em alta resolução, que você pode baixar e abrir em uma janela própria do seu computador. Eles contém mais de 70 conceitos usados dentro do mundo ágil em escolas diversas de pensamento.

Trem Ágil

Cada linha é representada por uma cor distinta e contém conceitos, papéis ou termos fundamentais para o entendimento daquele trilho. O objetivo é lhe dar um mapa para você navegar no mundo ágil, reconhecer e correlacionar conceitos comuns falados nos corredores e times ágeis de todo o Brasil.

Destaco aqui pontos importantes do mapa:

  • Linha Vermelha – Representa o trem do Scrum, o método mais popular do mercado ágil no Brasil, Aqui você vai encontrar termos como Backlog do Sprint, Planejamento de Sprint, Revisão ou Retrospectiva
  • Linha Amarela – Representa o trem do dono do produto e do desenvolvimento de produtos. Contem termos importantes como Backlog do Produto, VPD, Design Sprint e Design Thinking.
  • Linha Laranja – Representa a metodologia Kanban, que vai além do quadro Kanban. A linha laranja evolui para a linha do Lean, a linha Roxa.
  • Linha Roxa – Representa a linha dos métodos lean e traz conceitos fundamentais como a redução de lotes, redução do tempo de ciclo, teoria de fila e controle empírico de processo.
  • Linha Azul – Representa a linha dos times ágeis e traz ideias poderosas como Squads e o Management 3.0.
  • Linha Preta – Aqui temos a agilidade para dezenas ou centenas de pessoas, chamada de agilidade em escala. Escolhi representar aqui os principais conceitos de um dos métodos mais poderosos para a agilidade em escala no mercado, que é o SAFE.
  • Linhas Verde Escura, Verde Clara e Azul. Se você é de TI, vai gostar dessas linhas. Elas trazem os conceitos de DevOps, Automação de Testes e Arquiteturas Ágeis.

O mapa é uma abstração apenas e deve ser enriquecido ao longo do tempo com novos termos, conceitos e relações. Se você já trabalha com métodos ágeis, sugestões são muito bem vindas.

E como me aprofundo em cada trilha?

Se você quer navegar com mais profundidade por uma dessas trilha, tomo a liberdade de lhe recomendar alguns livros essenciais para iniciar ou reforçar o seu aprendizado em um dos trens do mundo ágil.

Linha Vermelha – Scrum

514ZCPRQ-bL._SX337_BO1,204,203,200_71nHi9Q2t6L._AC_US436_QL65_

Linha Amarela – PO – Dono do Produto

51oQRBYUxeL._SX381_BO1,204,203,200_61K0l8DfyCL._AC_US436_QL65_

Linha Laranja – Kanban

616tkWkRWjL._AC_US436_QL65_51hocASZ3bL._AC_US436_QL65_

Linha Roxa – Lean

41FItt2UB8L._AC_US436_QL65_51O-pgPIYAL._AC_US436_QL65_

51pgq089gIL._AC_US436_QL65_-2

Linha Azul

516O25pIrgL._AC_US436_QL65_71tMlME3L6L._AC_US436_QL65_

Linha Preta

511nXu28UIL._AC_US436_QL65_51zOpwQvJNL._AC_US436_QL65_

Linhas Verde e Azul – Para você que é de TI e estava se sentido esquecido

Como matar uma iniciativa DevOps em sete passos.

A TI é afeita a termos e letrinhas que surgem de tempo em tempo. No momento atual, os termos “transformação digital”, “microsserviços” e “DevOps” são tão modinhas quanto as músicas de qualidade ruim da Anitta.

E o problema das modinhas é que que todos querem dizer que estão fazendo, mesmo que tenham uma ideia distorcida do que estão realmente fazendo. A este respeito, tenho observado excelentes oportunidades DevOps sendo jogadas nos lixo por implementações equivocadas em pequenas e grandes empresas.

E se é para nos equivocarmos, gostaria de ajudar também. Vamos direto ao ponto e criar um guia rápida de como fracassar com DevOps.

É fácil. Siga os sete passos abaixo e falhe na sua implementação DevOps. É fracasso garantido ou o seu dinheiro de volta.

  1. Contrate um “Analista DevOps”

Existem sim líderes técnicos, desenvolvedores, testadores e profissionais de qualidade, entre outros, que praticam DevOps. Ao mesmo tempo devemos nos lembrar, desde o início, que o DevOps é uma cultura. Ou seja, não existem *Analistas DevOps*.

Acreditar que você vai encontrar um “Analista DevOps” já é ruim. E para piorar alguns gestores acreditam que contratar um “Analista DevOps” é o suficiente para ter a sua implementação DevOps realizada.

2. Crie uma área especialista para fazer DevOps

Erro clássico, embora muito comum. Criar mais um silo em um departamento de TI que já tem áreas de gestores, analistas, desenvolvedores, testadores, homologação e produção trabalhando em locais diferentes definitivamente não irá ajudar.

O DevOps prega a quebra das paredes (físicas e invisíveis). E não adicionar mais uma área funcional dentro da sua TI.

3. Estabeleça um pipeline DevOps dentro da área de qualidade ou governança

Qualquer iniciativa de centralizar uma esteira DevOps vai intensificar o oposto do que a cultura DevOps promove. O DevOps é uma cultura que promove comunicação ampla e a quebra de silos.

Que fique claro: o DevOps ocorre NOS PROJETOS e não em uma torre de marfim de qualidade.

4. Mantenha testadores e desenvolvedores trabalhando em áreas diferentes

Apartar (no espaço e no tempo) testadores e desenvolvedores é um dos piores erros que gestores podem cometer. Isso gera adiamento na resolução dos defeitos, desalinhamento e dedos apontados sobre as culpas no final do projeto. E isso também mantem a nefasta cutural funcional e os malefícios que os processos cascata nos impuseram ao longo dos últimos 40 anos.

5. Não envolva o time de infraestrutura. Ou não envolva o time de desenvolvimento

DevOps sem Ops soa estranho, certo? Assim como uma iniciativa DevOps sem Dev. E mesmo assim estamos vendo muitas implementações DevOps que ocorrem apenas dentro da área de desenvolvimento ou da área de operações.

6. Implante as ferramentas DevOps em primeiro lugar

Muitos gestores acreditam que ferramentas como VSTS, Chef, Puppet, GitLab, Docker ou Ansible já trazem o DevOps dentro dela. É como se você comprasse uma panela de cerâmica laranja e esperasse que o seu jantar vá ter qualidade de restaurante três estrelas Michelin.

Embora estas e outras ferramentas sejam excelentes devemos nos lembrar que no mundo DevOps devemos:

  • primeiro trabalhar as pessoas e a cultura,
  • depois as práticas;
  • e finalmente as ferramentas.

7. Venda o DevOps como a bala de prata que irá matar os lobisomens da sua organização

Não, o DevOps não é uma bala de prata. Ele não irá revolucionar a sua TI, não irá zerar o backlog e os defeitos, não irá garantir todas as entregas dentro dos prazos e também não irá fazer que pessoas deem as mãos em harmonia.

Apesar disso,  o DevOps pode lhe ajudar sim no contínuo caminho da melhoria contínua que buscamos nos ensinamentos do sistema Toyota de Produção e nas práticas Lean.

Algo está errado se os trabalhadores não olham ao seu redor cada dia e não encontram coisas tediosas ou aborrecidas para depois reescreverem eles mesmos os procedimentos. Mesmo o manual do mês passado deveria estar desatualizado hoje, Taiichi Ohno

A fábula dos porcos assados (e os sistemas de informação)

Certa vez, aconteceu um incêndio num bosque onde havia alguns porcos, que foram assados pelo fogo. Os homens, acostumados a comer carne crua, experimentaram e acharam deliciosa a carne assada. A partir dai, toda vez que queriam comer porco assado, incendiavam um bosque.  O tempo passou, e o sistema de assar porcos continuou basicamente o mesmo.

Mas as coisas nem sempre funcionavam bem: às vezes os animais ficavam queimados demais ou parcialmente crus. As causas do fracasso do sistema, segundo os especialistas, a dos porcos, que não permaneciam onde deveriam, ou à inconstante natureza do fogo, tão difícil de controlar, ou, ainda, às árvores, excessivamente verdes, ou à umidade da terra ou ao serviço de informações meteorológicas, que não acertava o lugar, o momento e a quantidade das chuvas.

As causas eram, como se vê, difíceis de determinar – na verdade, o sistema para assar porcos era muito complexo. Fora montada uma grande estrutura: havia maquinário diversificado, indivíduos dedicados a acender o fogo e especialistas em ventos – os anemotécnicos. Havia um diretor-geral de Assamento e Alimentação Assada, um diretor de Técnicas Ígneas, um administrador-geral de Reflorestamento, uma Comissão de Treinamento Profissional em Porcologia, um Instituto Superior de Cultura e Técnicas Alimentícias e o Bureau Orientador de Reforma Igneooperativas.

Eram milhares de pessoas trabalhando na preparação dos bosques, que logo seriam incendiados. Havia especialistas estrangeiros estudando a importação das melhores árvores e sementes, fogo mais potente etc. Havia grandes instalações para manter os porcos antes do incêndio, além de mecanismos para deixá-los sair apenas no momento oportuno.

Um dia, um incendiador chamado João Bom-Senso resolveu dizer que o problema era fácil de ser resolvido – bastava, primeiramente, matar o porco escolhido, limpando e cortando adequadamente o animal, colocando-o então sobre uma armação metálica sobre brasas, até que o efeito do calor – e não as chamas – assasse a carne.

Tendo sido informado sobre as idéias do funcionário, o diretor-geral de Assamento mandou chamá-lo ao seu gabinete e disse-lhe: “Tudo o que o senhor propõe está correto, mas não funciona. Isso pode funcionar na teoria, mas na prática não faz sentido. O que o senhor faria, por exemplo, com os anemotécnicos, caso viéssemos a aplicar a sua teoria? E com os acendedores de diversas especialidades? E os especialistas em sementes? Em árvores importadas? E os desenhistas de instalações para porcos, com suas máquinas purificadoras de ar? E os conferencistas e estudiosos, que ano após ano têm trabalhado no Programa de Reforma e Melhoramentos? Que faço com eles, se a sua solução resolver tudo? Hein?.”

“Não sei”, disse João, encabulado.

“O senhor percebe agora que a sua idéia não vem ao encontro daquilo de que necessitamos? O senhor não vê que, se tudo fosse tão simples, nossos especialistas já teriam encontrado a solução há muito tempo?.”

“O senhor, com certeza, compreende que eu não posso simplesmente convocar os anemotécnicos e dizer-lhes que tudo se resume a utilizar brasinhas, sem chamas? O que o senhor espera que eu faça com os quilômetros de bosques já preparados, cujas árvores não dão frutos e nem têm folhas para dar sombra? E o que fazer com nossos engenheiros em porcopirotecnia? Vamos, diga-me!”.

“Não sei, senhor.”

“Bem, agora que o senhor conhece as dimensões do problema, não saia dizendo por aí que pode resolver tudo. O problema é bem mais sério do que o senhor imagina. Agora, entre nós, devo recomendar-lhe que não insista nessa sua idéia – isso poderia trazer problemas para o senhor no seu cargo.”

João Bom-Senso, coitado, não falou mais um “a”. Sem despedir-se, meio atordoado, meio assustado com a sua sensação de estar caminhando de cabeça para baixo, saiu de fininho e ninguém nunca mais o viu. Por isso é que até hoje se diz, quando há reuniões de Reforma e Melhoramentos, que falta o Bom-Senso.”

Desconheço o autor desta fábula, mas ainda vejo florestas sendo queimadas com muito mais frequência do que imaginaria na área de Tecnologia de Informação.

Ouvi um relato de um projeto que foi fragmentado para quatro empresas fornecedoras operando remotamente, cada um com a sua especialidade tecnológica (Mobilidade, barramento, back-end e Web). Uma desculpa para este arranjo foi que cada empresa fornecedora era “dona” de uma tecnologia e os acordos contratuais exigiam esta distribuição. Dois anos depois e com com milhões de reais gastos nenhum produto foi entregue. O diretor de assamento então resolveu assar no espeto os gerentes e algumas fábricas que participaram deste processo.

Também tive a oportunidade de ver um time de produto que herdou uma arquitetura Web absurdamente complexa de um  “arquiteto super inteligente” de uma fábrica de software. O efeito desta arquitetura é o que time demora 3 semanas para implementar um cadastro de complexidade média.

Estas histórias reais me lembram do conceito de complexidade acidental e complexidade essencial, popularizado na TI por Neal Ford.

A complexidade essencial representa a dificuldade inerente a qualquer problema. Na nossa fábula acima, acender fogo era necessário para assar os porcos.  A complexidade decorrente dos compromissos que assumimos que incorrem em dívidas técnicas é diferente. Consiste em todas as formas imposta externamente de que o software se torne complexo e não deve existir em um mundo perfeito. A isso chamamos de complexidade acidental. Tecnologias como o Java EJB, Microsoft BizTalk e ERPs cujos nomes não podem ser pronunciados são exemplos de complexidade acidental na TI.

Tomo a liberdade aqui de expandir a definição original do autor, pensada para arquiteturas de software, para arranjos essenciais e arranjos acidentais.

Por exemplo, a existência de analistas desenvolvedores, analistas de testes e líderes de projetos são arranjos essenciais para entregar software de qualidade. Já times de testes e times de desenvolvedores que trabalham em salas separadas e com processos cascatas são exemplos de arranjos acidentais. E os  “gerentes de projetos” que ficam atrás das suas mesas 8 horas por dia atualizando cronogramas Gantt de 1000 linhas e perguntando aos seus coordenados “Eh aí, tá pronto?” são exemplos também ruins de arranjos acidentais.

Se você está cansado de queimar florestas inteiras para assar porcos, recomendo a aplicação de práticas do Lean Software Development, um corpo de práticas muito legais para você descomplicar a sua TI e a forma como entrega e mantém software.

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”
Edsger W. Dijkstra