Escolha uma Página

Por Luciano Osorio – Scrum Master da Zappts

Tradução Livre e Adaptada do texto Original Scrum Papers (páginas 45 a 47), escrito pelo Jeff Sutherland, Ph.D.

Em 2005, Jeff Sutherland (um dos criadores da Metodologia Scrum) trabalhou com Peter Deemer no Yahoo!. Eles quiseram apresentar o Scrum para seus gerentes.

Depois que a gerência decidiu utilizar o Scrum, uma análise da produtividade da implementação dele na IDX Systems (atual GE Healthcare) foi utilizada para calcular um ROI (return on investment – retorno sobre investimento) anual de 1000% em um período de três anos do uso do Scrum na Yahoo!.

Após dois anos da implementação em mais de 100 equipes, a taxa de retorno do Yahoo! para seu investimento em cada treinador Scrum interno foi de US$1,4 com base no treinamento de 10 equipes por ano. Isso equivale a cerca de 1000% de ROI.

Equipes treinadas por um treinador Scrum obtiveram de 3 a 4 vezes os ganhos de produtividade de equipes que não foram treinadas.

O Scrum foi adotado como ferramenta de Transformação Digital tanto no Yahoo! quanto na GE Healthcare.

O Aumento do ROI com o Scrum

A taxa interna de retorno sobre investimento em treinamento de Scrum é bastante alta. Ao fazerem a média de todas as suas equipes, muitas empresas dobraram a taxa de produção de software.

Recentemente, uma empresa de CMMI Nível 5 cortou os custos de projetos de software pela metade. Além disso, houve redução dos defeitos medidos em 40%. Mesmo com o corte de custos, a empresa manteve a conformidade com o nível 5 do CMMI para todos os projetos.

Até mesmo as melhores empresas mostram aumentos radicais de desempenho quando passam a utilizar Scrum e obtêm muito mais do que 1000% de taxa de retorno sobre o investimento em treinamento Scrum.

Este artigo aborda o retorno sobre investimento em treinamento de Scrum para grandes empresas. Essas empresas têm milhares de funcionários e centenas ou milhares de desenvolvedores.

Essas empresas estabeleceram, ao longo de muitos anos, processos pesados, burocráticos e cheios de falhas.

Embora pareça fácil gerar ganhos substanciais apenas eliminando as fontes mais óbvias de ineficiência, introduzir um processo radicalmente novo por toda a organização pode ser algo lento e doloroso.

O Scrum tem um processo contínuo e sistemático de melhoria de qualidade. Esse processo identifica e prioriza os impedimentos das operações no progresso da empresa.

IDX Systems (agora GE Healthcare): escalando o Scrum pela primeira vez

Durante o verão de 1996, a IDX Systems contratou Jeff Sutherland como vice-presidente de engenharia e desenvolvimento de produtos. A IDX tinha mais de 4 mil clientes e era uma das maiores empresas de software de saúde dos EUA. Eram centenas de desenvolvedores trabalhando em dezenas de produtos.

Aqui estava uma oportunidade para estender o Scrum ao desenvolvimento em grande escala.

A abordagem na IDX foi organizar todo o grupo de desenvolvimento em um conjunto interligado de Scrums.

Embora essa tenha sido a primeira grande equipe de desenvolvimento a tentar essa abordagem, a estratégia já foi executada muitas vezes e documentada por Ken Schwaber em “Scrum in the Enterprise”.

Cada parte da organização era baseada em equipes, incluindo a equipe de gestão. Nela haviam dois vice-presidentes, um arquiteto sênior e vários diretores. Scrums da linha de frente reuniam-se diariamente.

Um Scrum de Scrums, que incluía os líderes de cada equipe Scrum em uma linha de produtos, reunia-se semanalmente. O Scrum de gerenciamento se reunia mensalmente.

O principal aprendizado na IDX foi que o Scrum se adapta a qualquer tamanho.

Com dezenas de equipes em operação, o problema mais difícil era garantir a qualidade do processo Scrum em cada equipe. Toda a organização tinha que aprenderScrum ao mesmo tempo.

A IDX era grande o suficiente para trazer especialistas em produtividade para monitorar o rendimento de cada projeto.

Métricas de Escalabilidade

Enquanto a maioria das equipes conseguiu dobrar o número de Function Points (Pontos de Função) por mês com relação à média da indústria, algumas equipes entraram em um estado hiperprodutivo. Elas produziam quatro ou cinco vezes mais funcionalidades entregáveis do que a média da indústria. Essas equipes se tornaram estrelas na organização e exemplos a serem seguidos.

Uma das equipes mais produtivas da IDX foi a equipe do Web Framework. Ela criou uma infraestrutura de front end web para todos os produtos. A infraestrutura foi projetada para hospedar todos os aplicativos IDX, além de interoperar perfeitamente com aplicativos do usuário final ou de terceiros.

O Web Framework foi criado por uma equipe distribuída, com desenvolvedores em Boston, Seattle e Vermont, que se reuniam diariamente por videochamada.

A transparência geográfica deste modelo produziu equipes distribuídas de performance tão alta quanto a das equipes co-localizadas. Isso tornou-se a característica mais marcante de Scrums hiperprodutivos distribuídos/terceirizados das empresas Xebia na Holanda e Índia, e Exigen Services nos Estados Unidos e Rússia.

A qualidade do software de muitas das equipes de Scrum hiperprodutivas pode ser extraordinariamente alta.

O IDX Web Framework foi implementado pela primeira vez em 1997. Em 2007, foi selecionado como a principal tecnologia webpara os sistemas da GE Healthcare.

No entanto, muito poucas equipes de software IDX alcançaram o estado hiperprodutivo.

Em média, com base na análise de Function Points feita pela empresa de Capers Jones, a Software Productivity Research, a IDX só alcançou uma média de ganhos produtivos de 240%. O principal motivo disso foi a queda de produtividade causada pelo número excessivo de membros nas equipes Scrum, com até 15 pessoas.

Hoje é senso comum que essas equipes grandes causam perda significativa de produtividade e impossibilitam a escalabilidade linear.

A escalabilidade linear é uma das principais características das implementações Scrum bem executadas.

Resumo dos ganhos de produtividade na IDX

O orçamento da organização de desenvolvimento da IDX era de quase US$ 50 milhões por ano. Isso era suficiente para uma análise detalhada da produtividade basal antes do Scrum e dos ganhos de produtividade gerados por ele.

Uma empresa de consultoria independente foi contratada para fazer a análise de Function Points de todos os softwares IDX. Essa empresa chamava-se Software Productivity Research (SPR). Jeff Sutherland havia trabalhado com Capers Jones, o fundador da SPR, durante a criação do Scrum e queria comparar as metas de produtividade projetadas do Scrum com o seu desempenho real.

Alguns dos produtos IDX tinham mais de 12 mil Function Points. Isso era o equivalente a mais de um milhão de linhas de código Java ou C#. Os produtos menores tinham por volta de 5 mil a 6 mil Function Points.

Os aplicativos eram produtos financeiros e clínicos para operar hospitais e grupos médicos independentes em milhares de sites.

As plataformas de implementação variavam de Mumps a Cobol e Java, até as ferramentas e linguagens da Microsoft mais recentes disponíveis.

Function Points e Story Points

Function Points foram escolhidos como uma medida padrão da indústria, independente da linguagem e ambiente de desenvolvimento de software. Isso foi feito para garantir uma comparação realista da produtividade entre as tecnologias e equipes de desenvolvimento. Também havia garantia da comparabilidade com dados externos à indústria.

Especialistas externos foram contratados para calcular Function Points, a fim de fornecer dados qualificados para pesquisa.

Via de regra, os Function Points não são facilmente calculados pela equipe de desenvolvimento e não são recomendados como uma estratégia operacional.

Os Story Points (Pontos de História) surgiram como a melhor prática da indústria para medir a velocidade da equipe de Desenvolvimento Ágil. Eles são facilmente calculados e úteis para o planejamento do lançamento de um software.

Contudo, eles não são comparáveis entre equipes ou entre empresas. Portanto, não eram adequados para dados de pesquisa sobre a primeira implementação do Scrum em uma grande empresa.

Em cada lançamento de cada produto, o número de Function Points foi recalculado para refletir os novos recursos pelas consultas do Software Productivity Research.

O aumento nos Function Points foi dividido em meses por pessoa para as equipes de desenvolvimento sobrecarregadas. Isso inclui equipe de design, desenvolvimento, teste, administrativa e de gerenciamento.

A velocidade inicial de todas as equipes de desenvolvimento foi a média da indústria, em 2 a 3 Function Points por mês da equipe.

Algumas equipes aceleraram até alcançarem a hiperprodutividade usando o Scrum, atingindo de 5 a 10 vezes o desempenho médio da indústria. Essas equipes eram cerca de 10% da organização e alcançaram um aumento médio de produtividade de 666%.

Um pequeno número de equipes (menos de 5%) apresentou falhas por motivos pessoais ou tecnológicos.

Os Ganhos de cada Equipe

Ocasionalmente, uma equipe não era capaz de trabalhar em conjunto de forma eficaz e acabava sendo reorganizada ou desfeita, geralmente durante o primeiro Sprint.

Menos frequentemente, uma equipe de alto desempenho tinha assumido um risco calculado em novas tecnologias (sempre aprovadas pela gerência) e a falha técnica de algumas Sprints era antecipada (até mesmo incentivada) para ganhar uma liderança tecnológica no mercado.

Não houve falhas em grandes projetos, apenas falhas na entrega de software em Sprints isolados ou em uma curta série de Sprints. No caso de falhas da equipe, as equipes sempre foram refeitas. No caso de falhas tecnológicas, os esforços foram redobrados nos Sprints seguintes para superar os desafios de pesquisa e desenvolvimento.

Os 85% restantes das equipes atingiram uma velocidade média de 5 a 6 Function Points por mês de equipe, tendo um ganho médio de 100%. O ganho líquido de produtividade de todas as equipes combinadas foi de 240%.

Isso foi visto como uma falha em alcançar um desempenho de nível comparável ao da Toyota. Entretanto, foi um bom começo para a implementação do Scrum em toda a empresa. Recentemente, as equipes de desenvolvimento de tamanho comparável alcançaram consistentemente mais de 10 Vezes a Velocidade Média da Indústria.

Todas as Equipes de uma Organização Inteira Foram Hiperprodutivas, alcançando o objetivo original do Scrum.

Conclusão

É importante ressaltar que esses ganhos de produtividade foram alcançados em um ritmo sustentável. Houve maior retenção de funcionários e maior capacidade de contratar as melhores pessoas. Isso é devido ao ambiente de trabalho de alta qualidade fornecido para desenvolvedores pelo uso do Scrum.

As equipes hiperprodutivas sempre foram as equipes mais animadas, que amavam seus empregos e trabalhavam com grande sinergia, como uma equipe esportiva profissional.

A hiperprodutividade não é alcançada trabalhando mais arduamente, mas sim trabalhando com mais eficácia através de comunicação intensa, apoio mútuo e uma habilidade “sem esforço” que faz com que as coisas difíceis pareçam fáceis.

Pense em Michael Jordan subindo para um “shot” de basquete. A equipe trabalhou para que o jogo fosse propício para o “shot”, o que muitas vezes faz com que ele pareça tão suave e fácil que gera alegria tanto nos jogadores quanto nos espectadores.

shares