Agile não é mais o garoto novo no bloco. Mas para a maioria das empresas, uma transformação ágil ainda parece um salto de fé. Essas transformações exigem que as empresas redesenhem as estruturas organizacionais, alterem os modelos operacionais, criem novos recursos e alterem maneiras de trabalhar estabelecidas há muito tempo. Os evangelistas falam de grandes organizações que liberam dezenas para centenas de milhões de dólares em valor. Essas reivindicações podem ser apoiadas com números reais?
And the expectations are sky-high—agile promises to double speed to market, boost customer satisfaction and quality, increase efficiency, and reduce costs. Evangelists speak of large organizations unlocking tens to hundreds of millions of dollars in value. Can these claims be backed up with real numbers?
As reivindicações sobre Agile podem ser apoiadas com números reais?
A resposta é sim. De um modo geral, existem duas maneiras de medir o Impacto do Agile : Meça como as equipes ágeis agregam valor e melhoram com o tempo ou compare o valor que as equipes ágeis criam com o valor do trabalho em cascata anterior. Quando as transformações ágeis estão em andamento, incentivamos fortemente a abordagem anterior, uma vez que é prospectiva e leva a insights acionáveis. No entanto, as empresas que estão apenas começando em uma jornada ágil ou ainda não têm uma ampla adesão da equipe de liderança executiva geralmente se vêem desafiadas a provar que trabalhos ágeis em sua organização. Nesse caso, a última abordagem é útil. As métricas usadas para rastrear o sucesso em um contexto em cascata raramente se traduzem em um ambiente ágil, e algumas realmente incentivam comportamentos que contrariam valores e princípios ágeis. Aqui estão apenas algumas abordagens a serem evitadas:
Here we touch on some of the ways that measuring the impact of agile can go wrong, highlight an approach that has worked well, illustrate how companies have used this approach—and showcase the astonishing results they have seen.
What Doesn’t Work
Trying to measure the results of an agile transformation can lead companies astray in many ways. Metrics used to track success in a waterfall context rarely translate to an agile environment, and some actually encourage behaviors that run counter to agile values and principles. Here are just a few approaches to avoid:
- A abordagem da linha de montagem. O Agile é incentivar a experimentação, não refletir todas as eficiência. Focar na produtividade da unidade ou nas linhas de código por hora do desenvolvedor, por exemplo, é um erro. No Agile, procuramos medir os resultados, não apenas a produção - e as equipes podem girar quando reconhecem o trabalho que não contribui para os resultados e os principais resultados. If you try to measure the impact of agile in the same way an automaker calculates productivity on an assembly line, you’ve already lost. Agile is about encouraging experimentation, not eking out every ounce of efficiency. Focusing on unit productivity or lines of code per developer hour, for example, is a mistake. In agile, we seek to measure outcomes, not just output—and teams can pivot when they recognize work that does not contribute to outcomes and key results.
If you try to measure the impact of agile in the same way an automaker calculates productivity on an assembly line, you’ve already lost.
- A abordagem hipotética. Algumas empresas medem projetos ágeis contra planos criados anteriormente. O problema é que esses planos são hipotéticos e geralmente mudam durante a implementação, como evidenciado pela enxurrada usual de solicitações e revisões de mudança. Para uma comparação justa, o que é necessário é uma linha de base de projetos reais, não planos hipotéticos. Sem uma única fonte de verdade, a confiança entre equipes e líderes pode quebrar. Algumas medidas podem ser agregadas para ajudar a gerenciamento a obter uma visão de grande porte, mas os dados devem ser puramente enrolados dos números reais, não reinterpretados.
- The Sanitized Approach. If broad metrics are summarized or translated for consumption by leaders, the real story can be diluted or obscured. Without a single source of truth, trust between teams and leaders can break down. Some measures can be aggregated to help management get a big-picture view, but data should be purely rolled up from the actual numbers, not re-interpreted.
- A abordagem “Uma métrica que importa”. Por exemplo, as equipes que rastreiam apenas as pontuações de lealdade do cliente podem ignorar custos, sustentabilidade ou outros fatores -chave. As equipes ágeis eficazes também precisam dessas medidas para melhorar continuamente. Por exemplo, se uma equipe estiver automatizando um processo de negócios, esperamos que seja responsabilizada por erros reduzidos, aumento da taxa de transferência ou menor custo de execução - artigos que exigem que o processo seja implementado, não apenas entregue. tempo) e engajamento dos membros da equipe (através de verificações regulares de pulso). Focusing on a small number of metrics can be helpful, but one is seldom enough to maintain proper balance in priorities. For example, teams that solely track customer loyalty scores might ignore cost, sustainability, or other key factors.
What Does Work
Effective agile organizations establish a balanced set of measures to track the business value that teams create and the health and welfare of those teams. Effective agile teams also need these measures in order to continuously improve.
Business value metrics are typically specific to a team’s work. For example, if a team is automating a business process, we’d expect it to be held accountable for reduced errors, increased throughput, or lower cost of execution—outcomes that require the process to be implemented, not just delivered.
The health and welfare of a team is typically shown by metrics that track quality (escaped defects), predictability (meeting sprint commitments), frequency of delivery (reduced lead or cycle time), and engagement of team members (through regular pulse checks).
Independentemente das métricas, é essencial estabelecer linhas de base significativas. Se você não pode determinar por onde começou, não pode medir o quão longe chegou. Muitas organizações acompanham o progresso das equipes apenas quando começaram a correr. Depois de trabalhar juntos para alguns sprints, a maioria das equipes começará a mostrar melhorias mensuráveis na entrega de valor, qualidade, velocidade e tempo de ciclo, todos os principais indicadores de que o modelo ágil está funcionando.
Independentemente das métricas, é essencial estabelecer linhas de base significativas. Se você não pode determinar por onde começou, não pode medir o quão longe chegou.
Para provar os méritos do Agile em relação à maneira tradicional de trabalhar da empresa, geralmente é necessário realizar um processo analítico desafiador para estabelecer a linha de base histórica. Isso requer capturar os custos e o tempo dos projetos de cascata passados. Mas você não pode simplesmente baixar dados em todos os projetos de cascata anterior e usá -los como uma linha de base para comparação com projetos ágeis. Um despejo de dados simples produzirá muito pouco valor porque as comparações resultantes não serão maçãs para as maçãs. Veja como funciona. Usando uma abordagem quantitativa, esta lista foi reduzida a um número muito menor de projetos - em torno de 100 - que eram semelhantes em tamanho, escopo, custo e cronograma dos projetos ágeis em questão. Isso não é diferente dos corretores de imóveis do processo ao procurar "comps" em uma cidade, cidade ou bairro específicas, enquanto se preparam para colocar uma casa no mercado. Por exemplo, uma equipe pode ter um desempenho ruim porque o líder ficou doente e ficou fora por várias semanas durante o tempo de crocância. Ou uma equipe pode ter um desempenho heroicamente porque funcionou horas extras durante um feriado. Quando o processo de filtragem manual foi concluído, 30 a 40 projetos foram deixados como base para comparação. Da mesma forma, um avaliador imobiliário eliminará casas que oferecem uma base injusta para comparação, como as localizadas próximas a linhas de energia de alta tensão ou caíram em grave desconforto. No entanto, para obter uma comparação confiável de custos, foram necessários ajustes adicionais para explicar as variações entre os projetos. O cliente considerou a complexidade do projeto e a necessidade de coordenação interna, assim como um avaliador imobiliário chega a um valor de propriedade, considerando a metragem quadrada, o número de quartos ou o tamanho do lote. O cliente identificou e quantificou os principais fatores de diferença através da regressão multivariada, revisou os resultados com especialistas para garantir que os achados fossem plausíveis e ajustou as comparações na linha de base de acordo. Isso permitiu uma comparação de maçãs-maçãs do custo do projeto e permitiu ao cliente quantificar o aumento da produtividade alcançado através de maneiras ágeis de trabalho.
For a meaningful comparison of past waterfall projects and agile projects, companies need an approach akin to the appraisal method for valuing real estate. Here’s how it works.
One of our clients had data on 2,000 prior waterfall projects, but not all the data points were comparable to the data from the agile projects the company wanted to assess. Using a quantitative approach, this list was winnowed down to a much smaller number of projects—around 100—that were similar in size, scope, cost, and timeline to the agile projects in question. This is not unlike the process realtors go through when searching for “comps” in a specific city, town, or neighborhood as they prepare to put a house on the market.
The next step was to enlist experts within the company to manually review all 100 projects and eliminate outliers and projects with special circumstances; for example, a team might have performed poorly because the leader became ill and was out for several weeks during crunch time. Or a team might have performed heroically because it worked overtime during a holiday break. When the manual filtering process was complete, 30 to 40 projects were left as a basis for comparison. In the same way, a real estate appraiser will eliminate houses that offer an unfair basis for comparison, such as those that are located near high-voltage power lines or have fallen into serious disrepair.
Metrics such as quality, speed, and employee engagement from this refined baseline and from the agile projects could then be compared directly. However, to achieve a reliable cost comparison, further adjustments were required to account for the variances between the projects. The client factored in project complexity and the need for internal coordination, much as a real estate appraiser arrives at a property value by factoring in square footage, number of bedrooms, or lot size. The client identified and quantified key drivers of difference through multivariate regression, reviewed the results with experts to ensure that the findings were plausible, and adjusted the comparisons in the baseline accordingly. This allowed for an apples-to-apples comparison of project cost and enabled the client to quantify the productivity increase achieved through agile ways of working.
Como as empresas estão medindo o sucesso ágil
Companies using this filtering method have gained valuable—and quantifiable—insights into the impact of their agile transformation. Here are just a few examples.
A 55% Acceleration in Time to Market. A top-three North American financial institution used the filtering method to quantify the speed of execution of agile projects and waterfall projects. The company first identified three phases that apply to both agile and waterfall projects—up-front preparation until start of development, development and testing, and the final integration testing and preparation for release—and then compared each phase in the two project types. The agile projects achieved a 55% reduction in time to market, driven largely by decreases in the up-front preparation time (of 65%) and the development cycle time (60%). Final integration testing and preparation for release saw a 20% reduction because there were no late-stage issues and changes.
Threefold to Fourfold Increase in Speed to Revenue. A large global wealth and asset management company dramatically accelerated time to value when launching an innovative product in the market. In the past, product launches of similar size and complexity using traditional ways of working had taken 15 to 18 months. Using agile, the company was able to go from product idea to national launch in just five months. As one top executive said, “This speed to customer value is unheard of in our organization and in the industry. We beat our top competitors—and just imagine the P&L acceleration.”
O custo diminui de 25%. Primeiro, a empresa analisou os fatores de custos do projeto e descobriu que o principal motorista era o número de departamentos envolvidos - ou seja, quantos grupos tinham que trabalhar juntos para alcançar o objetivo. Quando comparados aos projetos de cascata anteriores da empresa, os pilotos ágeis, que foram organizados em torno de equipes colaborativas capacitadas para tomar decisões independentes e se mover rapidamente, levaram a economia de custos, mas a empresa queria uma visão mais finamente granulada. Depois de curar os dados do projeto em cascata, alinhar e refinar as dimensões comparáveis e o ajuste da complexidade, a empresa descobriu que os projetos ágeis estavam reduzindo os custos totais do projeto em até 25%. A global financial services company used this method to quantify how agile affects efficiency as measured by project costs. First, the company analyzed drivers of project costs and found that the main driver was the number of departments involved—that is, how many groups had to work together to achieve the objective. When compared with the company’s past waterfall projects, the agile pilots, which were organized around collaborative teams empowered to make independent decisions and move quickly, had led to cost savings, but the company wanted a more finely grained view. After curating waterfall project data, aligning and refining comparable dimensions, and adjusting for complexity, the company found that agile projects were lowering total project costs by as much as 25%.
Um aumento de 50% na qualidade. Usando uma linha de base de projetos comparáveis, a empresa descobriu que os produtos criados com a cachoeira tinham 65 defeitos de gravidade 1 ou superior após a liberação, mas os produtos criados com Agile tinham apenas 34 anos. A empresa também descobriu que 15% dos defeitos em projetos em cascata eram os requisitos de um cenário e em comparação com apenas 1% a 2% para os projetos ágeis. Deslizamentos e excedentes orçamentários de equipes de cascata e ágil. “O desbotamento médio de programação foi de 67% menos para equipes ágeis do que para as equipes em cascata - apenas mais de três meses em comparação com quase nove - e as equipes ágils entregues consistentemente no orçamento ou com o orçamento. Em comparação, as equipes em cascata tiveram um excesso de orçamento médio de 45%. As equipes, perguntando se os membros da equipe estavam "empolgados com o trabalho" que estavam fazendo, classificados em uma escala de "concordar fortemente" em "discordar fortemente". Antes da transformação ágil, cerca de 60% "acordou fortemente", mas as pontuações aumentaram para mais de 90% após 14 semanas de trabalho de maneira ágil. Para apreciar os benefícios dos níveis de engajamento, estabilizando -se em aproximadamente 90%. A Agile está cumprindo sua promessa - e pavimentar o caminho para escalá -la em toda a organização. Matthew Aliber A major North American financial institution used this method to analyze agile’s effect on the defect rate. Using a baseline of comparable projects, the company discovered that products created with waterfall had 65 defects of severity 1 or higher after release, but products created with agile had just 34. The company also found that 15% of defects in waterfall projects were the result of misunderstood requirements, compared with just 1% to 2% for agile projects.
Improved Predictability. A global media and entertainment company looked at the schedule slippage and budget overruns of both waterfall and agile teams. “The average schedule slippage was 67% less for agile teams than for waterfall teams—just over three months compared with almost nine—and the agile teams consistently delivered at or under budget. By comparison, waterfall teams had an average budget overrun of 45%.
A 30% Boost in Employee Engagement. A major bank measured the improvement in employee engagement by anonymously polling teams, asking whether team members were “excited about the work” they were doing, rated on a scale from “strongly agree” to “strongly disagree.” Before the agile transformation, around 60% “strongly agreed,” but the scores increased to more than 90% after 14 weeks of working in an agile fashion. Interestingly, the results for agile projects fluctuated during that period. Scores were sky-high in the first four weeks but then dipped for several weeks to less than 50% (in other words, below the initial readings) as employees came to grips with the challenges inherent in new ways of working. Once employees got their feet beneath them and began to appreciate the benefits of agile, engagement levels shot back up, stabilizing at approximately 90%.
As more and more companies embark on agile transformations, boards, shareholders, and regulators will demand more transparency from their executive teams. They will want to know the return on investment for the transformations and to understand how ROI is measured. By adopting the filtering approach, companies can establish quantifiable proof points that illustrate the ways agile is fulfilling its promise—and pave the way to scale it across the organization.
