Escalar Ágil é um assunto cada vez mais em voga, especialmente após quase uma década de experimentação desses métodos, já não é mais necessário provar que a abordagem dá certo.

O desafio agora é outro: como adaptar os métodos adaptáveis para necessidades, digamos assim, de gente grande? As startups começam a crescer e empresas tradicionais percebem a oportunidade. Agile começa a chamar a atenção como um diferencial para o negócio e não apenas mais para TI. Projetos (ou iniciativas) de software isoladas são relativamente simples; Conversar com  o pessoal de operações, auditoria, times remotos, fazer terceirizações, gerenciar projetos maiores, ter uma visão holística de programas, portfolio, trazer previsibilidade, alinhar as iniciativas às necessidades de marketing e jurídicas etc. Esses e outros fatores trazem uma complexidade maior que, a princípio, os primeiros métodos ágeis não eram capazes de responder ou pelo menos não o faziam de maneira muito simples.

A pergunta da vez então era: “como eu escalo isso?” Uma série de iniciativas surgiram para provar que tal método escalava e também alguns frameworks voltados exclusivamente para escala. Num mapeamento não exaustivo recente, levantei algumas abordagens: SAFe, LeSS, Nexus, Scrum at Scale, o próprio DAD e até mesmo o controverso Case Spotify. Nesse artigo, vou discutir minhas percepções sobre o Disciplined Agile Framework.

De antemão, acho honesto informar que minha experiência em escalar Agilidade vem de necessidades específicas de contextos onde trabalhei: necessidades regulatórias (SOX, Basileia etc, PCI entre outros), necessidades de terceirização com times remotos  e limitadas por requisitos trabalhistas e também limitações impostas por estruturas funcionais rígidas com alta especialização (banco de dados, operações etc.). Não cheguei a usar o DAD em profundidade e, apesar de ter estudado o framework, não passei por nenhum dos cursos oficiais e não me aprofundei o suficiente para conhecer todas as suas nuances. Esse artigo é apenas opinativo. Dito isto, vamos em frente.

O DA Framework

Segundo a definição, O Disciplined Agile (DA) Framework de decisão é uma estrutura que fornece orientação para ajudar organizações a simplificar seus processos, de maneira sensível ao contexto, dando uma fundação sólida para a agilidade nos negócios.

Historicamente, o Disciplined Agile Framework  nasceu em 2009 como um framework proprietário da IBM, voltado exclusivamente para estratégias de delivery de software, com sua primeira versão “madura” lançada para o mercado em 2012, por ocasião da publicação do “livro do veleiro”. Mais ou menos na mesma época que o SAFe veio à tona. Naquela época, ao procurar por visões de agilidade em escala, não eram raras as representações do DAD (Disciplined Agile Delivery) como o kernel do SAFe; Enquanto o DAD fava uma visão de como entregar, o SAFe tentava organizar isso em visões táticas e estratégicas. Em 2014 o DAD passou oficialmente para as mãos do DA Consortium, teoricamente rompendo seus laços com a IBM e finalmente, no final de 2017, com a publicação do DA Framework, o DAD tornou-se independente da visão do SAFe, fornecendo sua própria abordagem de agilidade para as visões em níveis de operação, área de TI e para a organização como um todo.

Escala na visão do DA Framework

O DA Consortium tem uma abordagem bem pragmática para aquilo que considera escalar ágil. Ele cita diversos fatores de escala: tamanho do time, distribuição geográfica, distribuição organizacional, compliance, complexidade técnica, complexidade de domínio. Eu particularmente concordo com essa abordagem pois, dentro da minha experiência, são esses os fatores que tendem a complicar o uso do ágil.

O que eu senti falta, ou pelo menos não encontrei de forma tão explícita, foi uma maneira de endereçar especificamente os fatores de complexidade explicitados na teia acima. Como o DA Framework se posiciona como um “framework de decisão sensível ao contexto”, acho que essas decisões poderiam ser mais direcionadas de acordo com um assessment feito com base na escala desses fatores.

Um novo Manifesto Ágil

Uma coisa legal que eu achei na iniciativa é a noção de que a agilidade não deveria ficar restrita às necessidades do cliente e nem às iniciativas de desenvolvimento de software. Nesse sentido, o DA propõe uma evolução do Manifesto Ágil.

O termo “software em funcionamento” seria substituído por Soluções Consumíveis, para dar visibilidade de que nem sempre software é o que agrega valor para a organização. Nesse contexto, soluções consumíveis é um termo bem mais abrangente, numa primeira iniciativa para expandir a agilidade para além da TI.

O termo “colaboração com o cliente” seria substituído por “colaboração com stakeholders”, para dar visibilidade de que num contexto corporativo, é preciso interagir com uma gama de outras partes interessadas não restritas apenas ao cliente da solução. Nesse sentido, a palavra stakeholders é bem mais abrangente e ajuda a dar um contexto da complexidade enfrentada nas iniciativas de desenvolvimento das soluções consumíveis.

Particularmente, acho que mais do que as palavras escolhidas para o manifesto ágil, o que deve ser valorizado é o mindset, e nesse sentido, seria desnecessária qualquer evolução do manifesto original. Por outro lado, essas pequenas alterações podem ser interpretadas como uma licença poética para explicar o conceito do DA, e realmente me ajudaram a pegar o tom da proposta.

Os 7 princípios

Num aprofundamento dos conceitos por trás do manifesto modificado, o DA propõe 7 princípios. Esses princípios são os direcionadores para a mentalidade que alguém buscando escalar a agilidade em sua organização deveria ter.

Existe um princípio core que faz com que o foco seja mantido nos clientes – “Delight Customers” e outros 6 princípios que orbitam, ou melhor, habilitam este princípio. Inicialmente eu achei a ideia um pouco contraditória com o “novo manifesto”, melhor seria se o princípio  fosse “Delight Stakeholders“. Mas depois eu entendi que é preciso colaborar com os stakeholders para no final poder encantar os clientes das soluções consumíveis. Um outro ponto de desconforto em relação a esse princípio é que em alguns momentos o DA parece defender que o cliente seja surpreendido positivamente. Eu particularmente discordo dessa abordagem de gold plating. Eu sou muito mais adepto à gestão de expectativas e à abordagem de customer success do Lincoln Murphy, por exemplo.

Alguns princípios como “be awesome, optimize flow e choice is good” não definem muito o DA Framework além do que os princípios fundamentais do Agile já fazem, por isso não vou entrar muito nos detalhes.

Outros princípios como Enterprise Awareness, Pragmatism e Context Counts por outro lado, vão de encontro à ideia principal do framework.

Enterprise Awareness chama a atenção para os times das iniciativas de que existe um mundo lá fora, e é preciso ter consciência de que esse mundo impacta a maneira como você trabalha e vice-versa.

Context-Counts chama a atenção de que não é possível que um framework prescritivo se encaixe em todos os contextos, principalmente naqueles de maior complexidade. Pragmatismo, outro princípio, complementa o Context-counts  no sentido da falta de compromisso com um framework específico, e o princípio “choice is good” fecha o quebra cabeça, fornecendo estratégias para escolher as melhores ferramentas dado determinado contexto.

Conceitualmente, a ideia me pareceu bastante consistente, embora na prática eu não tenha conseguido enxergar muito como isso funcionaria. Por exemplo, o DA vende sua ideia de ser um “agregador de todos os métodos”, chegando inclusive a criticar corpos de conhecimento como ITIL e PMBoK.  

Contudo, a parte de “choice is good” e a estratégia de utilizar “lâminas de processo” que podem ser escolhidas conforme a necessidade, fazem do DA Framework um grande “AgileBoK”, adotando exatamente a estratégia criticada. O fato de referenciar o PMBoK por PMIBoK e o fato de utilizarem a mesma estratégia criticada denotam uma possível falta de conhecimento dos autores sobre o assunto,  tornando um pouco frágeis seus argumentos de venda.

A Big Picture

Nesse ponto, o DA começa a apresentar suas “Disciplinas”, exatamente como fazem os corpos de conhecimento. Eu gosto de corpos de conhecimento, os BoKs da vida, pois acho legal agregar ferramentas e técnicas e permitir sua comparação. Minha única crítica, mais uma vez, é que fica parecendo que o DA Consortium criou exatamente aquilo que jurou combater.

Essencialmente, o Framework atua nos níveis de entrega, DevOps, Área de TI e Organizacional, sendo que originalmente direcionava apenas a parte de entrega.

No nível de Delivery, a estratégia é fornecer fluxos completos de ciclo de vida, com várias estratégias que podem ser escolhidas levando-se em consideração desde a maturidade do time até mesmo a estratégia de negócios: há sugestões de fluxos de agile básico usando Scrum, e até mesmo fluxos exploratórios para startups. O que é bem legal e pertinente. Tenho visto Agile Coaches forçando a barra de processos em cima de times que ainda não têm  condições de adotar práticas mais avançadas e realmente a abordagem do DA traz essa reflexão.

No nível de DevOps, a ideia é discutir boas práticas na interação do desenvolvimento junto com operações. As abordagens são bem interessantes, discutem agilidade do ponto de vista de Segurança, Help Desk, Administração de Dados, Operações e gestão de releases. Entretanto, foi ao subir para esse nível que fiquei decepcionado, pois, sinceramente, esperava a apresentação de uma estratégia para aplicação de agilidade além da Tecnologia, o que não aconteceu.

No nível de Área de TI, são apresentadas estratégias em nível tático e estratégico de gestão de tecnologia, assim como a interação da área de TI com o restante da empresa. São apresentadas estratégias de gestão de pessoas, produtos, portfolio, governança, arquitetura organizacional e engenharia de reuso, contudo, num nível bem mais raso do que DAD e DevOps.

Finalmente, no nível Organizacional (Disciplined Agile Enterprise), a coisa ficou bem confusa pra mim. Minha impressão é que foram ultrapassados os limites de um framework, invadindo disciplinas como Marketing, Vendas, Financeiro, Jurídico e Compras, para as quais já existe muito conhecimento e práticas que foram desenvolvidas ao longo de décadas. Eu esperava que a abordagem simplesmente citasse alguns requisitos, pontos de contato dos outros níveis mas em alguns momentos o DA Framework. Entretanto, o as diretrizes do DA parecem tentar ensinar para esses departamentos qual é o jeito correto de se trabalhar. Resumindo, passou do ponto.

Conclusão

Juntando tudo, me pareceu que:

• De verdade, apesar da tentativa, o foco continua em TI (e vai ser difícil sair)
• Me pareceu que faltou uma estratégia de assessment e implantação mais clara.
• Faltou também uma estratégia um visão específica para as variáveis de escala: tamanho do time, distribuição geográfica e organizacional, compliance, complexidade técnica e de domínio
• Tentativa de reinventar a roda na Administração de empresas, mas sem arranhar a superfície da complexidade dessas disciplinas

No final, é um bom Framework geral, bem estruturado e pertinente, mas seu detalhamento é, assim como o PMBoK, um bom BoK (body of knowledge)

Este texto também faz parte da ContÁgil, nossa newsletter mensal com curadoria de conteúdo pela equipe da Plataformatec sobre gerenciamento de projetos, metodologias e cultura ágil. Se você ainda não é assinante, assine agora! 🙂