Pegar a metodologia ágil, um processo otimizado para equipes pequenas, multifuncionais e colaborativas, e fazer funcionar em grande escala, é fascinante. Você tem que mudar alguns elementos e manter outros, conforme você redefine o contexto. Ser orientado a resultado, é um elemento que você deve manter – ou até aumentar sua importância –, ou você vai quebrar a essência do sistema de entregas.

Ficando mais rápido em construir a coisa errada

Eu “me tornei ágil” em 2000/2001 – eu estava escrevendo um software e liderando equipes em uma fábrica de software da época, e adotamos elementos de XP e outras práticas ágeis no que chamamos (interna e externamente) de Ciclo Rápido (em inglês, Fast Cycle Time – FCT). Era mais do que somente entregas incrementais, nós realmente incorporamos princípios ágeis, como programação em duplas e demonstrações, e práticas de engenharia como construções automatizadas e processos de testes, code-read, desenvolvimento para testes. Era um mundo novo para mim naquela época e me fisgou para sempre. Pelos anos seguintes minha carreira evoluir para a gestão de pessoas, pré-venda, e atividades de gestão de desenvolvimento dentro do gerenciamento de produtos.

Eu gastei muito tempo uma década atrás como um novo gerente de produtos ágeis – testando, aprendendo, aplicando, e entendendo como não ser somente um gerente de produtos trabalhando com equipes ágeis, mas também como ser ágil como um gerente de produtos. Ambos eram incomuns, e ambos ainda são importantes.

Eu diria regularmente – e ainda acredito que seja verdade – que quando uma equipe ou uma organização menor (digamos 100 desenvolvedores ou menos) se torna ágil, se eles também não estiverem focados na gerência de produtos, tudo o que eles estão fazendo é se tornando mais rápidos em fazer as coisas erradas. Para parafrasear Jon Harmer (@jharmer), quem eu agora tenho a sorte de chamar de colega, “você apenas bate seu carro no muro mais rápido”.

Eu passei os últimos 6 meses no começo da minha jornada para entender como a gerência de produtos ágil em grande escala pode funcionar. Vendo na prática. Ajudando uma empresa média a fazer a transição do modelo de cascata (em escala) para o ágil (em escala). Pense em algumas dúzias de equipes (algumas centenas de pessoas) trabalhando para entregar algumas centenas de sistemas, para uma organização multibilionária. Meus leitores mais antigos saberão que o que escrevo aqui é orientado em grande parte pela absorção, adoção, extrapolação e generalização de experiências pelos padrões e conceitos e ideias aplicáveis.

Para equipes pequenas, o desenvolvimento ágil sem um foco nos resultados corretos é se tornar mais rápido em construir a coisa errada. Como resultado, você só cria mais coisa errada. Uma falta de foco nos resultados não é melhor do que um foco nos resultados errados. Ser focado na saída não é ser focado nos resultados.

Para o ágil em escala, eu não acredito que isso seja verdade. Em escala, se você não estiver direcionando sua execução com foco no resultado, eu não acredito que você esteja realmente mais rápido – você está apenas diferente. Em escala, para melhorar a inteligência do Jon, “você ainda vai bater seu carro no muro, mas não necessariamente mais rápido”.

A diferença chave aqui é em torno do sistema de dinâmicas opostas de encapsulamento e coordenação. Organizações menores têm uma necessidade muito menor de coordenação – “tudo” acontece dentro da equipe. Vale a pena explorar o porquê de isso acontecer.

A escala é construída necessariamente com orquestração e planejamento

Você pode acreditar que o planejamento seja um anátema à agilidade. A guerra clássica entre o racionalismo e o empirismo, o que me fazer querer reler “The design of the design”, de Brook. Eu também suspeito que um outro ser iluminado com quem estou empolgado em trabalhar, Dave Nicolette (@davenicolette), sugeriria que o “ágil em escala” pode ser paradoxal no começo. Ele provavelmente já escreveu sobre isso também – mas eu quero ouvir ele falando disso ?. No fim do dia, isso depende de como você define agilidade, ou mais precisamente como você define “auto direcionado”.

Sempre existe um contexto em que a autodeterminação se aplique. Como eu estou apontando vários nomes neste artigo, vou agradecer novamente ao Andy Polaine (@apolaine) pelo visual que agora está permanentemente inserido no conceito de contextos aninhados para mim.

Concordar que as equipes tenham liberdade de operação e autonomia para a tomada de decisões dentro do contexto de trabalharem juntos é um pressuposto das metodologias ágeis. Fazer isso para atingir um resultado compartilhado que seja desejado é a chave para aproveitar a agilidade como uma força poderosa para atingir os objetivos de negócios.

Eu proponho que as equipes ágeis orientadas a resultados são o pé-de-cabra que podemos utilizar para afrouxar e potencialmente desatar o Nó Górdio da agilidade, e escalar sendo logicamente consistente. Então – enquanto quisermos aceitar a definição de ágil onde “autodirigido” significa ter autonomia dentro do contexto da função da equipe, nós somente precisamos articular o resto do contexto.

• Agilidade em escala requer múltiplas equipes pequenas.
• Cada equipe tem autonomia dentro do contexto da função da equipe.
• Cada equipe está trabalhando em coordenação com outras equipes para a entrega.
• Cada equipe é focada nos objetivos de negócio.

Esse foco nos objetivos de negócio – os “porquês” de investir em construir algo – é a definição de ser orientado a resultado.

Essa coordenação exige planejamento, de maneira contínua. Existe um contínuo teórico entre as ações não coordenadas e as puramente síncronas. Quanto menos sistemas altamente acoplados e menos recursos compartilhados, menos coordenação é necessária. Como um tecnólogo, eu posso imaginar uma situação onde todos os sistemas não desacoplados, e nenhuma equipe é sobrecarregada; através de uma combinação de decisões de arquitetura e treinamentos da equipe. Como um consultor, eu estou confortável em dizer que nunca haverá uma empresa em escala que evite coordenação e planejamento.

Porque as coisas mudam.

Todos têm um plano até…

“Todos tem um plano, até serem atingidos” – Mike Tyson

Existem muitas versões desse conceito, essa é a que me fisgou anos atrás. Outros lutadores se preparariam para uma luta com o Sr. Tyson, preparando um plano de dançar em volta dele, cansá-lo através dos muitos rounds, e então utilizar sua grande resistência e habilidade para vencer a luta. O Sr. Tyson regularmente tornava aqueles planos inúteis fazendo coisas tipo nocautear o oponente na primeira metade do primeiro round. Como o Sr. Tyson dizia – “Todos tem um plano, até serem atingidos”.

Para mim, esse é o marco para lembrar que existem muitas razões para seu plano mudar. Outro colega meu, Jeff Howey (@AgileAlchemy) é aficionado em perguntar para a sala – “o plano é uma mentira, certo? – Para o que todos balançam a cabeça dizendo sim. Isso não é único às metodologias ágeis – o método cascata também é uma mentira.

Aproximadamente 5 anos atrás, eu explorei muitas razões pelas quais os produtos fracassam. Entre as razões estão variações que refletem uma necessidade de mudança do planejamento. Você percebe que (obtendo novas informações, fora do processo de desenvolvimento) que sua equipe vai fracassar, então você precisa mudar. Um mecanismo formal para fazer isso é o pre-mortem.

1. Você pegou o cliente errado para o qual resolver problemas.
2. Para o cliente que você pegou, você pegou o problema errado para resolver.
3. Você cometeu o erro de declarar sucesso sem ter resolvido completamente o problema.
4. Sua abordagem da solução – você descobre – não vai resolver o problema.
5. Sua execução / implementação é incapaz de alcançar as necessidades do seu projeto, e sendo assim, não vai resolver o problema (mesmo com um projeto viável)

Os últimos dois cenários, (4) e (5), não são, na verdade, exemplos de seleção do problema errado, eles são exemplos de fracasso na resolução do problema selecionado. Normalmente, esses não são problemas com o planejamento (a escolha do problema a ser resolvido), apesar de que eles poderiam ser. Na situação onde suas escolhas estratégicas sobre quais problemas resolver são tanto valiosas quanto desejáveis, é possível que elas não sejam possíveis para que seu time execute. Pode ser que sua estratégia esteja além das habilidades da sua equipe, e nesse caso você precisa escolher um problema diferente para resolver. Eu os listei por uma questão de conhecimento, embora eu os tenha visto apenas uma vez como um fator de fracasso. Normalmente, outras coisas também estão erradas.

Você pode fazer um exercício poderoso, chamado premortem, para ajudar a descobrir com antecipação o que está errado com seu plano. Proposto pelo psicólogo Gary Klein, é um dos favoritos do Daniel Kahneman. Aqui está uma explicação de 3 minutos.

Resultados e Colaboração e Ágil

Quando uma pequena equipe ágil (Ex.: conforme planejado) descobre que eles estão trabalhando no problema errado – por qualquer das razões listadas – eles podem mudar facilmente. Eles podem mudar porque estão colaborando diretamente com os investidores do negócio. Eles estão diretamente engajados com seus clientes e recebendo os sinais que acionam a descoberta de que os planos precisam ser mudados. Da perspectiva organizacional, você pode descrever essa equipe como sendo encapsulada – a habilidade de mudar os planos está dentro de sua área de influência colaborativa.

Eles podem mudar os planos. Eles podem mudar os planos porque eles estão trabalhando juntos – tanto o lado do negócio (patrocinadores/clientes/investidores/usuários) quanto o lado da tecnologia (a equipe criando o produto ou solução). Eles compartilham um entendimento do valor/oportunidade/desejabilidade e custo/complexidade/tempo de solução do problema. Eles compartilham um entendimento da adequabilidade do projeto para potencialmente resolver o problema.

Eles compartilham um entendimento de suas habilidades para executar o projeto. Eles podem coletivamente gerenciar a incerteza tecnológica e de mercado sobre o porquê, em que e como eles estão trabalhando.

Essa equipe é orientada a resultados. E quando eles são metaforicamente socados no rosto, eles podem se virar para uma nova maneira de resolver o problema, para uma nova definição de “resolvido” ou para um novo problema a ser resolvido. Pela equipe ser encapsulada a complexidade dessa mudança pode passar despercebida. Os efeitos de ondas e a nova orquestração são resolvidos dentro da equipe.

Se a equipe não fosse orientada a resultados, sua capacidade de mudar radicalmente ainda seria comparável – a equipe poderia receber um novo conjunto de atribuições, e iriam descartar o trabalho prévio, resolver as dependências e fazer o novo trabalho. De fora dessa equipe encapsulada, o processo de mudança pareceria ser simples assim.

Esse equívoco – que a mudança é fácil para equipes ágeis, independente do foco no resultado – é a causa raiz das dificuldades que as empresas enfrentam para adotar as práticas ágeis para grandes ecossistemas/organizações.

Ágil sem resultados

O que acontece quando essa equipe tenta não ser direcionada a resultados? OK. Insira o som de pneus derrapando (ou a agulha de uma vitrola arrastada pela superfície). Eu tenho repetidamente desafiado os outros autores a fazer o seguinte:

1. Descrever algo ruim.
2. Dar o nome de algo bom (como plano de ação) para algo ruim.
3. Eloquentemente discuta sobre o porquê de a algo ruim ser genuinamente ruim.
4. Declarar a coisa boa no número (2) ruim, porque a coisa ruim do número (1) é, na verdade, ruim.

Eu vou tentar e evitar o mesmo erro. Se a equipe não for orientada a resultados, seu processo não é ágil (é somente uma entrega incremental das especificações do projeto). O que essa equipe pode fazer, como eu disse antes, é gerar mais saídas. Esse é um processo mais eficiente, mas somente mais eficiente – não mais efetivo. Ele ajuda você a bater no muro mais rápido.  E isso o torna algo ruim.

Coordenação e execução efetivas são irrelevantes quando você está solucionando o problema errado.

Resultados e elaboração progressiva

Uma característica interessante dos métodos ágeis, para gerentes de produtos, é como os “requisitos” são gerenciados. Hoje em dia, eu realmente falo sobre intencionalidade porque eu estou falando sobre a intenção da organização atingir um resultado. O termo intencionalidade ressoa com meu público e me ajuda a ter foco.

Um princípio ágil (acredito que ouvi ele pela primeira vez de Kent Beck em 2000) é sobre fazer as coisas no último momento responsável. É também uma característica de fabricação lean). No desenvolvimento de software, “fazer algo” é criar um inventário de trabalho em andamento. A compreensão dos pensamentos, projetos, códigos, testes e resultados dos testes são inventário. Inventário. Não o crie até que você tenha que criar. YAGNI (do inglês: You ain’t gonna need that – Você não vai precisar disso – Então não construa) é uma maneira de lembrar disso.

Assim como o planejamento em ondas nos encoraja a esboçar linhas de tempo e direccionalmente corrigir os planos para o futuro, com planejamento detalhado reservado para o futuro imediato, a intencionalidade é progressivamente articulada em relação ao tempo e ao escopo. Nós evitamos investir para criar algo que provavelmente será descartado – detalhes específicos sobre o futuro distante.

Existe um objetivo de longo prazo ou um resultado que você está tentando alcançar. Para suportar esse objetivo de longo prazo você pode definir algumas iniciativas estratégicas. Para avançar com essas iniciativas você também pode identificar um conjunto de produtos valiosos e entregáveis, ou potencialidades do produto. Esses são passos em direção do objetivo de longo prazo. A primeira dessas potencialidades pode ser progressivamente elaborada em funcionalidades ou histórias – que são o que a equipe trabalha para entregas nos lançamentos ou sprints, recebendo feedback pelo caminho. Você não constrói todas as histórias que abrangem completamente todas as iniciativas projetadas para atingir o objetivo. Você elabora progressivamente, conforme necessário. No último momento responsável.

Uma lista para acompanhar a intencionalidade progressivamente articulada:

• Estratégia: um objetivo de longo prazo, vários anos no escopo de uma organização em escala.
• Oportunidade: uma iniciativa suportando a estratégia, facilmente para um ano ou mais, talvez divisível em escopos.
• Épico: um componente ou capacidade chave como parte da oportunidade, posicionamento de mercado ou escopo do serviço.
• Funcionalidade: uma coleção de resultados do ponto de vista do usuário, entregas irredutíveis e testáveis pelo usuário.
• História: um cenário onde a entrega de valor para ao menos um cliente em ao menos um contexto.

Com uma equipe pequena, toda essa elaboração progressiva faz duas coisas. Primeiro, estabelece um contexto – o geral. Segundo, leva ao foco – o que a equipe tem que fazer para atingir o correto agora. No entanto, traz o custo da inextrincável conexão entre os requisitos e os elementos do projeto em múltiplos níveis.

A elaboração progressiva das intenções incorpora elementos de projeto e planejamento.

• As histórias fazem sentido, dada a funcionalidade escolhida.
• A funcionalidade reflete um conjunto de decisões de projeto (em termos de interação e implementação) para descobrir a intencionalidade do épico.
• O épico manifesta algumas hipóteses e suposições sobre como melhor descobrir uma oportunidade.
• A oportunidade representa um aspecto de uma maneira de ser bem-sucedido com uma estratégia.

Isso é mais do que intencionalidade, também é projeto e planejamento. Eles estão intrincadamente conectados.

Conforme você atravessa múltiplos contextos – progressivamente se aprofundando no problema – você está inserindo elementos de planejamento e decisões de projeto naquilo que sua equipe fará.

Conforme você se engaja com o mercado ao longo do tempo – você vai descobrindo que você precisa adaptar o plano. Como uma equipe ágil pequena, você consegue fazer isso facilmente. Você revisa decisões colocando elas para cima ou para baixo na escala de elaboração e você se adapta. Operar em escala é sobre orquestrar e coordenar. Planejar. É por isso que o foco no resultado é um requisito para as metodologias ágeis funcionarem em escala. Conforme o resultado esperado muda, os planos mudam.

Resultados e planejamento em escala

Quando você está orquestrando uma grande organização trabalhando em equipe, existem necessariamente elementos de decomposição e alocação de responsabilidades para a execução das partes do plano. Isso é verdade para as organizações com estrutura em cascata e ágil. Ambas fazem isso, mas fazem de maneiras diferentes – um aspecto que torna a transformação de uma estrutura na outra difícil.

No mundo da estrutura em cascata, as áreas da organização, e suas divisões, e equipes, receberão “uma parte do plano” para executarem. Alguns coordenam a execução e alocação das responsabilidades entre as equipes. É assim que grandes projetos sempre foram feitos.

Quando uma grande empresa que não é ágil diz que é ágil orquestrando planos entre as equipes, ao invés da intencionalidade progressivamente elaborada, o sistema se comporta de uma maneira similar à uma grande organização em cascata.

Quando o plano muda, as coisas ficam interessantes – a maneira que vivemos em momentos interessantes é meio “interessante”.

Uma das equipes vai descobrir que sua parte do plano não vai funcionar. Talvez eles recebam feedback negativo do cliente sobre um protótipo ou sobre os entregáveis da sprint atual. A equipe quer mudar o plano, para incorporar esse feedback. O problema é que a equipe conhece somente o plano e não a intenção; falta contexto para contexto para efetivamente desviar-se (ou modificar) o plano para trabalhar com problemas reais. Eles têm que, burocraticamente, enviar suas descobertas para cima na cadeia e iniciar discussões sobre como adaptar o plano. Enquanto isso, nada é feito. Isso é “em escala”, mas não é “ágil”. É a mesma coisa para equipes em cascata e “não-ágeis”.

Para uma equipe poder adaptar o plano eles precisam entender a intenção. Com informações sobre a intenção, eles podem se organizar dentro do contexto de como abordar a entrega da sua parte da intencionalidade. Eles podem avaliar se o que eles descobriram invalida também o enquadramento que a intencionalidade tem um nível acima. E essa equipe pode determinar como eles vão adaptar, sem ter que escalar toda a elaboração progressiva – a menos que isso seja necessário.

Essa distinção é a chave. Quando cada equipe está trabalhando em uma parte do plano, eles não têm conhecimento sobre as dependências entre as equipes e sempre precisam escalar antes de mudar. Não existe autonomia no que diz respeito a se adaptar as mudanças nas circunstâncias. Quando cada equipe trabalha para entregar uma parta da intenção, eles têm autonomia e flexibilidade para mudar o que eles constroem para a entrega. Eles escalam somente quando o que eles descobrem pode invalidar a intencionalidade – e então a escalada vai somente até onde precisa.

O que é único é que com foco na intencionalidade, em cada estágio da elaboração progressiva, as equipes podem adaptar-se dentro de seu contexto, sem interromper ou invalidar o contexto maior da intencionalidade. Esse é o molho secreto para a agilidade em escala. Sem ele, você tem apenas cascata, ágil-apenas-no-nome, em escala.

Agilidade em escala não pode funcionar sem intencionalidade.

Velocidade nas mudanças exige intencionalidade

Próximo do início desse artigo, eu assegurei que sem a intencionalidade, o “ágil” em organizações em escala não é mais rápido. Se não houverem mudanças aos planos, elas seriam mais rápidas do que uma organização no modelo em cascata, evitar marchas forçadas e ser mais eficiente no geral, é um resultado de uma cadencia frequente de entregas. No entanto, cada equipe vai ser atingida no rosto e cada plano terá que mudar.

A necessidade de mudar os planos – e todas as dependências entre equipes – é o que desacelera as equipes não ágeis em escala, fazendo com que não sejam mais rápidas que equipes no modelo cascada. Trabalhar com intencionalidades progressivamente elaboradas é o que permite a agilidade e adaptação das equipes pequenas trabalhando como parte de uma organização maior. Sem atrasos.

 

***

Scott Sehlhorst faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela Redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://tynerblain.com/blog/2017/05/24/agile-at-scale-outcome-driven-or-broken