Em 2015, a divisão de Software e Informática da Agilent estava com problemas. Em meio ao grande lançamento de um produto novo, a equipe perderia a data de lançamento. Não seria a primeira vez. A divisão cumpria apenas 20% das datas de lançamento a tempo.
As datas de lançamento perdidas criaram uma pressão tremenda das equipes de software. "Quando as equipes estão sob pressão, elas tomam decisões ruins", diz John Sadler, VP e GG da divisão de Software e Informática da Agilent. as equipes estão sob pressão, elas tomam decisões ruins", diz John Sadler, VP e GM da divisão de Software e Informática da Agilent. "Elas sacrificam a qualidade e acabam pagando por isso no back-end. No geral, a equipe estava meio desmoralizada e tinha dificuldades de entregar qualquer coisa a tempo".
Parte do desafio era que a divisão de Software e Informática da Agilent incluía 150 funcionários em dois continentes, que colaboravam com contratados em um terceiro continente. Era uma divisão extensa de profissionais de engenharia, marketing, garantia de qualidade, suporte técnico e vendas. A empresa precisava estabelecer novas práticas de equipe para ajudá-la a entregar valor com mais rapidez, com maior qualidade e previsibilidade e responder melhor à alteração. Em resumo, eles precisavam de uma transformação ágil.
Embarcando em uma transformação ágil
Em 2015, a Agilent mapeou uma transformação ágil com os objetivos a seguir:
- Foco na previsibilidade
- Desenvolver um ritmo de lançamentos confiável
- Criar um ciclo de entrega reproduzível
- Promover uma melhoria contínua
A abordagem ágil coloca a qualidade em primeiro lugar, um ritmo reproduzível em segundo e o escopo em terceiro. "Quando as equipes não seguem essas prioridades, elas costumam colocar o escopo em primeiro lugar, o cronograma é imposto na forma de um prazo e a qualidade fica escassa", diz Sadler.
A Agilent queria estabelecer processos ágeis que incluíssem prioridades no desenvolvimento de software dela. Estabelecer uma melhoria contínua como valor principal implicou uma mudança cultural que criou o contexto para a transformação. Colocar a qualidade em primeiro lugar significa a satisfação de clientes internos e externos. A Agilent estava disposta a sacrificar o escopo para atender às expectativas dos clientes em campo.
A segunda prioridade era que a divisão criasse um ciclo previsível de lançamentos que pudesse ser ajustado com o tempo. Um ciclo de desenvolvimento mais curto e confiável permitiria que a equipe evitasse problemas e mitigasse riscos com antecipação para dar um tempo de resposta adequado.
Transformação ágil: passo a passo
No início de agosto de 2015, a Agilent fez parceria com a cPrime, uma empresa de consultoria com experiência em ajudar as empresas por meio de transformações ágeis e, mais tarde, com a TCGen, uma líder em consultoria de desenvolvimento de produtos.
Implementar a ferramenta ágil de gerenciamento de produtos, o Jira, foi a primeira etapa. O Jira agora oferece um sistema de registro para todo o trabalho de desenvolvimento da Agilent, entre equipes globais distribuídas. Ele cria uma transparência com uma única versão da verdade, que revela funções da agenda, quando eles são esperados e o que foi alcançado entre as equipes.
Adaptado com permissão da cPrime, Inc.
O treinamento ágil foi a próxima prioridade, com objetivo de ensinar princípios e conceitos ágeis e estabelecer uma terminologia em comum. A cPrime desenvolveu receitas para um modelo de Governança ágil na empresa (RAGE) que destaca as principais cerimônias, incluindo reuniões de planejamento de lançamento, reuniões Scrum de Scrums da equipe, reuniões Scrum de Scrums do proprietário do produto, reuniões de revisão de tarefas de lançamento, revisão de lançamento e reuniões retrospectivas de lançamento.
A Agilent também estabeleceu funções de proprietário do produto e funções de gerente de programa da área e mediu o progresso com gráficos burnup. A Agilent também adotou técnicas leves de tomada de decisões, executou cerimônias, usou artefatos ágeis de scrum e adotou outras práticas ágeis.
Agilidade em ação
Em novembro de 2015, a divisão de Software e Informática da Agilent realizou o Sprint Zero, uma sessão de planejamento ágil de duas semanas com 14 equipes treinadas. Foi desenvolvido um plano de lançamento de produto com duração de oito meses para o sistema de dados de cromatografia OpenLAB.
As atividades do Sprint Zero incluíam três categorias:
- Ensinar as equipes sobre os objetivos, motivadores e requisitos técnicos e de negócios de alto nível para o OpenLAB por meio de apresentações e pôsteres.
- Usar as técnicas recém-aprendidas para desenvolver requisitos e estimar histórias, epics e defeitos.
- Apresentar histórias, epics e defeitos no quadro de planejamento de lançamento e marcar todas as dependências entre equipes.
A Agilent logo descobriu que as melhorias ágeis dela se estendiam além do projeto piloto. Um dos primeiros indicadores de sucesso foi interno. "Como tivemos que fazer parceria com outras divisões da Agilent, fazer o que dissemos que iríamos fazer foi imensamente importante", diz Sadler.
A Agilent também viu melhorias externas. O feedback dos clientes se tornou fundamental para aumentar a responsividade das equipes da Agilent às alterações do mercado. Ao incluir os clientes desde o início, no processo de desenvolvimento, a Agilent aumentou a qualidade do software enquanto reduziu o risco de integração e mercado.
Um dos insights da Agilent foi incluir na definição de pronto que as histórias de upgrade deveriam ser incluídas em todos os epics ágeis. Babita Jain, diretora de qualidade de software e Stefan Weiss, gerente de integração de software da Agilent, lideraram a implementação da transformação e ajudaram as equipes a entenderem o escopo do projeto. "A gente não considerava o epic pronto a menos que ele incluísse os upgrades", diz Jain.
A transformação ágil não melhorou apenas a qualidade, mas a confiabilidade. Em 2016, o sistema de dados de cromatografia OpenLAB foi entregue no prazo. Desde a transformação ágil, a Agilent tem fornecido software com continuidade e os defeitos relatados em campo têm diminuído.
Medição do sucesso
A Agilent define e mede o sucesso da iniciativa ágil com "baixas taxas de falha em campo e alta fidelidade dos clientes", diz Sadler. A retenção de clientes também é fundamental. No mercado maduro e competitivo do setor de ciências da vida, o atrito com o cliente é um perigo. A capacidade de vender um sistema novo para clientes antigos é essencial.
A seguir estão as quatro métricas essenciais possibilitadas pelo modelo de capacidade baseado em Jira da Agilent:
Gráficos de burndown/burnup
A Agilent media o trabalho em horas de engenharia, dias pessoais ou pontos da história. Agora todos usam gráficos burnup para rastrear o trabalho concluído e a quantidade total de trabalho. Os gráficos burndown exibem quanto trabalho ainda resta.
Porcentagem da capacidade entregue ao mercado (conteúdo)
A possibilidade de modelar e rastrear a capacidade tem um papel essencial em como a Agilent mede o sucesso. O Jira permitiu que a Agilent criasse um modelo de capacidade especificado. “Este modelo nos permitiu, durante a fase de planejamento, dizer ao marketing com quantos pontos da história eles tinham que trabalhar para um lançamento. O marketing pode classificar o backlog para se adequar a essa capacidade”, diz Sadler.
Contagem e tempo médio para entregar correções
O modelo de capacidade ofereceu uma visão mais granular que permitiu à Agilent ver a capacidade gasta em corrigir defeitos graves ou críticos relatados em campo versus os. defeitos que a equipe de qualidade descobriu e relatou.
Porcentagem de tempo gasto corrigindo defeitos descobertos por testes manuais
O modelo de capacidade ajuda a Agilent a medir o tempo gasto criando funções que os clientes valorizam versus o tempo gasto com a manutenção ou suporte de produtos existentes.
Em pouco mais de três anos, a divisão mais do que dobrou a porcentagem da capacidade focada no trabalho de valor agregado, aumento-a de 30% para 65%. À medida que a qualidade do software melhorou, impulsionada pela nova abordagem ágil, também ocorreram menos defeitos para reparar mais tarde.
Um ano após começar o processo de transformação ágil, os membros da equipe da Agilent descreveram diversos cenários de "antes" e "depois":
 | Antes: o desempenho era medido em horas de engenharia, dias pessoais ou pontos da história. |
|---|---|
 | Antes: equipes com diferentes níveis de treinamento ágil tinham definições diferentes de epics, histórias e subtarefas. |
 | Antes: mestres de scrum gravavam código, lideravam reuniões de equipe e ponderavam as prioridades de funções. |
 | Antes: funções com bugs poderiam ser aprovados, levando defeitos até as fases seguintes de desenvolvimento. |
 | Antes: os problemas ocorriam com frequência na última hora, causando pânico e atrasos substanciais. |
 | Antes: não havia um instrumento para medir a capacidade de trabalho de uma equipe. |
O futuro ágil da Agilent
Como qualquer cultura que valoriza a melhoria contínua, a transformação ágil da Agilent não está completa. As próximas etapas incluem continuar a reduzir o tempo de ciclo e aprimorar a capacidade de obter insights antecipados a partir de feedback do mercado, alguns elementos principais das métricas de DevOps.
A Agilent contribui para a redução drástica do tempo de ciclo, dividindo lançamentos anuais em dois ciclos de seis meses — mesmo que a empresa comercialize os lançamentos uma vez por ano. A empresa planeja reduzir o tempo de ciclo pela metade de novo, mudando para um ritmo trimestral.
Envolver os clientes no início e com frequência no processo de desenvolvimento também é assunto de melhoria contínua. Sadler disse que o grupo dele descobriu que há menos mediação entre os interesses conflitantes nas discussões sobre o escopo do produto quando há evidências claras de feedback do mercado. Manter a qualidade e a usabilidade para os clientes em campo é uma prioridade contínua, e o envolvimento contínuo com os usuários ajuda a manter as prioridades da empresa: qualidade em primeiro lugar, depois ritmo de lançamentos e escopo.
Lições aprendidas
Sadler atribui o sucesso à equipe dele, incluindo os líderes Jain e Weiss, que adotaram o desenvolvimento ágil como forma de impulsionar melhoria rápida e contínua. As ferramentas certas, como o Jira e o Confluence, permitiram que a equipe consolidasse o trabalho em um só lugar e medissem o progresso.
A Agilent descobriu que uma transformação ágil requer um patrocinador que supervisione a pesquisa e o desenvolvimento, o inbound marketing e a qualidade. "Se você não conseguir transformar os três, não vai ter sucesso", diz Sadler. "Você não consegue fazer uma transformação ágil apenas por meio de P&D". O que é mais importante não é o trabalho feito dentro das funções, mas a forma com que elas trabalham juntas.
A Agilent também descobriu que é essencial abandonar a suposição de que um entendimento perfeito das necessidades do cliente está dentro da empresa. Uma abordagem ágil é lançar os produtos de acordo com um ritmo confiável e, em seguida, receber feedback do cliente. Essa abordagem requer a atitude de que as datas de lançamento são sagradas e quando chega o prazo, a equipe envia o produto como ele está.
Por último, aconselha Sadler, a estrutura ágil torna os problemas visíveis. Por exemplo, a agilidade expõe falhas na capacidade. Ela revela as partes do processo sem valor agregado que causam atrasos e revela erros de qualidade. Alterar uma abordagem de cascata para uma abordagem ágil não requer apenas alterações em como as equipes trabalham, mas é, também, uma alteração cultural. A agilidade impulsiona uma cultura de melhoria contínua que é muito contagiante.
