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

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

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:

• Cultivando Squads – Dicas Práticas para Gerentes de Projeto e Líderes Técnicos
• Afinal, o que faz o gerente na minha Squad?
• Como operacionalizar Squads na minha empresa?

 

“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