Escolha uma Página

Desvendando FINOPS

Descubra como otimizar o orçamento de TI reduzindo custos da Nuvem

Por Luciano Osorio – Scrum Master da Zappts

FinOps é um modelo operacional para a Nuvem que possibilita a retomada do controle financeiro sobre a infraestrutura de TI, para que os departamentos operacional e financeiro trabalhem juntos e com os mesmos objetivos.

FINOPS – Vantagens e Desafios da Nuvem

Vamos começar falando das vantagens da Nuvem.

Ela traz muita flexibilidade, é extremamente elástica quando é preciso aumentar ou diminuir a sua utilização.

Na Nuvem, é possível fazer diversos tipos de processamento e atividades diferentes dentro de um único ambiente, com a facilidade de um clique para contratar cada um desses serviços.

No entanto, a Nuvem traz algumas situações que precisam ser observadas e endereçadas, e eu vou explicar melhor sobre esses desafios a partir de agora.

Desafios da Nuvem

Tradicionalmente, o departamento de TI era responsável por definir quais os servidores seriam comprados, o armazenamento disponível e o poder de processo estaria disponível. Tudo isso era definido com antecedência dentro do planejamento financeiro anual da empresa.

Porém, com o advento da Nuvem algumas coisas mudaram e o programador passou a ter o poder de decisão sobre os recursos que precisa utilizar para poder fazer a inovação na qual está trabalhando.

Com isso, surge um problema: o departamento financeiro deixa de ter visão do que está sendo gasto com TI e isso pode trazer um problema de controle muito grande para a empresa.

A falta de controle de custos com TI pode gerar rombos enormes nos orçamentos, quando, por exemplo, a empresa possui uma aplicação que tem recursos e clientes, mas que custa muito mais caro se comparada ao retorno financeiro obtido com ela. 

Como evitar essa falta de controle?

Para evitar essa falta de controle de custos, um consórcio formado por grandes utilizadores da Nuvem propôs um modelo operacional que, quando aplicado, possibilita a retomada do controle financeiro sobre a infraestrutura estabelecendo uma linguagem comum entre os departamentos financeiro e de TI.

Assim foi criado o FinOps com o objetivo de:

  • Estabelecer o controle do que está sendo utilizado com recursos de TI;
  • Revelar quanto dinheiro está sendo gasto em infraestrutura;
  • Indicar quais departamentos e aplicações mais consomem os recursos e o orçamento de TI.

A partir da leitura desses indicadores, a empresa consegue provisionar adequadamente o budget para fazer as compras necessárias e limitar a infraestrutura daqueles pedaços da empresa que usam pouco a Nuvem.

A ideia do FinOps é simples: juntar as áreas de tecnologia e finanças para que ambas falem a mesma língua e estejam alinhadas nos mesmos objetivos.

As fases do FINOPS

O FinOps foi estruturado em três fases.

A primeira fase é a fase de informação, que vai dar visibilidade de quais são áreas da empresas que estão gastando mais, como esse dinheiro está sendo investido, quais recursos são de fato utilizados e quais podem ser trocados.

A área de informação vai gerar essa visibilidade para a área de negócios, o que possibilita uma tomada de decisão informada a respeito do que está acontecendo na Nuvem.

A segunda fase é a de otimização. 

Com base nas informações que foram coletadas, chega o momento de propor maneiras de otimizar o custo do serviço, de acordo com as finalidades para as quais a Nuvem está sendo utilizada.  

Após o processo de otimização, tem início a terceira fase do FinOps: a operação. 

Aqui, serão formalizados os custos dentro do planejamento financeiro da empresa, gerando budgets e reserva de dinheiro para a compra dos recursos de Nuvem que são necessários, com relatórios customizados que vão trazer informações do quanto está sendo utilizado de cada um dos serviços de Nuvem contratados. 

Quem está utilizando esses serviços? Quais são as aplicações que utilizam esses serviços? Quanto do serviço está sendo utilizado fisicamente?

Questões que podemos solucionar com assertividade a partir da utilização do FinOps como modelo operacional para a Nuvem.

Reduzindo custos da Nuvem com FINOPS

A partir de agora, você vai conhecer as ações estratégicas do modelo FinOps para reduzir custos da Nuvem, começando pelo tagging

FINOPS – Fase 1 – Informação

O tagging funciona da seguinte maneira: você vai dizer para cada um dos microsserviços que estão rodando na Nuvem qual é o departamento, aplicação e a área da empresa que está fazendo a utilização do serviço.

É possível utilizar diferentes combinações de informações para fazer o tagging, e quando ele estiver pronto, é preciso rodá-lo durante um tempo para capturar dados de consumo da Nuvem atribuídos a cada uma das grandes áreas dentro da empresa ou das aplicações que estão sendo utilizadas. 

Isso ajuda a segregar o custo e a direcioná-lo, bem como a fazer uma alocação de custo correta, a partir da identificação de quais áreas da empresa estão gastando mais do orçamento. 

Na sequência, vem a medição do quanto está sendo utilizado de cada um dos serviços. 

Neste ponto, existem duas situações possíveis: contratar um serviço e utilizá-lo por uma fração do tempo que ele estiver disponível ou contratar um serviço e gerar uma instância do mesmo, que ficará ativa por um tempo considerável e será utilizada pontualmente. 

Após algumas semanas fazendo essa medição, é possível gerar informação e prever o quanto será utilizado de um determinado recurso ao longo do tempo, o que vai ajudar muito na fase de operação, quando será estimado o orçamento.

Ainda na fase de informação, os reports serão fundamentais para levar toda informação coletada em diferentes formatos para os diferentes públicos: técnico, financeiro, gestão. 

Assim, é estruturada a cadeia de informação necessária para poder operar o FinOps.

FINOPS – Fase 2 – Otimização

É na fase de otimização que se trabalha toda a informação sobre os recursos da Nuvem que estão sendo utilizados, começando por considerar aqueles que estão acima ou abaixo do que a empresa realmente precisa: ou seja, os recursos super e subprovisionados. 

Os serviços em desuso podem ser removidos do plano de Nuvem, o que ajuda a reduzir o custo. 

Outra estratégia é trabalhar com a automação, utilizando robôs para o levantamento e derrubada dos serviços menos utilizados. Dessa forma, dá pra fazer o trigger dos serviços mais robustos quando for necessário.

Tendo a previsão do quanto será utilizado de cada serviço da Nuvem, é possível fazer a compra de instâncias reservadas com até três anos de antecedência, que pode custar até 43% mais barato do que uma instância sob demanda. 

Além de todas essas ações, o right sizing será um grande diferencial para o dimensionamento adequado do serviço para cada tipo de aplicação utilizada, assim como a comparação de preços, levando em consideração serviços semelhantes com custos diferentes. 

Está gostando do artigo? Aproveite e baixe o ebook com o passo a passo para a implementação do FINOPS. Conteúdo exclusivo e gratuito!

FINOPS – Fase 3 – Operação

Na fase de operação “levamos o negócio para dentro da Nuvem”, por meio de uma visão de negócio de longo prazo. Eu explico.

Nesse ponto do FinOps, traçamos objetivos de crescimento, melhorias na performance e definimos as quantidades de acessos no futuro.

Com os orçamentos definidos, é necessário fazer o alinhamento do custo da Nuvem com os objetivos para chegar a conclusão sobre o quanto já foi atingido e qual o ritmo de investimento adequado para alcançá-los totalmente. 

É imprescindível ter governança nessa fase, por meio de relatórios periódicos do consumo do budget que foi reservado para a Nuvem, indicando o crescimento de uso da aplicação e o retorno que isso tá trazendo para o negócio.

Importante: aumentar o custo da Nuvem não significa, necessariamente, a existência de um problema. 

Vamos pensar na utilização de um serviço online, por exemplo, o Uber. 

Quando foi lançado, o Uber tinha pouca densidade de utilização. Com o tempo, o negócio foi ganhando escalabilidade, muitas pessoas começaram a consumir o serviço, e portanto, muitos mais recursos da Nuvem foram necessários para suprir a demanda.

Ou seja, o aumento do custo da Nuvem, em si, não é necessariamente um problema, porém, é preciso ter algum tipo de indicador que mostre o custo da Nuvem por usuário e esse valor tem que ser constante ou um valor que caia ao longo do tempo, a menos que se esteja implementando uma nova tecnologia ou funcionalidade, que apresentará oscilação no custo.

E concluindo a fase de operação, as melhorias devem ser constantes, considerando tudo o que mencionei até aqui, como por exemplo, melhorias na maneira como as aplicações estão sendo construídas e no tagging.

Aplicações que não estão sendo tagueadas, deixam de gerar visibilidade de como o custo está sendo consumido. Assim, uma “fatia” do custo da Nuvem deixa de ficar clara para a tomada de decisão e departamentos envolvidos (TI e financeiro).

Então, é muito importante acompanhar periodicamente os diversos indicadores que serão criados no momento de visibilidade e investir em melhorias da performance desses indicadores. 

FINOPS – Case Nubank 

O Nubank, fundado em 2013, é o maior banco digital independente do mundo, com mais de 20 milhões de clientes em todo o Brasil.

Quando iniciou a jornada de FinOps, não tinha visibilidade alguma do quanto estava gastando na Nuvem, com uma tendência de explodir os custos de nos próximos meses de utilização. Então, o Nubank adotou uma estratégia.

Primeiro, o banco passou pela fase de visibilidade e estabeleceu um indicador muito importante: o de custo da Nuvem por cliente. 

Esse índice considera uma massa de clientes para dividir o custo da Nuvem.

Dessa forma, o Nubank conseguiu monitorar, ao longo do tempo, como o custo da Nuvem estava crescendo para cada “x” quantidade de clientes que eles obtinham a mais, e também, conseguiram ter uma visibilidade  de qual seria a tendência para os próximos meses.

Objetivo: o Nubank estabeleceu uma estratégia de tagging muito agressiva para que nos próximos três meses após aplicar a estratégia, atingissem, no máximo, 10% das aplicações sem tagging, e isso era cobrado fortemente de todas as equipes. 

Naquele tempo, o Nubank tinha aproximadamente 90 serviços online, 50 squads trabalhando com a criação e a atualização de serviços. 

Os custos estavam crescendo de uma maneira descontrolada, e sem visibilidade, o banco não tinha uma estratégia definida, com uma demora extremamente grande entre um deploy de uma parte nova da aplicação e o outro. 

Três anos depois de aplicar a estratégia de FinOps, o Nubank manteve e até conseguiu reduzir o custo da Nuvem por cliente, mesmo com o aumento da quantidade de serviços ativos para mais de 250, com mais de 50 squads em operação.

Como resultado, o Nubank passou a trabalhar com custos da Nuvem previsíveis, por meio de uma visibilidade muito boa de como o banco vai crescer os serviços da Nuvem utilizados, seguindo como principais estratégias do modelo FinOps o tagging, a compra de instâncias reservadas e o right sizing

Assim, o Nubank se tornou um case de FinOps bem aplicado, chegando a fazer mais de 50 deploys de correções ou novas funcionalidades por dia de uma maneira praticamente instantânea, sem dores e sem ter saldos consideráveis no custo da Nuvem. 

Conclusão

Este artigo tem o objetivo de apresentar o conceito de FinOps, o modelo operacional para a Nuvem que possibilita a retomada do controle financeiro sobre a infraestrutura de TI. 

O controle dos recursos utilizados e a identificação dos departamentos que mais consomem os serviços da Nuvem são diferenciais estratégicos, voltados para a redução de custos em um cenário de trabalho conjunto entre TI e financeiro.

Se você ficou com alguma dúvida ou se precisa de ajuda para a implementação do FinOps na sua empresa, entre em contato clicando aqui!

E antes de me despedir, vou deixar um vídeo com mais informações sobre gestão de custos da Nuvem e FinOps. Abraço e até o próximo artigo!  👋👋👋

https://www.youtube.com/watch?v=mJjeDENeqTE&t=1133s

Management 3.0

Felicidade no trabalho com Management 3.0 — Como isso está funcionando para mim?

Por Luciano Osorio – Scrum Master da Zappts

Sou Luciano, Scrum Master na Zappts, e já trabalhei em muitas empresas (desde gigantes até empresas menores), e também já trabalhei para muitos clientes em diferentes áreas de negócios (saúde, serviços bancários, varejo, setor automotivo, etc).

Comecei como programador e ao longo de  10 anos mudei gradualmente para funções de liderança e gestão. Inicialmente, fui treinado nas práticas tradicionais de gerenciamento e depois fui para o Agile. 

Esta é a história de como consegui encontrar felicidade no meu trabalho como gestor, como isso se espalhou e como está fazendo com que meus times entreguem excelentes produtos. 

Acordando

Existem muitas teorias, livros e ferramentas de gestão por aí. Mas é raro encontrar uma que jogue na sua cara que o problema da gestão é provavelmente o mais óbvio: o gestor! Em outras palavras, é tudo sobre você.

Cruel? Talvez. Verdade? Com certeza! Ao menos no meu caso. Por que? Como gestor, fui treinado para esperar o pior das pessoas, para controlar tudo em detalhe e lidar com pessoas como se elas fossem máquinas. 

Se alguém precisa melhorar em algum aspecto de seu trabalho, basta mover uma alavanca (reclamar sobre algum comportamento, a minha versão de fornecer feedback), e voilá: a mudança está feita! O comportamento ruim desaparece e então… bem… eu aprendi da pior forma que isso não é verdade.

Eu estava perdido em um mundo de gráficos, projetos, relatórios, micro-gestão, times de baixo desempenho, grandes despesas, falta de propósito e muitos outros sinais de que não estava fazendo realmente um bom trabalho.

Como isso era possível? Eu sabia as práticas (CMMI, ITIL, e outros acrônimos, sem mencionar o Agile). Eu conhecia as métricas, as ferramentas … Então, o que poderia estar errado? Bem … Tudo em minha mente.

Levei alguns anos para descobrir e aceitar isso. Um projeto não é somente formado por práticas, métricas e ferramentas. Sim, é claro que tudo isso ajuda, mas um projeto envolve pessoas trabalhando com um propósito.

Volto para a definição de projeto do PMI (Project Management Institute):

Um projeto é um esforço temporário empreendido para criar um produto único, serviço ou resultado.

Em outras palavras, um projeto existe para preencher um objetivo ou propósito, e um produto, serviço ou resultado são necessariamente criados por pessoas, que estão alinhadas com esse propósito. E aqui é onde a mágica acontece!

Eu recebi um treinamento de Management 3.0 cedo demais, para ser honesto, e como eu estava começando minha experiência como gestor naquela época, não sabia, e nem poderia prever como isso iria impactar minha carreira no futuro. Então, eu guardei isso na prateleira do meu cérebro rotulada “para, talvez, ser usado no futuro”.

O futuro tornou-se o presente e após descobrir os problemas mencionados antes, fiz minha retrospectiva profissional e lembrei daquele treinamento. Olhando para as práticas do Management 3.0 mais cuidadosamente, comecei a perguntar …

O que posso fazer para ter um propósito no meu trabalho? Como eu posso comunicar esse propósito? Com posso fazer meu time ficar contagiado por esse propósito?

Tudo fez sentido quando eu li:

“Gerencie o sistema, não as pessoas”.

Para que as pessoas se sintam envolvidas, comprem a proposta e acreditem nela, todo o ambiente onde elas estão inseridas deve transpirar seu propósito. E eu não estou falando de poster na parede, camisetas com frases de efeito, etc. Estou falando sobre valores.

Agindo

Quais foram os passos que eu dei? Vou ilustrar cada um deles com os mais inspiradores e divertidos vídeos de Jurgen Appelo (exceto o segundo, que peguei do site Management 3.0).

Conheça as pessoas: Personal Maps

Feedback: Me ajudou a ficar mais próximo do time, entender quais são suas histórias, como eles acabaram trabalhando comigo e quais são os interesses que temos em comum. Me ajudou muito a iniciar conversas e criar relacionamentos.

Entenda o que as pessoas mais valorizam: Moving Motivators

Feedback: Deixou claro como abordar cada pessoa do time para discutir sobre os desafios a solucionar e como o papel de cada um se encaixa nesses desafios. O exercício em si foi usado como um ponto de partida para reuniões 1 a 1 que resultaram em objetivos a serem alcançados nos próximos períodos.

Celebre o que foi realizado: Celebration Grids

Feedback: Dá uma visibilidade clara durante as retrospectivas do que foi realizado (grandes ou pequenas coisas), e quais práticas levaram a esses resultados. Também me ajudou a responder às perguntas das retrospectivas (o que devo manter, alterar ou parar?) e criar planos de ação realistas para as próximas interações.

Estimule o reconhecimento: Kudos Box

Feedback: No meu caso, a Kudos Wall criou a oportunidade para pessoas se agradecerem pela ajuda, ensinamentos e suportes recebidos durante a última iteração. É incrível como pequenas coisas que você faz podem ter um valor enorme para alguém do time. 

Seja transparente: Happiness Door

Feedback: Criou a oportunidade de fornecer e receber feedback rápido sobre o trabalho diário e medir a felicidade do time. Junto às ações rápidas para mudar o que está deixando-os infelizes, criou um ambiente de confiança onde os membros do time sentem que podem levar assuntos mais sérios e desafiadores para serem tratados, e que às vezes, afetam suas vidas pessoais.

Forneça feedback honesto: Feedback Wraps

Feedback: Uma maneira muito estruturada, fácil e eficaz de dar feedback. Não nos permite dar feedback mecânico sem valor. É uma forma muito estruturada de abrir seus sentimentos sobre algo, apoiando-se em evidências e exemplos do que você espera como solução. Portanto, a outra pessoa terá bastante material para assimilar o feedback e executar as ações necessárias. 

As práticas acima criaram um ambiente onde existe confiança e as pessoas estão trabalhando com propósito e felizes. E quando o time está feliz, ele está comprometido com a qualidade, prazos, custos, e assim, entrega um produto melhor e que melhora o tempo todo.

Mantenha a ação…

Minha jornada Management 3.0 não acabou. Será que vai acabar?

Existem práticas que eu ainda não tentei, e pelos excelentes resultados a partir daquelas que mencionei anteriormente, mal posso esperar para começá-las. 

Portanto, aqui estão as práticas da minha lista “Vamos fazer isso”:

  1. OKRs – Objetivos e principais resultados (esta será a próxima)
  2. Delegation Poker
  3. Exploration Days
  4. Merit Money (Estou muito animado com esta prática!)

Todo o conjunto de práticas está relacionado aqui. Faça uma tentativa, veja como o trabalho pode ser divertido e traga felicidade para você também!

Gostou de aprender sobre Management 3.0?

Continue acompanhando o blog da Zappts para saber mais sobre gestão de times e aproveite também nossos conteúdos sobre Scrum, Transformação Digital e muitos outros temas!

Confira também as oportunidades de trabalho na Zappts e venha fazer parte do nosso time! https://www.zappts.com/trabalhe-conosco/

Eu fico por aqui. Até o próximo artigo!

Scrum x Kanban. E o vencedor é…

Qual estrutura de processos implementar em um projeto? Leia o artigo e entenda mais sobre as metodologias Scrum e Kanban!

Por Luciano Osorio – Scrum Master da Zappts

scrum kanban

Recentemente, um cliente estava considerando seriamente adotar a metodologia Scrum, mas de uma forma bastante particular.

As prioridades mudariam o tempo todo, o time estaria parcialmente alocado com pessoas compartilhadas entre vários projetos e as sprints deveriam ter uma semana de duração.  

Ele me pediu para ajudar a fazer esse modelo funcionar.

De acordo com o cenário exposto, recomendei o método Kanban como sendo o mais adequado, porém, a sugestão não foi aceita de início. Então, continuei estudando as melhores possibilidades.

Um dos problemas enfrentados nos projetos deste cliente era a falta de visibilidade sobre quanto trabalho realmente estava sendo realizado e como ele poderia melhorar a execução dos processos.

Mantive a recomendação e sugeri testarmos o Kanban por algumas semanas.

Agora, você pode estar se perguntando: mas qual o motivo da insistência em relação ao Kanban?

Bem, vou explicar o porquê dessa recomendação e aproveitar para esclarecer sobre as principais diferenças entre Scrum e Kanban.

Continue a leitura para descobrir!

Scrum x Kanban: A diferença está no compromisso e no foco

Vamos começar entendendo a diferença entre Scrum e Kanban e quais critérios avaliar para uma escolha assertiva e eficaz.

Scrum

No Scrum, o time se compromete com o produto. Toda sprint tem um objetivo para ser cumprido, que leva o time um passo à frente na entrega do valor do produto.

O time estima o trabalho que será incluído numa sprint e se compromete em realizar aquele trabalho com a maior qualidade possível. Sem interrupções ou mudanças de prioridade.  

O foco no objetivo da sprint é a principal temática das reuniões diárias do time. Elas devem ser realizadas com os propósitos de identificar problemas que impedem o alcance do objetivo e propor soluções removê-los dos processos.  

Ao final de uma sprint, aquele trabalho com o qual o time se comprometeu é avaliado e aceito como incremento de valor ao produto.

O time segue com uma avaliação de como o trabalho foi realizado durante a sprint e planeja as ações para trabalhar melhor na próxima.

Para entender mais sobre o que é Scrum, indico a leitura deste artigo, disponível em nosso blog.

É um conteúdo bem completo e com boas referências para se aprofundar no assunto 😉

Kanban

No Kanban, o time se compromete com o fluxo, ou seja, com o ritmo em que o trabalho realizado passa pelos passos do processo.

É necessário identificar os fatores que influenciam o fluxo e trabalhar para melhorá-lo sempre. Assim, é possível garantir que o trabalho não fique represado enquanto aguarda por algum passo.  

É preciso entender o passo mais lento e alinhar o ritmo para que ele ocorra de maneira fluida, sem acúmulos.

Além disso, no Kanban os membros do time executam um trabalho de cada vez. Esse foco ajuda a melhorar muito a qualidade do trabalho realizado.  

Aqui, mudanças de prioridade podem ocorrer livremente, pois ao selecionar o próximo trabalho, cada membro do time sempre escolherá o que é mais prioritário em um dado momento.

E para o time? O que é melhor: Scrum ou Kanban?

A resposta vai depender do contexto.

Em ambos os casos (Scrum e Kanban), times multidisciplinares executam o trabalho.

A relação entre os membros dos times seguindo os valores ágeis é fundamental em ambos os casos, além de uma liderança que deixe claro o propósito que eles devem perseguir, motivando-os a entregar o seu melhor sempre.

No caso do Scrum, a estrutura do framework com time-boxes cria a noção de começo, meio e fim a cada sprint, o que produz a sensação de atingir um objetivo.

Já no Kanban, o fluxo é contínuo e por não haver time-boxes, cada melhoria de fluxo conquistada pelo time deve ser celebrada, mantendo o foco na melhoria contínua.

Foco na coisa certa, ter objetivos claramente traçados e alinhados aos valores do time é sempre o melhor, e isso pode ser atingido com Scrum e Kanban.

Mas e o controle?

Em ambos os modelos há controle.

Métricas específicas, como Sprint Burndown mostram o avanço dos times Scrum ao objetivo diariamente e métricas como “velocidade” ajudam na previsibilidade das entregas.

No Kanban, o Diagrama de Fluxo Acumulado (Cumulative Flow Diagram), mostra claramente quais são os passos do processo que aumentam o Lead Time e que, portanto, necessitam atenção.

A métrica de Eficiência do Fluxo mostra a relação entre o tempo gasto em passos que estão trazendo valor e aqueles que não o fazem, mas que são necessários para o controle do processo, como inspeções, backlogs, etc.

Portanto, novamente, desde que com o foco adequado, Scrum e Kanban oferecem métricas que ajudam no controle e previsibilidade dos processos.

Scrum x Kanban: E o vencedor é…

Agora que já expliquei um pouco sobre as diferenças entre Scrum e Kanban e como avaliar a opção mais adequada, chegou o momento de responder à questão título deste artigo:

Scrum ou Kanban: qual o melhor?

Bom, como pudemos ver, não há vencedor neste “duelo”. O que há é uma necessidade de alinhar a escolha com o contexto, comprometendo-se com o que faz mais sentido.

Se estamos lidando com um time de produto, com um propósito definido, um escopo de projeto que evolui, mas de maneira ordenada e com prioridades definidas, o Scrum é recomendável e pode ajudar muito na realização dos objetivos do produto.

Por outro lado, se estamos lidando com um time que trata de uma demanda variável, com prioridades que mudam o tempo todo e problemas para conseguir completar o trabalho iniciado (o que se encaixa na situação do cliente que citei, lembra?), o Kanban ajudará na criação de um fluxo que tem um ritmo previsível.

Espero que essas informações possam te ajudar a entender Scrum e Kanban. São métodos aplicados para simplificar processos, ter mais flexibilidade no atendimento das demandas, e claro, melhorar o desempenho e integração da equipe de trabalho.

Abraço e até o próximo artigo!

Scrum Case: GE aumentou em 1000% do ROI em Treinadores Scrum

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.

Scrum Case: Como o FBI Desenvolveu em 1 ano um projeto que estava atrasado há 10 anos e com economia de 90% do investimento?

Por Luciano Osorio – Scrum Master da Zappts

Tradução Livre e Adaptada do texto original Software em 30 dias, escrito por Ken Schwaber e Jeff Sutherland (criadores do Scrum).

Em 2003, o FBI decidiu digitalizar os arquivos de caso das suas investigações. Isso permitiria que os investigadores pudessem comparar rapidamente os casos e descobrir conexões entre eles.

O projeto para automatização dos processos de comparação foi chamado de Sentinel.

O Sentinel Antes do Scrum

Em março de 2006, o FBI iniciou o desenvolvimento do Sentinel. A projeção era de uma base de mais de 30 mil usuários finais. Dentre eles: agentes, analistas e funcionários administrativos do FBI. Estimativas originais foram de US$ 451 milhões para o desenvolvimento e implementação do Sentinel até dezembro de 2009.

De acordo com o plano original do FBI, o Sentinel deveria ser desenvolvido em quatro fases. O FBI contratou a empresa de segurança Lockheed Martin para o projeto. Essa empresa propôs usar a metodologia tradicional de desenvolvimento de software, chamada Cascata.

Em agosto de 2010, o FBI gastou US$ 405 milhões do orçamento de US$ 451 milhões do Sentinel. Entretanto, o FBI entregou funcionalidades para apenas duas das quatro fases do projeto.

Mesmo que essas entregas tenham melhorado o sistema de gestão dos casos do FBI, elas não geraram tanto valor quanto foi previsto. Devido ao excesso de custo e ao cronograma apertado, o FBI cancelou o Sentinel em julho de 2010, deixando-o incompleto.

Scrum e a Nova Abordagem de Projeto

O FBI decidiu retomar o projeto com uma nova metodologia. O intuito disso era ver se haveria melhora nos resultados. Essa nova metodologia chama-se Scrum.

Segundo o Relatório CHAOS do Standish Group, apenas 37% dos projetos de software são bem-sucedidos. Apenas 14% dos projetos tradicionais (Cascata) tiveram sucesso, em comparação com 42% dos projetos ágeis (Scrum).

Além das definições tradicionais de sucesso do Standish Group, esses projetos também permitiram uma maior capacidade de resposta às mudanças nas necessidades dos clientes, permitiram uma melhor mitigação de riscos e, por fim, forneceram software de melhor qualidade.

Em 2009, o FBI recrutou um novo diretor de informações (CIO) e diretor de tecnologia (CTO) com experiência no gerenciamento de organizações que construíram software usando Scrum.

Em 2010, o CTO decidiu mudar a abordagem do Sentinel. Isso simplificaria os processos de tomada de decisão e permitiria ao FBI entregar o Sentinel dentro do orçamento.

O FBI disse ao Inspetor Geral do Departamento de Justiça que acreditava ser capaz de completar o Sentinel com o orçamento remanescente e dentro de 12 meses.

Uma auditoria já havia concluído que o FBI precisaria de mais US$ 35 milhões e mais seis anos se tivesse continuado com a metodologia tradicional.

O FBI reduziu a equipe do Sentinel de 400 para 45 pessoas, 15 das quais eram programadoras. O CTO fez o projeto sozinho, com o objetivo de fornecer novas funcionalidades do Sentinel a cada 30 dias. Cada nova funcionalidade precisava atender a todos os requisitos finais.

A cada três meses, o FBI implementaria os recursos que haviam sido construídos nas três iterações precedentes em um piloto de campo.

O Sentinel Um Ano Depois

Em novembro de 2011, após um ano de recomeço do projeto com o Scrum, todas as fases do Sentinel foram concluídas.

O software foi implementado em um grupo piloto de escritórios do FBI. Os demais escritórios tiveram implementação até junho de 2012. O FBI concluiu o Sentinel por US$ 30 milhões em 12 meses, uma economia de mais de 90%.

Depois que o FBI mudou sua abordagem, adotando o Scrum como ferramenta de Transformação Digital, eles trabalharam com a mesma intensidade de antes, mas foram recompensados ​​com resultados muito superiores.

Se uma organização como o FBI pode fazer isso, por que a sua não pode?

Scrum Case: Companhia Aérea Reduz de 50% a 75% o tempo de entregas de novas funcionalidades

Por Luciano Osorio – Scrum Master da Zappts

Tradução Livre e Adaptada do texto Original do Scrum Case Studies.

Em 2012, a liderança de uma companhia aérea internacional emitiu uma ordem para aumento de agilidade.

Essa empresa é grande e atende mais de 150 destinos ao redor do mundo.

A ordem foi emitida a fim de tornar a organização mais adaptável e capaz de reagir mais rapidamente a mudanças.

Para conseguir isso, uma equipe de desenvolvedores de TI focada em aplicativos móveis adotou o Scrum. Pouco tempo depois, mais equipes Scrumse formaram para aplicações web e mobile.

O Scrum foi adotado como ferramenta de Transformação Digital nessa companhia aérea.

As Equipes Scrum

Em janeiro de 2015, quatro equipes Scrum se formaram para trabalhar no aplicativo mobile de fidelidade dessa companhia aérea. Cada equipe específica focava em uma parte diferente do aplicativo: front end, back end, design e teste da experiência do usuário, incluindo um Product Owner.

As equipes estivam se dando bem com o Scrum. Porém, elas enfrentavam problemas de integração entre seus membros. Uma das causas disso eram todas as dependências que seus projetos sofriam. Além desse desafio, era necessário aumentar ainda mais a agilidade.

Lorenz Cheung, Treinador Scrum Profissional, Agile Coach e Scrum Master dessa companhia aérea, queria encontrar um meio para que essas quatro equipes diferentes criassem um trabalho integrado antes de aumentar a agilidade.

A Solução: o Framework Nexus

A fim de solucionar os desafios de integração, Lorenz Cheung adotou o Nexus. O Nexus é um framework para escalabilidade do Scrum criado por Ken Schwaber, co-criador do Scrum comum.

O Nexus é uma estrutura que repousa sobre várias equipes Scrum que estejam trabalhando juntas para construir um produto. Com base no Scrum, o Nexus foca em ajudar a superar as dependências entre as equipes e os problemas de integração.

O Nexus utiliza, além dos eventos do Scrum comum, suas versões próprias desses eventos. Um exemplo é o Nexus Sprint Planning. Ele também utiliza a Equipe de Integração do Nexus, que é responsável por garantir que pelo menos um Incremento Integrado seja produzido a cada Sprint.

Agora o Nexus é usado nessas quatro equipes Scrum, compostas por aproximadamente 40 pessoas, com um único Product Owner.

A Transição para o Nexus

Como eles tinham usado o Scrum com sucesso antes de adotar o Nexus, a transição não foi difícil.

Eles já tinham um único Product Owner para o produto inteiro, Sprint Planning compartilhado e Sprint Review compartilhada. Esse cenário abria caminho para uma progressão fácil e natural para o Nexus.

O Nexus se concentra na minimização e remoção de dependências entre as equipes. Ao mesmo tempo, ele permite a integração. Os quatro times Scrum podem trabalhar de forma independente porém interligada em um mesmo produto.

A cada Sprint, eles se concentram em um único incremento integrado, permitindo que eles entreguem softwares funcionais ao final de cada Sprint, satisfazendo a Definição de Pronto do Scrum.

Resultados

Ao usar o Nexus, essa companhia aérea conseguiu atender melhor às necessidades de seus clientes, liberando funcionalidades com maior frequência.

Por exemplo, as equipes de desenvolvimento puderam extrair feedback dos usuários da seção de pesquisa do aplicativo. Com isso, liberaram novos recursos em apenas duas semanas, retornando valor aos clientes.

Antes de aplicar o Nexus, as equipes Scrum estavam produzindo um incremento integrado a cada 8 semanas.

Agora, com o Nexus, cada equipe produz um novo incremento a cada 2 (75% de redução) ou 4 semanas (50% de redução), com o objetivo de entregar de forma mais consistente a cada duas semanas.

Previsões Futuras

Essa companhia aérea internacional começou com apenas um Nexus. No futuro, podem haver mais equipes de produto adotando o Nexus à medida que a empresa continua focando mais em Produto.

Lorenz Cheung implementou o Nexuspara produzir pelo menos um incremento integrado a cada Sprint. O objetivo era lançar produtos mais rapidamente e responder ao feedback dos clientes.

Ainda, o cenário ideal teria padronização Nexus em toda a empresa. Esse padrão seria feito com avaliações do nível de maturidade e de sucesso dos métodos ágeis em todas as equipes.

Scrum Case: Ganhos na Cobertura e Qualidade de Testes à Distância de 1 Clique em um Banco Europeu

 

Por Luciano Osorio – Scrum Master da Zappts

Tradução Livre e Adaptada do texto Original do ValueGlide, escrito por John Coleman.

Um grande banco europeu tinha várias equipes por produto que queriam uma alternativa ao Scrum, ao Kanban, ou ao Lean Startup.

As equipes queriam um padrão para esses métodos. Daí surgiu o Nexus+, que é igual ao framework Nexus mas com acréscimo do papel de Architecture Owner. O Nexus+ foi adotado como ferramenta de Transformação Digital nesse banco.

Em uma instância do Nexus+ nesse banco, haviam 5 equipes em um Nexus. Quatro equipes eram Scrum e uma equipe era Kanban. Um dos outros Nexus tinha três equipes: uma Lean Startup, uma Scrum, e uma Kanban.

O Escopo

A meta para os primeiros 6 a 12 meses da mudança para o uso do Nexus foi a entrega mais rápida. Em paralelo ocorria a retirada gradual do híbrido de Cascata/Scrum usado antes. Isso promoveu uma boa agilidade, sustentável e com propósito. O DevOps era a maior prioridade, vindo o Lean Finances em segundo. O objetivo em cada caso foi poder, mais tarde, focar no cliente e na inovação.

As pontuações DICE do Boston Consulting Group para prontidão para mudança desse banco só seriam verdes/amarelas se a meta de 6 meses fosse diluída ou se o escopo da organização fosse limitado.

Os colaboradores do banco começaram a visar melhores tempos e taxas de entrega com o objetivo de atrair mais clientes na onda de 6 a 12 meses de acompanhamento posterior.

O escopo foi de US$25 milhões em gasto aproximado.

Transição para o Nexus+e suas Instâncias

O Nexus era utilizado para ter Sprint Reviews mais ou menos mensais em todo o portfólio. As previsões eram feitas com simulações probabilísticas Monte Carlo para identificar “planos incríveis”.

Também houve desenvolvimento da capacidade interna. Quando houvesse corte de custos, a organização poderia continuar sua jornada de agilidade sem perder o ritmo.

Em uma das suas instâncias, o Nexus+ foi implementado com equipes distribuídas. As responsabilidades e metodologias de cada uma eram:

  • Europa: infraestrutura (DevOps e automação de testes). Kanban com tempo estruturado de aprendizado.
  • Europa: desenvolvimento da aplicação. Scrum.
  • Índia: desenvolvimento de aplicação. Dois times Scrum.
  • Estados Unidos: desenvolvimento de aplicação. Scrum.

Papéis e Desafios do Nexus+

O Architecture Owner é um papel importante, pois é responsável pelo fluxo do back end. No caso desse banco, o back end envolvia a autorização de cartões de crédito e débito.

As 5 equipes implementaram automação de testes e lançamentos mensais. Anteriormente, os lançamentos eram irregulares e impulsionados pela execução do projeto. Isso reduzia a previsibilidade e causava problemas de sequenciamento.

Por exemplo, se um projeto tivesse um componente com entrega atrasada, os projetos relacionados a ele precisavam reconsiderar e refazer seus testes. Isso permitia por volta de 6 a 10 lançamentos por ano.

Isso tudo foi feito em tecnologia antiga. Por esse motivo, houve necessidade de recorrer a testes automatizados de ponta a ponta, ao invés do TDD(Test Driven Development – desenvolvimento guiado por testes).

Todas as transações com cartões passavam pela tecnologia antiga. As equipes estavam alterando-a a cada mês utilizando DevOps.

As equipes possuíam um Product Owner disciplinado, um Architecture Owner orientado à agilidade, Scrum Masters apropriados, Scrum apropriado, Kanban apropriado. Isso eliminou o híbrido Cascata/Scrum rapidamente.

Há sempre novos desafios. Soluções causam novos problemas. Por exemplo, um desses desafios nessa instância do Nexus+ era a sincronização entre a costa oeste dos EUA e a Índia.

Desdobramentos

Apesar de todas as mudanças, a pressão dos órgãos reguladores e da diretoria foi grande. Com isso, a gerência recuou para o que eles sabem planejar em páginas, em gráficos de Gantt, e marcos imutáveis para os 6 meses seguintes.

Os marcos eram atingidos pela alteração do conteúdo da entrega. Ironicamente, embora essa “equipe de equipes” tenha argumentado contra os marcos, suas medições eram incrivelmente boas, com gráficos de queima de marcos (Burndown Charts).

O controle financeiro insatisfatório tornou difícil argumentar o caso do Agile. A diretoria achava que, se tivessem rastreado o custo em relação aos entregáveis, teria sido mais fácil mostrar valor (ou a falta dele). Era difícil para eles medir o valor de um sistema que a maioria das pessoas simplesmente considerava natural.

A realocação da equipe dos EUA para a Costa Oeste causou uma queda maciça na produtividade. Isso agravou o desafio da diferença de fusos horários. As pessoas na Europa e na Índia tiveram que se esforçar para tentar fazer a equipe dos EUA se sentir mais conectada.

Ferramentas de Mudança

As ferramentas de DevOps (com exceção da automação de testes) foram interrompidas devido à falta de financiamento, mas ainda continuam, como atividade paralela e conforme a equipe percebe o valor nelas.

O primeiro estágio será fazer build automaticamente a partir do Git usando o Jenkins para dar push no código para a plataforma NonStop. Já que não há um cliente NonStop Git adequado, com o build sendo executado pelo Jenkins usando macros (de uma linguagem para scripts bem antiga, chamada TACL) já existentes.

O retrabalho de testes usando o VersaTest produziu um pacote de testes muito mais preciso, com melhor cobertura. Os testes agora são limpos e, embora não sejam automatizados, basta pressionar uma tecla para rodá-los.

No geral, o saldo foi positivo. Nos 6 meses seguintes, houve implementação de builds automáticas. As métricas utilizadas sobre o que realmente pode ser fornecido pelo desenvolvimento são decentes. As equipes na Índia tiveram bons resultados.

Conclusão

A paixão, foco e energia dessas pessoas foi o que moveu a equipe. O Nexus foi um trampolim para o LeSS. É necessário mais suporte para as Feature Teams e a Teoria Y é necessária para essa próxima etapa.

Convenientemente, quando a mudança estava chegando à diretoria, houve resistência. Os colaboradores já estão saindo de lá e indo para outras empresas. Empresas que não tenham resistência às metodologias ágeis.

Não há melhora se a diretoria não compreender isso.

Scrum of Scrums: Como Empresários estão tendo ganhos +40% na velocidade com Agile em projetos de finanças, governo, manufatura, educação…

Por Luciano Osorio – Scrum Master da Zappts

Tradução Livre e Adaptada do texto Original publicado na Forbes, escrito por John Coleman.

Metodologias Ágeis fazem parte do cenário de TI há décadas. O Scrum, especificamente, surgiu nos anos 90.

Em vez de trabalhar isolados em uma bolha por meses e meses, os desenvolvedores são incentivados a trabalhar de perto com a empresa. Há liberação de iterações que melhoram continuamente.

Que lições os negócios voltados a outros setores podem aprender com a experiência que a TI já adquiriu com o Agile?

O que é Agile e Scrum of Scrums?

Ajay Budhraja é especialista em Agile e palestrante renomado. Ele possui décadas de experiência em posições de liderança em grandes empresas. Segundo ele, o Agile é altamente transferível.

Budhraja alertou que há equívocos tipicamente associados ao Agile. “Um deles é que o Agile resolverá todos os problemas em seus projetos”, diz ele. “O Agile oferece técnicas. Ele é como um mapa das linhas de metrô de uma cidade. Você ainda tem que analisar as informações que estão no mapa para entendê-lo e descobrir como chegar do ponto A ao ponto B. Além disso, o Agileainda precisa de documentação básica e muito planejamento.”

Desafios do Agile

Críticos do Agileafirmam que a metodologia não possui boa escalabilidade, e pode até mesmo retardar a entrega de soluções em uma era em que tudo tem que sair rapidamente.

Muitos desses problemas em potencial podem ser superados com uma forte colaboração entre as pessoas da empresa, explica Budhraja. “Alguns dos problemas que vejo são: identificar e monitorar inadequadamente as dependências entre as equipes; falta de planejamento, especialmente com equipes dispersas geograficamente; e foco insuficiente no gerenciamento de mudanças“, diz ele.

“Combinado com lançamentos rápidos e planejados, o Agile pode acelerar a entrega de soluções. Portanto, as equipes precisam trabalhar juntas para que isso aconteça.”

Outros Frameworks e Técnicas

Há também técnicas específicas que podem ajudar as práticas ágeis a escalar em uma parte maior da empresa. Budhraja recomenda o Scrum of Scrums, que “reúne muitas equipes nas quais representantes de cada equipe individual participam de reuniões do Scrum of Scrums.”

Outra técnica, SAFe, “é mais orientada para o processo e aborda isso em três frentes: equipe, programa e portfólio”.

Já a LeSS, ou Large-Scale Scrum (Scrum de Grande Escala), é uma maneira leve de escalar várias equipes.

A chave para garantir que a abordagem seja eficaz é trabalhar com equipes e com gerentes em toda a organização e balancear esse processo com base nas necessidades da organização.

O que é importante para construir uma organização Ágil?

Ele acrescenta que, com abordagens ágeis, as tarefas mudam. Por exemplo, no Scrum, com o Scrum Master facilitando os resultados do trabalho, outros que estavam realizando essas tarefas ficarão menos sobrecarregados.

“Com a entrega rápida, os trabalhos e as tarefas mudam, pois há um foco extremo no planejamento e na execução para entrega incremental.”

Resultados do Agile

Em última análise, as metodologias ágeis melhoraram a entrega de tecnologia nas organizações.

“Técnicas Agile são de entrega rápida e eu tenho liderado grandes projetos com tremendo sucesso nessas áreas”.

Em um projeto web e mobile que Budhraja conduziu usando Scrum, houve aumento de 40% na velocidade de entrega devido a ciclos mais rápidos. Nos projetos financeiros e governamentais, o aumento foi superior a 50%.

feedback dos clientes foi ótimo para esses projetos, já que o produto melhorou muito mais rapidamente.

O Programador pode ser o Scrum Master?

Por Luciano Osorio – Scrum Master da Zappts

Tradução Livre e Adaptada do texto Original publicado no Business 2 Community, escrito pela Stephanie Ockerman.

As pessoas que se perguntam se um desenvolvedor pode ser Scrum Master geralmente já estão desempenhando duas funções. Ou estão prevendo que é isso que vai acontecer com elas.

A resposta curta é: o Scrumnão tem regras contra o desempenho de dois ou mais papéis ao mesmo tempo. Cabe a cada um escolher o que é melhor dentro do contexto de sua organização e sua equipe.

A resposta mais longa envolve refletir se: você deve e você pode desempenhar esses dois papéis?

Contextualizando sua situação

Muitas vezes, essa situação surge do desejo de selecionar alguém de uma equipe de desenvolvimento já existente para ser o Scrum Master. As organizações geralmente não gostam de “adicionar funcionários”, a menos que tenham razões muito boas.

Não há nada inerentemente errado com essa abordagem. No entanto, é importante procurar alguém que possua as habilidades, características, conhecimentos e experiência desejados em um bom Scrum Master.

Para responder se você deve e se você pode, vamos explorar os 4 desafios mais comuns de quem é Scrum Master e Desenvolvedor simultaneamente.

Desafio 1: As responsabilidades do Scrum Master

Primeiro, vamos esclarecer as responsabilidades.

A equipe de desenvolvimento é responsável por criar pelo menos um Incremento de Produto funcional até o final de cada Sprint.

O Scrum Master é responsável por garantir que todos entendam e sigam o Scrum. Para isso, ele ajuda-os a cumprir com mais eficiência suas funções.

“Um Scrum Master atende o Product Owner, a Equipe de Desenvolvimento e a organização. Essa é uma gama ampla de responsabilidades. Se um Scrum Master é percebido pela equipe ou pela organização como apenas um “facilitador de eventos” ou “aplicador do Scrum”, o impacto da função e os benefícios da Agilidade nos negócios são diminuídos.”

Ensinar é mais do que uma simples lição. A facilitação é mais do que definir o tema e conduzir uma reunião. Saber qual abordagem adotar e quando servir melhor uma equipe é muito desafiador, mesmo para Scrum Masters experientes.

As equipes e organizações precisam reconhecer que, se essa pessoa não tiver experiência e habilidades como Scrum Master, ela precisará de suporte. Um treinamento, por exemplo. Isso exigirá tempo e comprometimento. E ainda, reduzirá o tempo gasto com desenvolvimento do produto, o que nos leva ao segundo desafio.

Desafio 2: Focar mais em fazer o trabalho

Muitas vezes, existe uma pressão na organização para “entregar mais”. Além disso, a vocação da pessoa pode ser mais alinhada com o desenvolvimento do produto do que com a liderança da equipe.

Quando qualquer uma dessas opções for verdadeira, será muito desafiador para essa pessoa ter comprometimento suficiente e dedicar mais tempo para se aprimorar como Scrum Master.

Mesmo que a pessoa escolhida tenha uma forte paixão pelo papel de Scrum Master, todos os demais precisarão respeitar isso e dar a essa pessoa o tempo e o apoio necessários.

Isso significa que a equipe de desenvolvimento provavelmente precisará adaptar sua forma de trabalho para enfrentar o próximo desafio.

Desafio 3: Planejamento de capacidade e habilidades escassas

É difícil saber exatamente quanto tempo é necessário para exercer a função dupla de líder-liderado. Também é difícil saber exatamente quanto tempo é necessário para criar um produto complexo que atenda à meta da Sprint e a uma alta qualidade e integridade.

Tanto a equipe de desenvolvimento quanto o Scrum Master estão fazendo um trabalho complexo!

Quando um membro da equipe de desenvolvimento também é o Scrum Master, o resto da equipe de desenvolvimento precisará ser mais flexível e menos dependente desse indivíduo para construir o produto. Isso geralmente requer uma redistribuição dos conhecimentos, habilidades e atividades de desenvolvimento, o que demanda tempo.

Por isso é importante discutir abertamente sobre as necessidades de cada membro e da equipe nas Sprint Retrospectives. O mesmo vale para as conversas do cotidiano.

Desafio 4: Confusão com autoridade, propriedade e auto-organização

Um Scrum Master que também é desenvolvedor precisa respeitar a responsabilidade e a autonomia compartilhadas pelos integrantes da equipe de desenvolvimento.

O Scrum Master é frequentemente visto como o “especialista” e como uma posição de autoridade. Mas é preciso lembrar que a autoridade e o conhecimento de um Scrum Master são especificamente sobre o uso efetivo do Scrum como ferramenta. Não é sobre a melhor forma de criar um incremento funcional ou sobre quanto trabalho deve ser realizado em um Sprint.

Neste cenário, um Scrum Master deve prestar atenção nas dinâmicas de equipe mais complexas.

Como membro da equipe de desenvolvimento, essa pessoa é líder e liderado ao mesmo tempo. Portanto, pode opinar sobre como o trabalho é feito ao mesmo tempo que é responsável pela qualidade e integridade desse trabalho. E, como Scrum Master, a pessoa deseja que toda a Equipe de Desenvolvimento se sinta responsável por criar o Incremento.

Além disso, os desenvolvedores devem entender que têm poderes para decidir qual a melhor forma de realizar o trabalho. Permitir e aumentar a auto-organização se torna ainda mais desafiador.

Conclusão

Então, afinal, você deve e você pode? Primeiro, tenha uma discussão aberta sobre esses desafios listados. Depois faça uma pergunta a si mesmo. Por que você deseja que um membro da Equipe de Desenvolvimento também seja o Scrum Master?

Existem algumas motivações, uma delas pode ser a economia de recursos, ou pode ser que uma das funções não seja vista com a mesma importância. Ambas motivações indicam problemas a serem resolvidos.

Se você descobriu outras razões que parecem válidas, talvez a combinação de papéis faça sentido no seu contexto e valha a pena tentar. Certifique-se de discutir com frequência como isso está funcionando para garantir que o desempenho no projeto não seja prejudicado.

E aí, o que achou do conteúdo? Deixe sua opinião nos comentários e compartilhe-o com sua rede!