O segredo sombrio do Agile? A TI tem pouca necessidade dele

Agile, supostamente, é notícia velha. Empresas avançadas? Elas saltaram para o DevOps. Exceto que muitas equipes de aplicativos que não apenas não adotaram técnicas ágeis, como sequer conseguem perceber como o fariam.

Você pode achar isso surpreendente – até que  dê uma olhada mais de perto no que essas equipes precisam fazer: Há muito pouca sobreposição entre seus objetivos e o que as metodologias ágeis oferecem.

Metodologias ágeis, especialmente o Scrum, que muitos gerentes de TI acham que são sinônimos de Agile, são melhores no que a TI menos faz: desenvolver novos aplicativos.

Com exceção do site e dos aplicativos móveis da empresa, um dos princípios básicos da TI é “compre quando puder, construa quando necessário.” A TI licencia algo como 90% de todas as novas funcionalidades na forma de comerciais software (COTS) e software como serviço (SaaS), deixando 10 por cento para software desenvolvido internamente.

Scrum, Kanban, Lean Software Development e a maioria das outras metodologias ágeis são projetadas para os 10%, não para os 90%. Além disso, em um típico departamento de TI, cerca de 70% das horas de desenvolvedor vão para manter e aprimorar aplicativos já em produção, deixando 30% para implementar novos.

Faça as contas. O Agile é útil principalmente para 10% dos 30% – em outras palavras, ele lida com 3% do que as equipes de aplicativos de TI são obrigadas a fazer.

Seu percentual pode variar. Conecte seus próprios números. O resultado ainda será pequeno, embora não precise ser.

Manutenção e aprimoramentos da maneira ágil
Vamos pegar o fácil primeiro: os pedidos de manutenção e aprimoramento que constituem muito do que a TI faz no dia a dia.

Você nem precisa ficar de olho na fila de manutenção e aprimoramento para ver o quanto ela se parece com um backlog ágil. Adicione um proprietário de produto, comece a frasear solicitações como histórias de usuário (chegaremos a isso em um minuto). E aplique Kanban: o proprietário do produto define as prioridades e, sempre que um desenvolvedor terminar uma história de usuário, ele escolhe a próxima da lista de pendências para trabalhar. É simples, impõe muito pouca sobrecarga e faz o trabalho fluir.

Agile COTS
A aplicação de metodologias ágeis às implementações COTS não diz respeito tão simples a aplicá-las à manutenção e ao aprimoramentos.  Implementar grandes sistemas não é tão simples quanto lidar com manutenção e melhorias, ponto final.

Mas você também pode aplicar técnicas ágeis ao COTS. Você apenas tem que reconhecer dois pontos cruciais.

Primeiro: Implementar COTS, seja no local ou através de software como serviço (SaaS), não é apenas como desenvolver software do zero, com talvez um ou dois ajustes necessários. É diferente em maneiras profundas que tornam o Scrum e o Kanban severamente inadequados para o trabalho.

O segundo é algo que já abordamos, só que pode usar metodologias mais ágeis do que Scrum e Kanban.

App dev vs COTS: tudo começa com os dados
Quando as equipes de TI desenvolvem software, elas precisam entender o que “a empresa” precisa que o software faça. Uma vez que eles chegaram a esse entendimento, eles não começam o desenvolvimento.

Eles começam projetando estruturas de dados. O aplicativo vem depois. Exceto, isto é, quando eles não precisam projetar estruturas de dados porque um banco de dados existente já lida com o que o novo aplicativo precisa.

Comprar quando você pode e construir-quando-você-tem são tarefas profundamente diferentes.

Quando a TI implementa vários pacotes COTS/SaaS, os bancos de dados existentes tornam o trabalho mais difícil, não mais fácil. Cada pacote vem com seu próprio banco de dados, e quando os fornecedores de software projetam seus bancos de dados, eles não levam os que você já tem em conta, porque eles não podem.

Assim, quando implementam um pacote COTS, precisam rastrear todos os bancos de dados existentes que armazenam os mesmos dados que o novo aplicativo também gerencia – não para aproveitá-los, mas para descobrir como manter os dados sobrepostos sincronizados.

Quando se trata de gerenciar dados, o desenvolvimento interno e as implementações de pacotes são completamente diferentes.

Descrevendo o que o software deve fazer
Com os dados em mãos, as equipes de aplicativos precisam descrever o que a empresa deseja que o software faça. Variantes mais ágeis prescrevem o uso de “histórias de usuários” para este propósito – afirmações tomam a forma, “Como um <tipo de usuário> eu quero <a meta> para que <bom motivo>”. Por exemplo, “Como um operador de telemarketing Quero armazenar informações sobre residências de clientes, por isso só chamo pessoas que possam querer comprar o próximo produto que estou vendendo”.

Ok, o exemplo é obviamente ficção, mas não se preocupe com isso. Preocupe-se com o fato de que se você está implementando um sistema de CRM, você desperdiçará o tempo de todos e incomodará os gerentes de negócios se insistir nesse tipo de coisa. Se você estiver implementando um pacote de CRM que não armazene informações sobre todas as formas de “cliente”, não estará implementando um pacote de CRM.

Quando você implementa o software COTS ou SaaS, o argumento usual é se deve implementá-lo como “plain vanilla” ou adaptá-lo para suportar os processos e práticas de negócios da empresa. Estas são alternativas extremamente bobas para discutir.

O software COTS é fornecido com versões explícitas ou implícitas de processos de negócios que, em muitos casos, são superiores àquelas usadas atualmente nas áreas de negócios que o utilizarão. Mas em muitos outros casos, não.

Aqueles que defendem a customização (porque a TI precisa deixar seus “clientes internos” felizes) estão fazendo lobby, gastando muito dinheiro implementando um software novo e brilhante para que você possa cuidar do seu negócio exatamente como está costumado.

Grande custo, sem melhoria de negócios, por design . Por quê? É tão simples, porque não há chance de um processo de negócios ser diferente.

Às vezes – na verdade, por definição – uma empresa é a melhor do ramo em uma coisa ou outra. Force o simples e a TI estará insistindo na deterioração dos negócios como estratégia.

Se a TI e o negócio que ela suporta vão ter um argumento, plain vanilla vs. customização, estarã incorrendo em um erro.  Você pode ignorá-lo completamente.

COTS de dois estágios
Quando uma empresa (não a TI) implementa uma mudança intencional de negócios ativada por COTS, há dois estágios no esforço: tornar o software competente e otimizar os negócios.

Você pode manipular o primeiro estágio usando uma variante ágil pouco conhecida, chamada de piloto de sala de conferência (CRP). Como funciona?

Primeiro, a TI carrega os dados principais – dados do cliente, dados do produto e assim por diante – no banco de dados do novo pacote. Em seguida, o gerente de projeto reserva uma grande sala de conferência carregada com muitos quadros brancos, monitores grandes e outras coisas legais. Em seguida, vem uma grande pilha de transações comerciais que o novo pacote terá que lidar para ser competente no negócio.

Essas transações comerciais podem ser o resultado de um plano de teste cuidadosamente elaborado. Ou podem ser o que quer que tenha sido processado no mês passado ou no mês anterior. Qualquer abordagem funciona bem.

Em seguida, você atrai vários usuários corporativos e alguns gurus de aplicativos, trava a porta e ocasionalmente coloca algumas pizzas e bebidas variadas.

O que acontece atrás da porta trancada? Um usuário de negócios pega uma transação, tenta fazê-la funcionar com o software como está e explica aos gurus: “Não consigo processar essa transação porque …” O desenvolvedor corrige o “porque” e passa para o próximo razão. Depois de um tempo, os porquês se tornam mais difíceis de encontrar. À medida que o fazem, o Estágio 1 desvanece e o Estágio 2 desaparece.

A transição é marcada por uma mudança na conversa. Enquanto no estágio 1 os usuários de negócios explicavam por que não conseguiam processar uma transação, as conversas do Estágio 2 soavam como: “Eu poderia processar essa transação mais facilmente se o software fizesse isso …”

Note que as conversas não são sobre tornar o software mais competente. Eles são sobre tornar os processos mais eficazes – sobre otimização de negócios.

Ah, e a propósito, seus desenvolvedores não são tomadores de pedidos passivos nesse processo. A qualquer momento, eles são encorajados a dizer algo como: “Fazer o software fazer isso seria confuso e caro. Que tal fazer isso em vez disso?

O segredo mais sombrio do Agile
Agile tem um segredo sombrio do que ser inútil para a maioria do que a TI faz: desenvolvimento ágil diz respeito à entrega de produtos. Seja Scrum, Kanban, Lean ou o que você tiver, o projeto é concluído quando a TI fornece um produto de software.

Mas, quer você esteja usando o Scrum para desenvolver software do zero ou um pacote usando o CRP, a entrega do produto não é o que alguém precisa. Se não for uma mudança intencional nos negócios, não fará sentido. O aplicativo é uma alavanca que a empresa pode usar para alcançar a mudança desejada.

Todo o segundo estágio do CRP é fazer o negócio funcionar de maneira diferente e melhor. Mudança intencional de negócios é incorporada a ele.

O uso de técnicas ágeis para desenvolver um aplicativo, por outro lado, está repleto de riscos de que a mudança nos negócios seja o problema a mais, porque tudo sobre Scrum, Kanban e o restante é cuidadosamente elaborado para tornar a entrega do produto a meta. Se não fosse esse o caso, não teríamos proprietários de produtos e as histórias de usuários não seriam sobre o que o software deve fazer.

O que é necessário são técnicas que começam com projetos para fazer melhor as coisas, transformam esses projetos em histórias de usuários e adicionam tarefas ao backlog que são todas sobre como mudar os negócios.

Ou, ainda melhor do que isso, técnicas para melhorar incrementalmente o desempenho das áreas de negócios, realizando os incrementos iterativos por meio de alterações e aprimoramentos de aplicativos vinculados às ideias de melhoria de negócios.

Conclusão
Ok, como escândalos vão, os segredos mais sombrios do Agile também. No entanto, ignorá-los pode levar a sérios desperdícios de esforços, argumentos inúteis e sucessos de projetos que se parecem muito com falhas quando alguém pergunta se a empresa está melhor do que costumava ser.