O Todo Poderoso Gráfico do Fluxo Cumulativo de Valor

Figuras brilhantes da administração moderna, como Peter Drucker, já diziam que é inútil tentar gerenciar um sistema de trabalho sem um sistema consistente de medições e métricas. Se você já trabalha com métodos ágeis isso é ainda mais importante pois métodos ágeis são baseados nos princípios de transparência radical, feedbacks e replanejamentos contínuos. Sem números apropriados, não conseguimos avançar na maturidade do uso de métodos ágeis.

Felizmente, existe um gráfico simples e superpoderoso que pode ser facilmente usado por times ágeis. Esse gráfico lhe dará muitas informações valiosas, tais como:

  1. A representação das entregas realizadas no fluxo de valor do seu sistema de trabalho.
  2. O tempo médio que o seu sistema de trabalho demora para processar um novo pedido ou requisito. (lead time ou tempo de atravessamento).
  3. O tempo médio que cada papel ou área do seu sistema de trabalho demanda para processar novos itens. (cycle time ou tempo de ciclo).
  4. A quantidade de itens que estão sendo processados em um determinado momento do tempo (WIP ou trabalho em progresso).
  5. Observar mudanças de escopo ao longo do tempo
  6. Observar a vazão do seu sistema de trabalho, de um papel ou de uma área. (throughput)
  7. Observar gargalos
  8. Estimar quando o seu projeto irá terminar

Ferramentas normalmente usadas por times ágeis, como por exemplo o Microsoft VSTS/TFS, JIRA Agile, Redmine ou o Trello com plugins, já constroem automaticamente esse gráfico e liberam o nosso tempo para a análise intelectual das informações. Ao mesmo tempo, você pode criá-los em ferramentas de planilhas simples como o Google Sheets ou o Excel. Irei fazer isso ao longo desse post para que você possa entender como construir e interpretar esse gráfico.

Construindo o Gráfico do Fluxo Cumulativo de Valor

O nome do nosso super-gráfico é fluxo cumulativo de valor e é também chamado de CFD ou Burn-Up.

Os passos essenciais para a construção desse gráfico são:

  1. Decidir que tipo de informação será medida.
  2. Decidir a frequência da análise.
  3. Decidir que etapas do fluxo de valor serão medidas.

Vamos trabalhar com um primeiro exemplo onde queremos analisar os incidentes que são atendidos por uma área de suporte de um produto. A nossa análise nesse exemplo será semanal e iremos analisar as seguintes etapas:  novos incidentes, incidentes em tratamento e incidentes fechados.

Primeiro monte uma tabela com as informações dos incidentes em cada estado ao longo de cada semana.

Captura de Tela 2018-09-09 às 11.02.39.png

Depois você deve somar os dados em cada semana, i.e, em cada semana iremos ver todos os incidentes naquele estado. Na semana 2, portanto, teremos 17 incidentes no estado aberto, 10 em execução e 7 fechados. Isso irá gerar uma planilha simples conforme mostrado abaixo.

Captura de Tela 2018-09-09 às 11.02.46

Agora iremos representar isso visualmente em um gráfico de área 2D (Area Chart Non Stackable no Google Sheets ou Área 2D no Excel). O resultado abaixo será mostrado.

chart

 

Extraindo Informações do Gráfico Cumulativo de Valor

Vamos agora interpretar as informações trazidas por esse gráfico.

A representação das entregas realizadas no fluxo de valor do seu sistema de trabalho.

O primeiro fato a ser extraído do gráfico é como o seu sistema de trabalho está se comportando conforme o seu fluxo de valor, que é a coleção de etapas ou estados através dos quais podemos observar o sistema de trabalho.

Podemos observar que nas 4 primeiras semanas tivemos 52 incidentes abertos, 33 itens em execução e 19 fechados. Já na semana 6 observamos 78 itens abertos, 51 em execução e 40 itens fechados. E isso indica que o sistema na semana 6 está menos saudável que na semana 4 pois existe um acúmulo maior de itens nos estados aberto ou em execução. Colocado de outra forma, podemos ver que na semana 4 existe um acúmulo de 33 itens (52 itens abertos – 19 itens fechados). Já na semana 6 temos 38 itens acumulados (78 itens abertos – 40 itens fechados).

Se observamos a figura, podemos observar como a barriga da área azul. Visualmente podemos ver que a barriga na semana 6 se tornou maior que a barriga da semana 4. E isso indica que a saúde do sistema piorou.

Sistemas de trabalho saudáveis devem manter conseguir processar itens em taxas similares às suas chegadas. Isso evita filas, troca de contexto e defeitos no processamento de pedidos, requisitos, demandas ou encomendas.

O tempo médio de processamento de pedidos (lead time ou tempo de atravessamento)

Um dos motivos que leva a que métodos ágeis tenham esse nome é que eles buscam garantir que um pedido aberto não fique muito tempo dentro do seu sistema de trabalho, i.e., um novo pedido ou requisito deveria ser rapidamente construído, verificado e liberado para os seus clientes. Chamamos essa métrica global de tempo de atravessamento ou lead time.

Vamos examinar como o lead time pode ser examinado pelo gráfico do fluxo cumulativo de valor. Ele pode ser lido através da diferença horizontal entre os itens fechados e os itens abertos.

Captura de Tela 2018-09-09 às 11.38.25.png

Por exemplo, na semana 5 estamos vendo que os itens fechados correspondem aos itens que foram abertos na semana 2. O lead time da semana 5 está perto de 4 semanas, que indica que um incidente fica perto de um mês no seu sistema antes de ser finalizado.

Se observarmos a semana 10, vemos um o sistema ficou ainda menos saudável.  Os itens fechados na semana 10 foram abertos entre a semana 5 e a semana 6, que indica que o lead time médio agora está em cerca de 4 semanas e meia.

Nos métodos ágeis, buscamos minimizar o lead time. Quanto menor o lead time, mais rápida é a capacidade do seu time de processar pedidos. E portanto a medição do lead time é em minha opinião a mais importante métrica a ser observada em sistemas baseados em métodos Scrum, Kanban e afins.

O tempo médio de processamento de pedidos por papel ou área (cycle time)

Se o lead time mostra o tempo total de atravessamento no nosso sistema de trabalho, podemos usar o mesmo racional para examinar como uma etapa do trabalho (papel ou área) está se comportando. Considere o gráfico abaixo como exemplo.

Captura de Tela 2018-09-09 às 11.54.21.png

Aqui estamos observar o tempo de ciclo da etapa de execução, i.e, o tempo médio que um incidente demorou para ser efetivamente resolvido uma vez que ele começou a ser tratado pela equipe. Podemos ver que o tempo de ciclo na semana 5 era de um pouco mais de 1 semana. Já na semana 10 o tempo de ciclo já era de 3 semanas, indicando que o time de execução claramente não está conseguindo liberar incidentes na mesma taxa que eles estão chegando.

Veja ainda que o tempo de ciclo pode ser analisado em outras etapas. Por exemplo, no gráfico abaixo podemos observar o tempo de ciclo da etapa de Novos Incidentes.

Captura de Tela 2018-09-09 às 12.02.14.png

Aqui podemos ver que na semana 3 um incidente demorava, em média, uma semana e meia até começar a ser tratado pelo time. Já na semana 10 um item ficava aberto quase 4 semanas até começar a ser tratado pelo time.

Longos tempos de ciclo para uma etapa indicam que a área associada aquele trabalho está com dificuldades. E isso indica que a gestão deve buscar formas de apoiar aquele time para reduzir nos gargalos. Ao invés de permitir a chegada de novos itens de foram desenfreada (ilusão de controle) ou fazer ameaças (management 1.0) a gestão ágil deve promover enxames de ajudantes de outras áreas e funções para desafogar o time com dificuldades e com isso reestabilizar o sistema.

A quantidade de itens que estão sendo processados em um determinado momento do tempo (WIP ou trabalho em progresso).

Esse gráfico é tão legal que podemos observar também como os itens estão se acumulando no sistema de trabalho. A isso chamamos de trabalho em progresso ou WIP (Work In Progress). Valores altos do WIP indicam que o seu sistema não está saudável pois indica que as pessoas estão tentando fazendo muita coisa ao longo de uma semana. Isso leva a interrupções no trabalho, trocas de contexto e esgotamento mental pelo seu time.

No gráfico abaixo, podemos observar que o WIP da semana 10 é claramente pior que o WIP da semana 02, mostrando como o sistema está se degradando ao longo do tempo.

Captura de Tela 2018-09-09 às 12.09.16.png

De fato, se você observar os dados da planilha fornecida no exemplo você irá observar que o WIP da semana 02 era de 19 itens (26 – 7). Já o WIP na semana era de 37 itens (119 – 72).

Observar mudanças de escopo ao longo do tempo

Vamos considerar o contexto de um time que precise construir um produto e fez um levantamento inicial dos requisitos do produto. Esse time trabalha em um fluxo de valor com os estados: Backlog, Em Análise, Em desenvolvimento, Em testes, Em homologação e Fechado.

O gráfico mostrado abaixo mostra que houve um intenso esforço na descoberta de requisitos nas semanas 2 e 3. E o gráfico também mostra que houve mudanças de escopo ao longo da semana 8 (12 novos itens surgiram). E se o projeto foi baseado em premissa de escopo fechado, isso indica um sinal gerencial amarelo que sinaliza que novos sprints talvez sejam necessários para completar o escopo recem-descoberto.

Captura de Tela 2018-09-09 às 13.34.42.pngObservar a vazão do seu sistema de trabalho, de um papel ou de uma área. (throughput)

Podemos observar ainda um aspecto bem importante na saúde de um sistema que é a sua vazão, ou taxa de produção de itens no tempo. Por exemplo, considere o seguinte gráfico.

Captura de Tela 2018-09-09 às 13.41.45.png

Explicitei nesse gráfico a vazão dos responsáveis pelo desenvolvimento nas semanas 4, 5, 6 e 7. Observe que quanto maior a inclinação da seta, maior é a vazão. E então podemos observar que o time de desenvolvimento teve um problema mais sério entre a semana 5 e 6. A inclinação da seta aqui está muito baixa nesse região do gráfico. Talvez algum dos desenvolvedores tenha sido alocado em outro projeto ou algum aspecto técnico da arquitetura ainda não explorado do produto tenha surgido e atrasado o trabalho de todos eles.

A análise da vazão ao longo de cada etapa é um instrumento importante para o Scrum Master, Agile Coach e time analisar a saúde e estabilidade do sistema de trabalho.

Observar gargalos

Um outro superpoder desse gráfico é permitir que você analise gargalos. E para isso vamos habilitar as linhas de tendência das etapas inicial e final desse sistema de trabalho (novos requisitos no backlog e requisitos fechados). As linhas de tendência são criadas pela opção Trend Lines no Google Sheets e Excel e são observadas pelas linhas vermelha e preta nesse exemplo.

Captura de Tela 2018-09-09 às 13.56.38.pngSe a inclinação das linhas é igual isso indicaria que o sistema está saudável. No caso aqui, estamos vendo que a inclinação da linha vermelha é maior que a inclinação da linha preta. E isso indica que mais itens estão chegando do que itens saem do sistema de trabalho.

Podemos fazer essa análise comparando quaisquer duas etapas (ex. desenvolvimento versus testes ou análise versus testes), para todo o intervalo de tempo ou para um período de análise. As inclinações das retas nos permitem analisar se gargalos estão sendo formados.

E se você observar um gargalo, é o momento de ligar um sinal amarelo e analisar como podemos pensar coletivamente e apoiar área que está apresentando dificuldades.

Estimar quando o seu projeto irá terminar

Por último, mas não menos importante, esse gráfico lhe dá também uma oportunidade de estimar quando o projeto provavelmente irá terminar.  Vamos considerar o gráfico mostrado abaixo, onde explicito a quantidade de itens fechados ao longo do tempo e também a quantidade de itens que devem ser realizados ao longo do projeto.

Captura de Tela 2018-09-09 às 14.07.07.png

Uma heurística simples que podemos usar aqui é a regra de três sobre os itens fechados até o momento. No nosso exemplo temos 28 itens que foram fechados em 10 semanas. E como temos 117 itens a serem realizados, o tempo total para finalizarmos todos os itens no escopo seria calculado como: 117/28 *10 = 41 semanas.

Essa abordagem, pois mais simplista que pareça, trabalha com o princípio básico que a velocidade passada é um excelente preditor da velocidade futura em um sistema. E isso se torna cada vez mais verdade quando você tem um bom número de observações ao longo do tempo.

Erros Comuns no uso do Fluxo Cumulativo de Valor

Embora esse gráfico seja extremamente poderoso, devemos ter atenção a alguns pontos para não usarmos a ferramenta de forma errada. Alguns erros incluem:

  1. Começar com um fluxo de valor complexo. Recomendo começar com um fluxo simples (A Fazer, Em execução, Finalizado) e incluir mais estados a medida que você e o seu time se acostumarem com o instrumento.
  2. Possui uma definição fraca de Finalizado. Finalizado é algo que está pronto para os seus usuários finais. Se você trabalha com entrega de livros, Finalizado significa que o seu livro está na casa do seu cliente. Se você trabalha com uma cozinha, Finalizado significa que o seu cliente está almoçando o prato que ele pediu há 30 minutos atrás. E se você trabalha com desenvolvimento de software, Finalizado implica que o aquela funcionalidade está nas mãos dos seus usuários no ambiente de produção.
  3. Não possuir Critérios de Aceite para mover um item ao longo do fluxo de valor.  É fundamental que o time defina critérios objetivos que permitam avaliar se um item pode transitar de um estado para outro no fluxo de valor. Isso evita falsos positivos e a maquiagem de dados.
  4. Não comunicar o gráfico. Esse gráfico deve ser afixado em base periódica nas paredes do local de trabalho do seu time ou exibido na TV da sua sala. Esconder esse gráfico em alguma planilha obscura na rede não irá ajudar ao seu time, nem você.
  5. Ter uma frequência baixa de atualização. O poder do gráfico cumulativo de valor vem das interpretações que conseguimos obter das medidas ao longo do tempo. (WIP, Lead Time, Taxas e Gargalos). E isso depende de um ciclo de amostragem regular. Recomendo um ciclo mínimo de uma semana. mas se você coletar os números em base ainda menor você terá insumos ainda melhores.
  6. Adotar esse gráfico apenas para  um único tipo de informação. Todo sistema complexo deve ser examinado em diferentes níveis. E cada nível  lhe dar perspectivas diferentes de análise. Por exemplo, na construção de produtos podemos analisar Épicos, Features ou Histórias. E podemos ter gráficos CFD para cada um desse itens, que permite que você observe a saúde do sistema em níveis distintos e possa extrair interpretações mais robustas.

“Don’t look with your eyes, look with your feet. Don’t think with you head, think with your hands.“ – Taiichi Ohno


A planilha mostrada nesse exemplo está compartilhada aqui para seus estudos sobre o CFD.

Acelerando a Implantação de Squads com o Modelo Iceberg

Muitas organizações estão tentando implementar métodos ágeis e buscado aplicar práticas Scrum, Kanban, Squads e Lean no seu dia a dia de projetos e operações de TI. Entretanto, várias organizações tem falhado semana após semana nessas tentativas. Apesar das reuniões diárias, papéis estruturados como o PO e SM, pessoas trabalhando em contato físico permanente e ambientes modernos para atender as insatisfações das gerações Y e Z, vários gestores não tem observador melhoria efetiva nos resultados de negócio.

Se você está vivendo essa realidade, você pode estar contaminado por um terrível vírus que transformou o seu processo em uma coisa chamada Agile Zombie.

Agile Zombie

São sintomas comuns do Agile Zombie:

  1. Não existe coração pulsante

Times Agile Zombie repetem ritos, mas não existe entrega frequente de software em produção. Em equipes ágeis saudáveis, entendemos que ter um fluxo contínuo de software entregue não é apenas uma boa ideia, mas um objetivo fundamental do método. O Agile Zombie aborda isso de forma diferente. Para eles, é sempre muito complicado fazer entregas intermediárias e sempre existem respostas prontas para dizer porque isso não é possível.

   2.  Sem resposta emocional a fracassos e sucessos

Como um corpo sem vida, as equipes do Agile Zombie não mostram resposta a um Sprint fracassado ou bem-sucedido. Onde outras equipes amaldiçoam ou se alegram, elas simplesmente mantêm seu olhar vazio. O moral da equipe é muito baixo. Itens do Sprint Backlog são transferidos para o próximo Sprint sem questionamentos. Porque não? Há sempre um próximo Sprint e as iterações são artificiais de qualquer maneira.

   3. Sem força de vontade para melhorar

No Agile Zombie não há alegria e certamente não há necessidade de melhorias. E ninguém parece se importar. O Product Owner não está normalmente presente durante a Revisão da Sprint ou o Planejamento da Sprint. As equipes são altamente instáveis, pois os membros são continuamente emprestados a outras equipes que precisam de suas habilidades (especializadas). Os desenvolvedores possuem desculpas prontas sobre o porque eles não tem tempo para fazer testes de unidade e os testadores também tem desculpas prontas sobre porque eles insistem em usar documentos Word para organizar casos de testes. Alguns dos gargalos podem ser reais, enquanto outros podem ser imaginados. E isso facilmente se traduz em retrospectivas chatas com  muitas reclamações. E certamente nenhum desejo de melhorar. Os sentimentos de sarcasmo, cinismo e desânimo são muito comuns.

Afinal, de quem é a culpa? Preciso trocar o meu time ou aquele mala que trabalha comigo?

Times ágeis são estruturas complexas, i.e., o seu poder vem das interações entre as pessoas que as formam e das interações entre essas pessoas com o ambiente, estruturas e crenças culturais. E isso implica que usemos instrumentos apropriados para compreender como eles realmente funcionam. O pensamento sistêmico nos ensina que na vasta maioria dos casos o problema não está nas pessoas, mas em elementos mais profundos e normalmente não óbvios.

E se você vive o Agile Zombie na sua organização, vamos conhecer um poderoso antivírus para esse sintoma, que é uma ferramenta do pensamento sistêmico chamado de Modelo Iceberg.

Modelo Iceberg

Captura de Tela 2018-09-01 às 15.12.20.png

Eventos

Um software com incidentes críticos em produção ou uma pessoa que reclama muito são exemplo de eventos dentro do modelo Iceberg

Acima da linha de água estão os eventos. Os eventos são marcadores no tempo em que várias variáveis ​​são observadas. Elas são o “o que aconteceu” ou “o que vimos”.  Ao aplicarmos o Modelo Iceberg às questões globais, poderíamos dizer que na ponta, acima da água, há eventos ou coisas que vemos ou ouvimos acontecendo no mundo todos os dias. Os eventos que ouvimos dos nossos clientes, gerentes e colegas representam a ponta do iceberg. A maior parte dos gerentes gasta seu tempo no nível do eventos, tentando resolver problemas não triviais como produtividade e motivação de times. E isso quase nunca funciona.

Padrões de comportamento

Padrões são as mudanças nas variáveis ​​que ocorrem ao longo do tempo. São as tendências que percebemos ao longo do tempo. Por exemplo, podemos observar um fluxo cumulativo de valor ao longo de três meses e perceber que a taxa de entrega está reduzindo. Os padrões são importantes para identificar porque indicam que um evento não é um incidente isolado. Os padrões respondem às seguintes perguntas O que está acontecendo e o que está mudando?

Quando fazemos uma declaração como “parece que estamos reduzindo o tempo gasto para implantar software em produção”, esses são padrões que estamos observando, uma série de relações entre eventos observados na linha do tempo. Quando chegamos ao nível do padrão, podemos antecipar, planejar e prever. Ele nos permite adaptar aos problemas para que possamos reagir de forma mais eficaz a eles.

Estrutura do sistema

A estrutura suporta, cria e influencia os padrões que vemos nos eventos. Estruturas podem ser entendidas como as “regras do jogo”. Elas podem ser escritas ou não escritas; eles podem ser físicas e visíveis ou invisíveis. São regras, normas, políticas, diretrizes, estruturas de poder, distribuição de recursos ou formas informais de trabalho institucionalizadas tacitamente ou explicitamente. Eles respondem a pergunta: o que pode explicar esses padrões?

Pode não ser fácil ver a estrutura, mas os padrões que podemos ver nos dizem que a estrutura deve estar lá. Estruturas são compostas de relações de causa e efeito. Estas são conexões entre padrões. Por exemplo, um desenvolvedor pode dizer: “Se eu aumentar o número de testes de unidade automatizados, terei menos problemas em produção”. Ela está dizendo que há uma conexão entre um número crescente de casos de testes – um padrão – e uma quantidade decrescente de defeitos – outro padrão.

Se você observar a causa raiz de alguns padrões, poderá começar a entender e abordar soluções sustentáveis ​​de longo prazo, como por exemplo políticas robustas de testes de regressão ou mecanismos que apoiem que pessoas se motivem.

Modelos mentais

O modelo mental usado para perceber o mundo e é o que gera as estruturas, padrões e eventos

Abaixo das estruturas estão os modelos mentais. Estes definem o pensamento que cria as estruturas que então se manifestam nos padrões dos eventos. Os modelos mentais são suposições e crenças profundamente arraigadas que, em última análise, impulsionam o comportamento de todo o time. E não existem apenas um padrão, estrutura ou modelo mental em jogo; podem haver muitos.

Os modelos mentais são as atitudes, crenças, moralidades, expectativas, valores ou cultura que permitem que as estruturas continuem funcionando como estão. Essas são as crenças que muitas vezes aprendemos subconscientemente em nossa sociedade ou família e também nas empresas e times de desenvolvimento e sustentação de software. Os modelos mentais são, em última análise, o que mantém a estrutura fazendo o que faz. São os pensamentos e processos de raciocínio que precisam existir para fazer com que a estrutura seja como é. Essas ideias existem nas mentes das partes interessadas da estrutura, das pessoas que montam a estrutura ou daquelas que desempenham um papel na maneira como ela opera. Modelos mentais são tipicamente difíceis de identificar, pois geram muitas suposições que nunca são explicitadas.

Ao mesmo tempo, se você trabalhar e for bem sucedido em trabalhar os modelos mentais dos gerentes e dirigentes de uma organização, você irá permitir que todo um novo conjunto de estruturas, padrões e eventos possam ocorrer.

Exemplos de Uso do Modelo Iceberg

Cliente “Mal Educado”

Ao invés de reclamar que o seu cliente é mal educado, pare e pense por um momento no sistema onde ele trabalha e na pressão que ele recebe em base diária dos chefes e clientes deles. Observe também os sistemas pessoas dessa pessoa, como condições de vida, família e outros fatores.  Ao fazer isso você poderá ter uma compreensão mais profunda sobre os comportamentos observados, que são apenas os efeitos (e não as causas).

Aquele seu colega lambão que entrega muito defeito

Ao invés de reclamar que o seu colega entrega muitos defeitos, busque compreender o sistema de incentivos onde ele trabalha. Por exemplo, se ele é incentivado para entregar no prazo para receber bonificações financeiras, é perfeitamente esperados que ele entregue código com muita rapidez .. e com defeitos de brinde. Ou você pode se questionar se ele foi treinado em práticas de código limpo ou até mesmo se ele aprendeu na prática como fazer código limpo com um mentor em algum projeto.

Um Caso Real 

Vamos omitir o nome da empresa, para sermos educados. E nessa empresa existe uma tribo com várias Squads que estão lutando com todas as suas forças para implementar práticas de Squads e acelerar a implantação do Scrum e Kanban.

E, apesar das tentativas repetidas de uma pessoa bastante competente, os resultados são ruins. A taxa de defeitos é muito alta e o moral do time é muito baixo.

Conduzi nessa organização uma análise com o modelo Iceberg e chegamos a alguns resultados interessantes, resumidos abaixo.

Eventos

  • Pessoas reclamam e demonstram atitudes cínicas.
  • Sprints falham.
  • Produtos lançados em produção tem um índice alto de defeitos.
  • Clientes reclamam e alguns deles o fazem com muita agressividade.
  • O gerente interrompe os analistas que ousam gerar reclamações, no meio de suas falas.
  • A gerência discute com o time de arquitetura como o produto deve ser desenhado e implementado.

Padrões

  • O moral do time está reduzido, devido a contaminação do ambiente pelas críticas ao longo do tempo.
  • O produto está atrasado e a taxa de chegada de novos requisitos é maior que a taxa de saída.

Estruturas

  • As áreas de negócio não se envolvem e não tem “tempo” para interagir com os times
  • A gerência sênior delega todo o problema para o gerente de projeto, que atua colocando ainda mais pressão no time.
  • A gerência sênior bonifica o time pelo cumprimento de datas, a qualquer custo.
  • A gerência apartou o time de testes do time de desenvolvimento. Eles se comunicam primordialmente com emails e documentos Word.

Modelos Mentais

  • A gerência acredita no micro-gerenciamento, especificando o que fazer e impedindo que os times introduzam práticas técnicas “estranhas” ao conhecimento dele.
  • A gerência acredita em hierarquias rígidas e no modelo do Management 1.0
  • A área usuária acredita que projetos devem atender simultaneamente o custo, escopo e o prazo, ainda que esse compromisso tenha sido feito com informações precárias em um documento de 1 página.
  • Vários desenvolvedores e testadores acreditam que eles devem receber comandos claros e o que trabalho deles termina no comit do código (time de desenvolvedores) e na geração de defeitos (time de testes)

Ao analisar esse caso, vemos que o modelo de incentivo da diretoria induz comportamentos de micro-controles em alguns gerentes médios, que por sua vez propagam e criam força a uma cultura comando e controle aumenta o nível de passividade de várias técnicos do time.

Aplicando Mudanças com o Modelo Iceberg

O modelo Iceberg não apenas ilustra as diferentes dimensões de um problema, mas também oferece uma visão sobre como implementar mudanças de maneira mais eficaz dentro do sistema, através dos chamados pontos de alavancagem.

Alavanca
“Dê-me uma alavanca e um ponto de apoio e eu moverei o mundo”, Arquimedes.

Um ponto de alavancagem é um lugar dentro de um sistema – uma organização, uma economia, um corpo vivo, uma cidade, um time -, onde uma pequena mudança em uma coisa pode produzir grandes mudanças em tudo. Quanto mais baixo nós vamos no iceberg, mais alavancagem teremos para transformar o sistema. Mudar estruturas e influenciar modelos mentais tem um efeito mais amplo e mais abrangente do que reagir no momento e eventos discretos de combate a incêndios.

  1. Mudança no nível dos Eventos – Efeito: Reação

    Se apenas olharmos para os eventos, o melhor que podemos fazer é reagir. Algo acontece e nós consertamos. Essa é tipicamente nossa resposta na primeira vez que um evento ocorre. Nós não mudamos nosso pensamento de forma alguma; Nós apenas agimos rapidamente para corrigir o problema imediato usando soluções pré-existentes que funcionaram no passado. Para alguns eventos superficiais, esta abordagem pode funcionar bem, mas falhará claramente se uma questão é mais sistêmica, pois estamos apenas lidando com os sintomas do problema, não com as causas subjacentes.

    A metáfora do iceberg ajuda a ilustrar que, se de alguma forma alteramos o evento no topo sem encontrar uma solução para a causa, a flutuabilidade do gelo por baixo simplesmente empurra para recriar a ponta novamente. Como tal, apenas os problemas mais superficiais podem ser resolvidos neste nível.

  2. Mudança no nível de Padrões de Comportamento – Efeito: Antecipação

    Quando começamos a notar um padrão em uma série de eventos, temos mais opções. Podemos antecipar o que vai acontecer e podemos planejar isso. Quando começamos a perceber padrões, podemos começar a considerar o que está fazendo com que os mesmos eventos aconteçam repetidamente.

    Por exemplo, você observar que liberações sem testes de regressão irão trazer um alto volume de incidentes no mês seguinte. E isso lhe permite estabelecer no futuro estratégias de testes e práticas de qualidade contínua para se antecipar a esses problemas.

  3. Mudanças no nível da Estrutura – Efeito: Redesenho

    Quando começamos a prestar atenção às estruturas subjacentes, começamos a ver onde podemos mudar o que está acontecendo. Nós não estamos mais à mercê do sistema. Podemos começar a identificar o pensamento e os modelos mentais que estão causando essas estruturas a serem do jeito que são.

    Por exemplo, podemos ter uma estrutura de desenvolvimento onde os usuários chave estão em contato diário com o time de desenvolvimento e possuem tempo semanal dedicado para gerar feedback dos produtos. E isso permite que novos padrões de construção floresçam, que irão reduzir muito retrabalho de requisitos e reduzir defeitos.

  4. Mudanças no Nível dos Modelos Mentais – Efeito: Transformar

    Mudar o modelo que uma organização usa é o ponto de alavancagem mais alto, pode levar a uma transformação real, com a possibilidade de reestruturar totalmente o sistema e superar até mesmo desafios complexos.

    Por exemplo, quando você tem um time cujo gerente “comando e controle” foi removido e agora você tem um líder que promova discussões aberta e transparência radical para tratar e resolver problemas, você consegue criar um ambiente de aprendizado verdadeiro e mais resiliente para lidar com as pressões.

Em resumo, o pensamento sistêmico nos convida a parar de reclamar das pessoas pelo ato de reclamar e estudar os motivadores diretos e indiretos que levam as pessoas a fazer o que elas fazem. Os atos que você observa são apenas eventos. Julgar os eventos sem entender os padrões,  estruturas e modelos mentais é raso e normalmente não vai resolver nada que seja realmente complexo.

Efeitos da Aplicação do Modelo Iceberg

As regras do jogo mudam quando você começa a jogar

Quando você incorpora o espírito de times ágeis, você compreende que o seu trabalho é não linear, i.e., que regras que anteriormente valiam podem ser invalidadas no meio do jogo. Por exemplo, você pode perder aquele excelente desenvolvedor de backend que foi trabalhar em uma outra empresa. Ou você pode ter parte do seu escopo invalidado por uma regulamentação que acabou de chegar do governo. Aceitar a imprevisibilidade e desenvolver mecanismos de adaptação a mudança são fundamentais para fazer com que as Squads prosperem.

Você pode estar errado

Outra regra importante do pensamento sistêmico diz que mesmo que você seja muito experiente, você pode fracassar. Você pode ter executado uma prática com sucesso em vários locais, mas pode falhar miseravelmente na próxima iniciativa. Ou seja, ter a mente aberta para tratar seus movimentos ágeis como hipóteses e buscar validar essas hipóteses o mais rapidamente possível é crítico para prosperar.

Você pode ter efeitos colaterais

Quando você está experimentado com uma Squad, você deve ter ciência que seus movimentos podem gerar efeitos colaterais, também chamados de consequências não-intencionais. Esteja aberto para avaliar os efeitos de segunda e terceira ordem das suas mudanças e crie um ambiente de banda larga

Você deve envolver muitas pessoas, continuamente.

Não é fácil mudar o modelo mental e estruturas e você deve envolver muitas pessoas para discutir as mudanças e debater o que deve ser realizado. Crie instrumentos de meritocracia para avaliar quais são as pessoas que estão realmente aptas para contribuir com mudanças e lhe ajudar a estabelecer pontos de alavancagem firmes.

Dicas para Operar Mudança no Nível dos Modelos Mentais

  1. Descubra o que é REALMENTE importante para as pessoas, ignorando o que dizem que é importante.

  2. Incentive as pessoas nas dimensões que são valiosas para elas, mas quem podem ser facilmente proporcionadas por você.

  3. Preste atenção à maneira como reagem. Se você ficar frustrado ou surpreso com suas reações, trate de aprender com elas e experimentar algo diferente

  4. Crie incentivos que mudem as estruturas de antagônica para cooperativa.

  5. Nunca acredite que as pessoas farão algo simplesmente porque é a coisa certa.
  6. Saiba que certas pessoas farão tudo que estiver ao seu alcance para manipular o sistema, encontrando maneiras de vencer que você jamais havia imaginado. Esteja preparado para isso e se adapte.

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?

Afinal, o que faz o gerente na minha Squad?

O modelo de Squads advoga que você aproxime as pessoas que estejam no núcleo da entrega e sustentação de seus produtos de negócio. Essas pessoas trabalham juntas em forte cooperação técnica, fazem uso de métodos ágeis como Kanban, Lean, Scrum ou LESS e entregam produtos para os seus usuários com boa frequência.

Ao mesmo tempo, as Squads são constituídas sobre estruturas organizacionais já existentes. E nessas estruturas temos muitos gerentes, dispostos em silos funcionais e com receio que alguém mexa em seus domínios.

Ouvi recentemente a dúvida de um gerente de uma dessas empresas com muitos gerentes.  – “Qual o papel do gerente nas Squads?”.

Como a pergunta não tem uma resposta trivial ou única, compilo aqui algumas respostas que o mercado tem trazido para essa questão.

O Gerente em Projetos Tradicionais

Tradicionalmente, os gerentes estão frequentemente envolvidos em decidir qual é o trabalho a ser feito e estão também envolvidos na decisão de como fazê-lo.  Entretanto, gerentes não são necessariamente excelentes analistas de negócio. E ao usar o seu poder para decidir qual o trabalho deve ser feito, eles podem deixar escapar a oportunidade de aplicar a melhor engenharia de valor em seus produtos.

Gerentes também não são normalmente excelentes técnicos e ao tentar dizer como um técnico deveria fazer o seu trabalho eles realizam micro-gerenciamento. Microgerenciar pessoas está correlacionado com frustração, desmotivação e até mesmo demissões voluntárias.

O Gerente nos Métodos Ágeis 

Nos métodos ágeis, o papel do gerente não é mais responsável por definir qual é o trabalho a ser feito. A decisão sobre o que a equipe deveria trabalhar não está mais sob o controle do gerente, mas é decidida pelo Dono do Produto. Ele tem uma visão geral do produto e o que é mais valioso para os clientes. E portanto ele prioriza o trabalho que a equipe deve fazer.

E o papel do gerente nos métodos ágeis também não é responsável por definir como um trabalho vai ser feito. A decisão sobre como a equipe deve funcionar é delegada à equipe. A equipe é uma equipe de autogerenciamento e, juntos, precisa refletir sobre o que deve ser feito e decidir como farão isso e como vão melhorar continuamente o seu trabalho.

Mas, então, o que o gerente deve fazer?

O papel da gerência intermediária é enxergar o todo e melhorar a capacidade da organização em construir produtos de excelente qualidade. Ele deve ajudar a equipe e o Scrum Master na remoção de obstáculos e melhorias. Ele deve ensinar a equipe a melhorar e como resolver seus próprios problemas. Ele deve ir e ver (Genchi Genbutsu) para entender o que realmente está acontecendo no local de trabalho, e ver como ele pode ajudar melhor a equipe a melhorar seu trabalho.

O papel da alta administração é menos alterado, pois ainda estão envolvidos com decisões estratégicas relacionadas à empresa e seus produtos. Ao mesmo tempo, é também o papel da alta gerência  ensinar aos gerentes intermediários como ensinar as pessoas. Ele também precisam ajudar seus subordinados na resolução de problemas e como podem se tornar melhor no treinamento dos seus times.

O Gerente nas Squads – O Que Tenho Observado

Modelo 1 – Gerente Como Dono do Produto

Em muitas empresas, os gerentes intermediários são pessoas centralizadoras devido à cultura gerencial instalada. E nesse tipo de cenário tenho visto gerentes acumulando também o papel do PO. Isso dá a eles autonomia sobre o que fazer sem violar práticas de métodos ágeis como o Scrum.

O risco aqui é que o gerente simplesmente use o seu bom senso para trabalhar a priorização do produto. Não à toa, o próprio PMI reconheceu a importância dos gerentes conhecerem mais sobre os seus produtos de negócio, realizar engenharia de valor e usar técnicas provadas de análise de negócio. A certificação de Analista de Negócio do PMI é um movimento nessa direção e hoje já existem excelentes cursos de pós-graduação para a formação de analistas de negócio.

Modelo 2 – Gerente Como Scrum Master

Para Squads menores e onde o gerente tenha um domínio técnico do assunto sendo tratado pude já observar o gerente assumindo também o papel do Scrum Master.

Isso pode ser positivo para limpar impedimentos em organizações muito hierarquizadas, onde o crachá gerencial é fundamental para conseguir ajuda de outras áreas.

Existe aqui o risco do gerente atuar como um decisor técnico e inibir o desenvolvimento do time. E nesse modelo devemos ter extremo cuidado para não reforçar ou manter os cacoetes de microgerenciamento.

Modelo 3 – Gerente Como Agile Coach da Tribo

Nesse modelo o gerente se desapega do trabalho operacional e começa a atuar como um construtor de capacidades do time no nível da tribo. Com isso ele consegue atuar em várias Squads e estabelecer uma consistência do trabalho.

Realizar esse trabalho é árduo e requer uma mudança nos modelos mentais preestabelecidos. No nível gerencial, a principal função a ser buscada é desenvolver pessoas. E no nível do time, a principal função a ser buscada é operar como uma unidade autogerenciada de alta performance  e que busque melhorias contínuas no seu processo de trabalho.

Existe um risco no exercício dessa função que lida com o paradigma de gestão. Pessoas não devem ser gerenciadas. Ao invés, o gerente deve cuidar do sistema em torno das pessoas e nos incentivos que irão permitir que as pessoas se motivem. E não falo aqui de incentivos financeiros. Para trabalhos de natureza intelectual, já foi demonstrado que o aspecto mais importante na motivação de pessoas é a autonomia na tomada de decisões.

Vamos tomar um exemplo de uma ideia gerencial que parece ser boa mas que pode ser usada de forma inadequada, que são as reuniões individuais de acompanhamento. Se o gerente usa as reuniões um-para-um para estabelecer objetivos individuais e posteriormente solicita atualizações de status para as pessoas ele estará apenas reforçando o relacionamento superior-subordinado que é típico nas organizações de comando e controle.

Everyone should learn how to manage the system, not the people, Jurgen Appelo

Quando um gerente decide atuar como Agile Coach, ele deve usar práticas gerenciais que:

  • envolvam as pessoas e promovam as suas interações;
  • permitam ao time melhorar o sistema;
  • ajudem a engajar e aproximar os clientes do time e do produto sendo construído.

Uma prática gerencial importante e que atende a essas condições são retrospectivas.  Um outro exemplo é a prática Vá Ver (Genchi Genbutsu), que permite que os gerentes acompanhem os seus times no trabalho real e possam discutir formas de melhorar o sistema.

O portal do Management 3.0 traz uma excelente coleção de práticas que atendem aos requisitos acima e pode ser usada para que gerentes migrem do nocivo modelo comando e controle (Management 1.0) para um papel mais próximo ao de coaches.

Modelo 4 – Simplesmente Reduzir o Número de Gerentes na Organização

Quando olhamos as organizações que migram de modelos hierárquicos e silos funcionais para o modelo de squads, observamos que algumas gerências simplesmente deixam de existir.

Vou trazer um exemplo no contexto de QA e testes de software. Em empresas hierarquizadas, temos gerentes de testes que chefiam um pool de pessoas e gerenciam filas de requisições para prestar serviços de verificação e validação de sistemas para outras áreas da organização. Quando operamos por Squads, os analistas de testes estão agora dentro das Squads. E agora os próprios analistas de testes se reunem periodicamente (ex. comunidade de práticas de testes) para realizar retrospectivas do seu trabalho e também para desenvolver a competência organizacional de testes na organização.

Esta visão vai na direção da descentralização gerencial e que é bastante enfatizada por Neils Pflaeging no seu excelente livro – Organizar para a Complexidade. E o mantra aqui é: Mais Gestão, com Menos Gerentes.

Captura de Tela 2018-06-28 às 00.55.58


 

 

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.