Ágil e TBM: transformando o negócio de TI para melhor.

*Dean Leffingwell é o criador do Scaled Agile framework (SAFe®) e cofundador da Scaled Agile, Inc. Ele atua com empresas que escalam o Agile de poucas equipes para dezenas e até centenas de times, construindo sistemas e soluções de software em larga escala. 

Um analista de TI resumiu bem: “Há poucos anos, as empresas já usavam Agile e investiam entre 5 e 10 milhões de dólares em programas Agile. Em uma base de investimento e governança relativa, realmente não importava como era gasto ou em que era gasto. Foi um experimento interessante, e eles gostaram dos resultados. Mas agora, eles estão analisando programas que exigirão US$ 50 milhões a US$ 100 milhões ou mais de investimento e serão concluídos com Ágil. Isso muda tudo.

Esse aspecto chama a atenção da diretoria executiva, especialmente de CIOs e CFOs, que percebem que não podem mais ignorar o Ágil pois ele está prestes a dominar a maioria dos processos da empresa. Se não adotarem novos modelos financeiros e de governança agora, serão ultrapassados.

Hoje, o desempenho das empresas que escalaram com sucesso o desenvolvimento Agile se reflete em lançamentos mais frequentes, maior rapidez no time to market, qualidade superior e melhor engajamento dos colaboradores. A produtividade pode aumentar significativamente, entre 30% e 50%, reduzindo o tempo para chegar ao mercado geralmente em duas a três vezes ou mais. O engajamento dos colaboradores cresce à medida que eles veem seu código chegar ao mercado mais rapidamente e receber feedback mais ágil dos usuários.

O fato é que o Ágil não é uma moda passageira. Trata-se de uma megatendência que está transformando os negócios e o setor de TI para melhor.

Atualmente, o Ágil exige um tipo diferente de envolvimento com os negócios. No passado, a equipe de TI poderia dizer: "Ok, aqui está o que você pediu". O negócio pode responder à entrega (um ano depois) dizendo: “Isso não é exatamente o que pedimos e, aliás, as necessidades da empresa evoluíram e agora exigem algo diferente.”

Tradicionalmente, a TI seguia um processo lógico: colaborar com os analistas de negócio, documentar as especificações, elaborar o business case, construir a solução e seguir adiante.

Mas realmente não funciona assim. No lado da TI, a realidade é a seguinte: sua solução só é boa quando os proprietários da empresa dizem que é boa. Não importa se você o escreveu de acordo com as especificações. Só importa se o proprietário da empresa disser que resolve seu problema e quer continuar colaborando.

Entre no Ágil. As pessoas nas linhas de negócios que se beneficiam dessas aplicações devem se envolver e permanecer envolvidas no desenvolvimento da solução. Não existe "escreva a especificação, preencha um cheque e vá embora". Agora, o impacto no negócio é significativo, mas o nível necessário de engajamento também é maior. A única maneira de construir uma solução é fazê-la juntos.

O modelo scaled Agile envolve diretamente o proprietário do negócio no feedback, na tomada de decisões informada, na priorização contínua do trabalho e em tudo que é necessário para garantir que o resultado atenda à necessidade atual. A transferência tradicional mudou. O desenvolvimento ágil de soluções não é uma função isolada ou uma série de especificações. Não é um caso de negócios que comprove teoricamente o ponto. Em vez disso, são pessoas trabalhando juntas de forma colaborativa durante todo o período de tempo de desenvolvimento.

Infelizmente, os modelos tradicionais de financiamento baseados em projetos não funcionam para Agile. Esses projetos geram “trabalho temporário para pessoas temporárias” e, embora seja uma forma prática de organizar novas tarefas, não favorecem um fluxo contínuo de valor.

Na abordagem Ágil, a gestão do trabalho ocorre de maneira distinta. Não é por tarefa individual e uso de tempo; É por meio de pequenos segmentos de valor que você deseja ver fluir pelo sistema em tempo real. O impacto é imediatamente visível quando alguém diz que sua organização está organizada funcionalmente e inicia projetos e mede o uso.

O mantra Ágil são os produtos, não os projetos. Isso representa uma mudança significativa na forma como a organização pensa sobre investimentos, finanças e retorno, e requer ferramentas baseadas em valor em vez de baseadas em tarefas. Grande parte do que existe na contabilidade tradicional sobre trabalho baseado em projetos, folhas de ponto, registros e capturas, são grandes obstáculos ao fluxo de valor.

A metodologia ágil consiste em responder a mudanças em vez de seguir um plano. E isso requer uma mudança para evidências objetivas: feedback rápido, indicadores precoces e previsibilidade. As equipes ágeis fizeram o que disseram que fariam em um prazo específico? Se o proprietário de uma empresa quiser fazer outra coisa, as equipes Ágeis podem mudar?

No geral, o modelo muda do ROI para o desenvolvimento baseado em hipóteses e no produto mínimo viável (MVP). A ideia teórica de ROI é tão atraente quanto um número concreto, mas o ROI é apenas uma estimativa do retorno caso tudo ocorra conforme o planejado. E as coisas raramente saem conforme o planejado. Mesmo quando o fazem, os dados não estão disponíveis até que seja tarde demais, porque o ROI não fornece feedback durante o desenvolvimento.

Para entender a eficácia do Ágil, buscamos indicadores precoces e medidas chamadas de inovação contábil. Definimos os preditores para um bom valor, e esses preditores vêm muito antes do ROI. Em última análise, os sistemas precisam ser preparados não apenas para quais são os custos, mas para o valor que os usuários recebem.

A discussão inicial de investimento é primeiro sobre a hipótese e depois como provocá-la. E, claro, quanto custa chegar a esse primeiro ponto. Normalmente, essa é uma fração do investimento total, pois as equipes conseguem obter feedback sobre o MVP dentro de um prazo acordado (como algumas semanas ou meses). Depois, ocorre uma discussão sobre continuar investindo ou mudar o rumo para outra solução.

A vantagem é que esse modelo lean é, em grande parte, imune a custos irrecuperáveis. No mundo tradicional, se você já fez um investimento de US$ 5 milhões, ele deve valer a pena. Os stakeholders não gostam de chamá-lo de desperdício ou experimentação. Mecanismos de defesa podem agir, aprovando mais 10 a 20 milhões de dólares para manter o projeto vivo, independentemente do valor gerado.

A empresa ágil não faz isso. Financiamento em ondas, MVPs, ignorar custos irrecuperáveis e tomar decisões baseadas em medidas objetivas de inovação contábil: é assim que a empresa ágil trabalha, uma hipótese de cada vez.

No desenvolvimento ágil, você não espera anos por nada. Se você estiver olhando para um programa importante, os pontos de prova aparecem nas primeiras seis a doze semanas. Após alguns incrementos no programa, as evidências indicarão se deve prosseguir por esse caminho mais longo ou não.

Tanto métricas diretas quanto indiretas podem ser usadas para avaliar o valor dos produtos entregues via Ágil. Indiretamente, é possível medir a velocidade ou a quantidade de stories ou pontos de história que as equipes conseguem concluir em determinado período. Em vez de analisar a estrutura de decomposição do trabalho, avalie como trabalhos similares no passado utilizaram essa capacidade.

É importante primeiro procurar previsibilidade: você entregou o valor com o qual se comprometeu no prazo? Então, você pode fazer ajustes e iniciar conversas para entender por que esse objetivo é muito mais importante que os demais. Também é simples verificar um indicador como o NPS para avaliar os resultados junto aos donos do negócio. Qual é o seu nível de confiança? Você recomendará as equipes avaliadas a outras pessoas?

A transição do Waterfall para o Ágil desafia o tratamento tradicional de CapEx e OpEx. As regras do FASB afirmam que, ao comprovar a viabilidade e obter a aprovação da gestão, é possível capitalizar a mão de obra e depreciá-la durante a vida útil do projeto, afetando a receita.

No modelo Cascata, depois que os requisitos e o design são determinados e aprovados, você pode capitalizar. No Agile, não existe esse portão de estágio. Você constrói a solução aos poucos, mas ainda pode lucrar.

Ainda há muito trabalho envolvido em inovação, pesquisa, infraestrutura e diversas outras atividades que não se relacionam diretamente com a adição de funcionalidades ao sistema. Isso ainda não é capitalizado. Mas, no Ágil, você trabalha com “histórias” que implementam novas funcionalidades. Se você tiver uma história para uma funcionalidade como um novo mecanismo de logon único, pode capitalizar. E você talvez nem precise de planilhas de horas para fazer isso. Mas usar maiúsculas exige uma explicação, uma conversa que precisa acontecer.

Atualmente, a metodologia agilidade em escala impacta os stakeholders responsáveis pela governança e pelos investimentos. Como os departamentos de TI ainda costumam operar com pouca transparência de custos, a percepção sobre o gerenciamento financeiro de TI pode ser: “Aqui está nosso grande centro de custos.” Aqui estão os gastos, e com o tempo obtemos diferentes resultados de negócios, mas sim, temos muita dificuldade em relacioná-los ao investimento. Nós alocamos os custos."

Para mostrar o valor que entregam, as transformações Ágeis exigem que os líderes de TI saibam medir o impacto financeiro e o valor do desenvolvimento contínuo, saibam quando capitalizar o trabalho e como dar visibilidade às iniciativas financiadas. Você precisa de um nível adequado de transparência para saber se está investindo nas coisas certas da maneira certa em TI. É nesse ponto que os líderes de TI aplicam o gerenciamento de negócios de tecnologia (TBM).

O TBM é uma disciplina que melhora os resultados de negócios ao oferecer às organizações uma forma consistente de traduzir os investimentos em tecnologia em valor para o negócio. O TBM define as ferramentas, os processos, os dados e as pessoas necessárias para gerenciar os negócios de tecnologia. Ele se baseia em uma taxonomia e um framework padronizados de TBM que organizam os problemas que líderes de tecnologia e negócios precisam resolver, como o financiamento agilidade em escala.

O TBM adota uma taxonomia e geração de relatórios padronizadas, independentemente do modelo Waterfall ou Ágil. Essas funcionalidades ajudam as empresas a dar visibilidade às métricas financeiras do desenvolvimento de aplicações com base em Ágil e a organizar recursos e resultados conforme as atividades de cada fluxo de valor. Como resultado, há alinhamento com os resultados de negócios e aumento do valor gerado.

Algumas das maiores empresas do mundo têm cerca de 10 mil profissionais de TI, e talvez 5 ou 6 mil deles trabalhem no desenvolvimento de aplicações, o que representa um custo significativo. Isso é um centro de custos ou um centro de investimento? Depende do ponto de vista, mas você precisa saber como acompanhar o desenvolvimento em Ágil se quiser entender como esse dinheiro está sendo usado. Esse processo exige planejamento sobre como iniciar, financiar e medir os produtos Ágil.

Para ser visto como um parceiro que agrega valor nas decisões, você precisa entender tanto o fluxo de valor quanto os gastos com dados e comunicação. Essas questões continuam importantes, mas o foco da conversa está migrando para como competir com novas soluções.

É natural querer que tudo seja previsível, alinhado a um plano e vinculado aos orçamentos futuros, mas isso, somado aos custos, acaba sendo limitante.

Sim, você quer prever o que não pode ser previsto e garantir ROI sobre o incerto, mas isso não é realista. Quando você consegue estar ao lado dos stakeholders da diretoria e apresentar os investimentos e resultados atuais, em vez de se prender a planos de vários anos, você consegue competir.

A boa notícia é que o Ágil substitui toda essa especulação sobre ROI por evidências objetivas em tempo real. Em vez de trabalhar com requisitos para os próximos dois anos, você identifica a primeira parte e a entrega. Agora,

A maior força do Ágil está em transformar uma grande iniciativa em partes menores e começar a gerar valor quase de imediato. A troca é que você descobre mais cedo se está no caminho certo ou não.

O ritmo acelerado da tecnologia exige que mais empresas adotem metodologias Ágil, como o Scaled Agile Framework (SAFe), para responder rapidamente a mudanças nos modelos de negócios, nos mercados e na própria tecnologia. Com isso, elas precisam gerenciar os gastos crescentes com tecnologia e ter mais transparência sobre os custos de TI. As organizações podem usar TBM e SAFe em conjunto para entregar mais valor, com maior transparência, alcançando mais agilidade nos negócios e fortalecendo a parceria com as áreas de negócio.