Na Construx Software Executive Summit do ano passado, um dos problemas que nós exploramos foi a forma de escalar o desenvolvimento de software, principalmente desenvolvimento Agile, entre projetos, portfólios, geografias e empresas. Como parte disso, avaliamos 3 diferentes métodos populares para escalar Agile: LeSS (Large Scale Scrum), SAFe (Scaled Agile Framework), e DAD (isciplined Agile Delivery).

LeSS e LeSS Huge – Scrum de larga escala

Craig Larman, coautor de LeSS (e LeSS Huge – para programas realmente importantes), começou criticando o “jogo do contrato” ou “jogo de compromisso” que o gerenciamento, os desenvolvedores e os clientes tradicionalmente jogam para transferir a culpa inicial para quando as coisas (inevitavelmente) dão errado em um projeto. Era provocador e divertido, mas tinha pouco a ver com escalar Agile.

Ele passou o resto de seu tempo construindo o caso para reestruturação das organizações em torno de equipes de recursos multifuncionais end-to-end que entregam código de trabalho em vez de equipes de componentes especializados e grupos funcionais ou matrizes. As equipes de recursos podem se mover mais rápido, através da partilha de código e conhecimento, resolver problemas em conjunto e minimizando handoffs e atrasos.

A arquitetura empresarial em LeSS parece fácil. Cada membro da equipe é um desenvolvedor – e cada desenvolvedor é um arquiteto. Os arquitetos trabalham juntos no exterior de equipes e projetos em comunidades de práticas voluntárias para colaborar e dar forma à arquitetura da organização em conjunto. Isso parece bom – mas é muito importante que a arquitetura, especialmente em ambientes de grandes empresas, tente gerenciar out-of-band. LeSS não explica como eliminar a especialização, e trabalhar sem definição de arquitetura inicial, os padrões arquitetônicos e a supervisão vai ajudar a construir grandes sistemas que funcionam com outros sistemas grandes.

LeSS deveria ser sobre intensificação, mas a maioria do que LeSS expõe se parece com o Scrum feito por muitas pessoas ao mesmo tempo. Não está claro onde termina Scrum e começa o LeSS.

SAFe – Scaled Agile Framework

Não existe lugar para a gestão em LeSS (exceto para proprietários de produtos, que são a restrição da chave para o sucesso – como em Scrum). Implementar LeSS envolve, fundamentalmente, a reestruturação de sua organização em torno de programas orientados pelos negócios e se livrar de gestores e especialistas.

Os gerentes (assim como os arquitetos e outros especialistas) têm um papel no Scaled Agile Framework do SAFe – um método mais detalhado e pesado que pega coisas emprestadas do Agile, Lean e abordagens de desenvolvimento do Waterfall sequencial. As equipes seguem Scrum (e algumas práticas técnicas XP) para construir códigos que realmente funcionem em programas e portfólios.

Na verdade, há muito mais coisas para os gestores fazerem em SAFe, como “Lean-Agile Leaders”, que o Dean Leffingwell passou a maior parte do seu tempo enumerando e elaborando os papéis e as responsabilidades dos gestores na ampliação de programas Agile e liderando a mudança.

Alguns dos pontos que ficaram comigo:

• A maneira mais fácil de mudar a cultura é ter sucesso. Foco na execução, não na cultura e a mudança vai seguir seu curso.
• De Deming: apenas os gestores podem mudar o sistema – porque os gerentes criam sistemas. A mudança tem que vir do meio.
• Os gerentes precisam encontrar maneiras de levar as decisões para as equipes e os indivíduos, dando-lhes “filtros de decisões” fortes e claros para que eles entendam como tomar suas próprias decisões.

DAD – Entrega Agile Disciplinada

Scott Ambler não acredita que existe uma maneira para dimensionar o desenvolvimento Agile, porque, em uma empresa, diferentes equipes e projetos vão entregar diferentes tipos de software de maneiras distintas: alguns podem estar seguindo Scrum ou XP, ou Kanban, Lean Startup ou com Deployment Contínuo, ou RUP, ou SAFe, ou uma abordagem Waterfall sequencial (tendo eles boas, ou não tão boas razões, para trabalhar da maneira que eles o fazem).

O Desenvolvimento Disciplinado Agile (DAD) não é um framework de gerenciamento de projetos ou um método de desenvolvimento de software – é um framework de tomada de decisão que analisa a forma como planejar, criar e executar os sistemas de toda a empresa. As camadas DAD sobre Scrum/XP, Lean/Kanban ou outros lifeycles, ajudando os gestores a tomar decisões sobre como gerenciar projetos, como gerenciar os riscos, e como conduzir a mudança.

Projetos, e pessoas que trabalham em projetos, precisam estar (cientes?) empresa-aware – eles precisam trabalhar dentro dos limites da organização, seguir as normas, atender à conformidade, integrar com sistemas herdados e com outros projetos e programas, e alavancar os recursos compartilhados, a expertise e outros ativos em toda a organização.

O desenvolvimento não é o maior problema em escalar o Agile. As mudanças precisam ser feitas em muitas partes diferentes da organização, a fim de se mover mais rápido: governança (incluindo o PMO), compras, finanças, conformidade, gestão de produtos, gerenciamento de dados… E essas mudanças podem levar muito tempo. No DAD, isso não é fácil e não é emocionante. Apenas tem que ser feito.

Escalar Agile é difícil, mas vale a pena

Quase todos nós concordamos com Dean Leffingwell que “ninguém ganha do Agile em nível de equipe”. Mas atingir o mesmo nível de sucesso em um nível organizacional é um problema difícil. Tão difícil que nenhuma das pessoas que deveriam ser especialistas poderia explicar claramente como fazê-lo.

Depois de falar com os gerentes seniores de muitas indústrias e países diferentes, eu aprendi que a maioria das organizações parecem estar encontrando seu próprio caminho, misturando desenvolvimento Waterfall/stage-gate com práticas de gerenciamento enterprise em larga escala com Agile no nível do time. Utilizar as abordagens Agile para explorar ideias e requisitos, prototipagem e pontos técnicos para ajudar a entender a viabilidade, o escopo, as necessidades técnicas e os riscos iniciais, antes de fretar projetos. Começar esses projetos com planejamento, análise suficiente e modelagem inicial para identificar as dependências-chave e os pontos de integração, em seguida, receber equipes Agile para preencher os dados e entregar o software funcionando. Gerenciar esses projetos é como gerenciar quaisquer outros, mas com mais transparência para o estado real do desenvolvimento de software – porque você começa a trabalhar o software em vez de relatórios
de status.

A grande vantagem do Agile ao escalá-lo não é a capacidade de reagir às mudanças contínuas ou mesmo entregar mais rápido ou mais barato. É saber mais cedo se você deve continuar, ou se precisa continuar, ou se você deve parar e fazer outra coisa em seu lugar.

***

Jim Bird 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://swreflections.blogspot.com.br/2014/11/different-ways-of-scaling-agile.html