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!

Transformação Digital: O que é, como aplicar e os seus maiores desafios!

  

A Transformação Digital é um conceito que surgiu no início dos anos 2000, com a popularização da Internet, dos computadores pessoais e do conceito de globalização dos anos 90.

Desde então, a presença da tecnologia no cotidiano das instituições mais diversas tem sido cada vez maior e mais dinâmica. Das casas de família às empresas multinacionais, essa ferramenta já faz parte das nossas vidas.

Mas o que isso significa para os processos manuais de trabalho? Realizar pagamentos com um cartão de plástico, ir a uma farmácia física para comprar remédios ou pedir empréstimos pessoalmente no seu banco? Tudo isso é passado.

Como esse processo generalizado de transformação digital tem afetado as organizações e como fazê-lo de forma eficiente na sua empresa?

O que é Transformação Digital?

Transformação Digital surgiu da demanda de empresas em resolverem problemas de forma mais rápidaeficaz e, de preferência, automatizada.

Para aplicá-la, é necessário o uso de tecnologias que se integrem à cultura e ao modelo de negócios da empresa, otimizando as funções antes desempenhadas de maneira tradicional.

Mais do que isso, a Transformação Digital é um modelo de negócio usado por organizações para se adequarem ao digital. No processo de implementação, a organização torna-se moldada pelo digital.

O uso de canais ou ferramentas digitais, isolado, não caracteriza transformação digital.

A transformação digital depende, além da gestão correta dos recursos organizacionais, de uma mudança cultural dentro da empresa. Essa gestão deve ser feita de forma que boa parte das habilidades técnicas sejam automatizadas. Isso permite que os funcionários possam focar seu desempenho em suas habilidades interpessoais e utilizar as tecnologias como ferramentas.

Os cinco domínios da Transformação Digital são: Clientes, Competição, Dados, Inovação e Valor.
Adquira redes de clientes com funis de venda reinventados, melhor jornada de compra e análise dos padrões de comportamento dessas redes. Construa plataformas, não apenas produtos, usando novos modelos de negócio, retirando intermediários e aumentando o valor competitivo dessas plataformas. Transforme dados em vantagens competitivas ao analisá-los para extrair valor e tomar decisões. Inove com experimentações rápidas, como protótiposMVPs e projeções de escalabilidade. Adapte suas propostas de valor com novos conceitos de mercado, novas trajetórias de saída de mercados em queda e etapas para avaliar a evolução do suporte.
Fonte: Brand Leadership

Exemplos de Transformação Digital

O perfil dos consumidores mudou de forma generalizada após a popularização dos smartphones e das mídias sociais; mídias essas que acabaram se tornando os principais veículos de relacionamento entre clientes e muitas marcas.

Hoje, não basta um serviço ou produto de qualidade: os clientes querem que a experiência seja a parte mais valiosa do que estão comprando e a ascensão da prática do UX Design é reflexo disso.

É importante entender que a transformação digital não se resume ao uso de ferramentas digitais. A organização se aproxima do cliente não através de ferramentas, mas sim da quebra de paradigmas, quebra que deve ser feita visando entregar o que o cliente precisa com mais agilidade.

Transformação digital é algo mais amplo do que usar canais digitais. Ela é sobre começar a tomar decisões com análise de dados. O digital é apenas uma ferramenta para impactar o cerne do negócio. Os dados são o insumo para a tomada de decisão.

Um exemplo é a mudança do processo de envase na linha de produção industrial. As máquinas de envase de garrafas de refrigerante podem passar a captar dados. Haverá registros de quantas garrafas de um litro, dois litros e três litros são envasadas por minuto, por hora e por dia. A análise posterior desses dados auxilia na otimização de custos e na mitigação de falhas na produção.

Alguns Setores que se Beneficiam com a Transformação Digital:

Com a difusão do acesso à internet, é difícil pensar em um setor que não se beneficiaria com a transformação digital. A maioria dos serviços e produtos possui ao menos uma parte do seu processo de venda que pode ser otimizada por um ambiente de cultura fortemente digital.

Tendo isso em vista, sempre há os setores que se beneficiam mais do que outros, e são eles:

  • Financeiro e Bancário;
  • Saúde;
  • Telecomunicações;
  • Varejista;
  • Educacional;
  • e Recursos humanos.
Imagem: Prova Fácil na Web

Transformação Digital no Setor Financeiro

Aqui, vamos olhar o setor financeiro separado dos bancos tradicionais. O motivo dessa abordagem é a ascensão das Fintechs, empresas de pagamento, consultorias de investimento e outras organizações que lidam com finanças mas operam como bancos.

A Importância da Análise de Dados

Os bancos lidavam com um volume grande de dados. Esses dados eram subutilizados pois estavam atrelados apenas a transações. A análise de dados começou a ser feita como parte da transformação digital ao perceberem a ascensão do conceito de Business Inteligence.

Essa análise ajudou na tomada de decisões mais eficazes, baseadas nos dados demográficos dos clientes e em seus padrões de comportamento.

Esses padrões são utilizados para mitigar riscos e detectar possíveis fraudes. Ainda, podem ser empregados na personalização da experiência do cliente.

Tanto em bancos quanto em outras instituições financeiras, ou ainda em outros setores, o embasamento em dados para tomar decisões tem sido fundamental. Calcular melhor os riscos na hora de conceder um empréstimo é um exemplo dessas decisões.

Transformação Digital nos Bancos

O setor bancário já tem se digitalizado há algum tempo. Os bancos foram os primeiros a utilizar canais digitais, na década de 90. Nesse quesito, esse setor sempre esteve à frente do mercado.

Já na remodelagem de negócios para adequar-se à cultura organizacional digital, o atraso nesse setor é igual ao observado em outros setores.

A implementação de caixas eletrônicos nas agências e, depois, o desenvolvimento de aplicativos para internet banking tiraram uma boa carga de atendimento dos funcionários ao digitalizar processos mais simples como saques, transferências e depósitos, mas devido a complexidade de serviços como empréstimos e investimentos, e à preocupação com a segurança, a transformação digital nos bancos só começou recentemente.

Com o surgimento das Fintechs, baseadas em contas exclusivamente digitais e atendimento personalizado para cada cliente, como a Nubank, os bancos tradicionais tiveram de investir ainda mais em inovação. Os grandes bancos tradicionais estão tendo que rever seus valores e suas jornadas de compra.

Isso implica não apenas na aceleração do processo de digitalização dos serviços e produtos, mas também na remodelagem de negócios. É daí que surge a verdadeira Transformação Digital.

Experiência do Usuário voltada à Autonomia

É imprescindível pensar na transformação digital com foco na liberdade e individualidade dos clientes. Hoje, eles priorizam o acesso às suas finanças, de qualquer lugar e a qualquer hora.

Essa tendência surgiu pois os usuários, especialmente os jovens de idades entre 18 e 25 anos, estão mais orientados ao digital e buscam a comodidade, rapidez e facilidade proporcionadas pelos aplicativos mobile como seu meio principal de acesso ao internet banking.

Um passo fundamental para bancos que adotam a transformação é a aquisição de clientes mais jovens que já são familiarizados com ambientes virtuais.

Outro fator comportamental notável é que quanto mais jovem o cliente, menor a importância dada por ele a marcas renomadas e hábitos já estabelecidos. Por isso a necessidade de maior investimento em inovação.

O processo de autoatendimento traz autonomia aos clientes e maior liberdade na tomada de decisões, autonomia que ajuda os funcionários das agências tradicionais a focarem em processos mais demorados e complexos, processos que podem ser otimizados por conjuntos de conhecimentos exclusivos de cada colaborador, atribuindo aos bancos tradicionais um papel mais consultivo.

A redução do número de agências físicas implica na economia de uma renda que, idealmente, deve ser canalizada para a transformação digital. Iniciativas que reforcem a cultura digital dentro dos grandes bancos irão salvá-los da obsolescência.

Sistemas Legados

A maior dificuldade da transformação digital nos bancos é a complexidade e magnitude de seus sistemas legados, que estão rodando há muitos anos de forma satisfatória.

A ideia de ter gastos com a reformulação desses sistemas pode parecer pouco atraente para os líderes da organização. Entretanto, é importante frisar que o investimento em tecnologias mais novas e ágeis gera otimização em todas as operações da empresa.

Se isso for feito tendo o usuário como foco (sendo usuários tanto os clientes quanto os colaboradores), a fidelização e satisfação serão ambas otimizadas. O objetivo é melhorar cada vez mais a experiência dos humanos, tanto clientes quanto colaboradores envolvidos nas transações.

Alguns exemplos desse tipo de tecnologia podem ser vistos no funcionamento das Fintechs, que detalharemos a seguir.

As Fintechs

O Banco Central do Brasil instituiu em 2011 a possibilidade de contas exclusivamente digitais. Isso reduziu o custo das agências físicas e facilitou a conquista de clientes mais jovens, que antes não eram o foco do setor bancário.

As fintechs são empresas que usam a tecnologia para tornar os serviços financeiros mais eficientes. Por causa delas é que este artigo divide o setor financeiro em duas partes: bancos e instituições de pagamento.

É comum que as fintechs sejam instituições de pagamento, e não bancos, entretanto, temos no Brasil um exemplo de fintech que se enquadra em ambas atuações: o Inter.

Algumas dessas empresas desafiam os bancos tradicionais são conhecidas como challenger banks (bancos digitais com licenças que os permitem operar com dinheiro físico) ou neobanks (bancos digitais 100% digitais).

No Brasil, a fintech mais conhecida é a Nubank, criada em 2013. Segundo um estudo da consultoria EY (Ernst & Young), empresas como a Nubank e o Inter são utilizadas por 40% dos clientes digitais no Brasil.

O grande diferencial entre os bancos tradicionais e as fintechs é justamente o foco em consumidores mais jovens. Estes eram ignorados pelos bancos até pouco tempo atrás, enquanto as fintechs já nasceram com foco neles.

Essa negligência por parte dos bancos se deve ao risco de crédito e pelas baixas margens desses clientes, já que a maioria deles está se profissionalizando agora. Isso gerou uma imagem negativa dos jovens para os bancos tradicionais, e vice versa.

Exemplos de Serviços Financeiros Digitais

Na China, os serviços AliPay e WeChat representam 92% dos pagamentos do país. No Quênia, existe a conta mobile M-Pesa, que é focada em quem nunca usou bancos tradicionais.

Na Índia, o WhatsApp já implementou seu serviço de pagamentos. A previsão para o lançamento mundial desse serviço é 2020.

Outros exemplos de ferramentas para pagamentos digitais desvinculadas de um banco ou fintech específico são o PicPay, o PayPal e o PagSeguro.

As tecnologias implementadas nesses serviços são diversas. As mais comuns são o atendimento ao cliente feito por chatbots e o pagamento por aproximação (chamado NFC ou contactless) ou por QR Code.

O foco da Transformação Digital acaba sendo não apenas em otimizar processos com auxílio de canais digitais, mas também em otimizar os recursos humanos ao criar uma cultura fortemente digital dentro da organização. – Imagem: Trello

Transformação Digital na Área da Saúde

análise de dados com Big Data é aplicável a todos os setores que queiram passar pela transformação digital. Ela permite traçar padrões de usuários de um serviço e também seus padrões de comportamento. A rota para isso é avaliar os dados para encontrar características comuns entre pacientes.

Essa análise é fundamental para a otimização de processos, por isso, a transformação digital na área da saúde traz muitos benefícios como:

  • maior agilidade no atendimento médico,
  • maior precisão nas análises e prescrições de medicamentos,
  • maior segurança para o profissional da saúde pois as chances de erros por falta de informações serão menores,
  • diagnóstico precoce de doenças, com base nos padrões de comportamentos e de perfis,
  • monitoramento de um paciente à distância,
  • aumento da precisão de procedimentos.

Essa transformação já começou em alguns dos grandes hospitais do Brasil. O Sírio Libanês, por exemplo, usa robôs para simular procedimentos cirúrgicos e para auxiliar durante esses procedimentos. O Hospital do Coração, utiliza tecnologia de ponta no tratamento Gamma Knife, também conhecido como radiocirurgia estereotáxica, um método não invasivo utilizado para tratar lesões nos órgãos, cabeça e pescoço.

Além disso, os canais digitais podem ser atualizados e utilizados para melhor gestão de todos os processos hospitalares. O acesso remoto e a integração de informações otimizam essa gestão.

Transformação Digital nas Telecomunicações

transformação digital no setor de telecomunicações assemelha-se à dos bancos em alguns aspectos. Por exemplo, na quantidade de sistemas legados, na rapidez em digitalizar mas lentidão em transformar digitalmente, e na demanda dos clientes em terem uma experiência mais eficiente e sem intermediários.

Como citado anteriormente, a análise de dados persiste na sua importância.

Outra tendência que persiste em todos os setores mas que talvez não tenha ficado clara anteriormente é o Omnichannel. As mídias sociais e a experiência mobile tornaram comum que o usuário espere poder começar um processo em um canal digital e terminar em outro.

Transformação Digital no Varejo

No varejo, a disseminação de e-commerces web e mobile para lojas físicas, bem como contas em mídias sociais de brechós e lojas exclusivamente virtuais, aliados ao marketing digital, facilitaram a compra e venda de produtos antes restringidos aos grandes centros comerciais físicos.

As demandas de mercado hoje não dependem mais apenas de intuição. Coletar dados sobre os clientes e suas preferências é crucial para alimentar as estratégias de marketing e vendas e personalizar a experiência de compra com a oferta de promoções específicas e a sugestão de produtos similares.

Há alguns fatores que contribuem no retorno de clientes e recomendação orgânica para clientes novos. Ter as vontades percebidas pelas marcas é um exemplo. Ter essas mesmas vontades levadas em conta no atendimento e na resolução de problemas apontados pelo consumidor final também.

Uma nova dinâmica de venda observada nos varejos é a compra online com retirada em loja física sem cobrança de frete. Essa retirada em loja física facilita a entrega tanto para o cliente quanto para a loja.

Um desafio na transformação digital é a comunicação interna com os vendedores. A digitalização do processo de compra é positiva não só para quem compra, mas também para os funcionários e para a empresa. Ela possibilita que, através do sistema interno, os vendedores possam fechar pedidos feitos em loja física de produtos que não estão disponíveis no estoque daquela unidade. Isso faz com que ainda recebam comissão e evitem que o cliente prefira procurar pelo produto em lojas concorrentes. Varejos que querem utilizar dessa nova estratégia de venda precisam trabalhar sua cultura interna para que os colaboradores entendam as vantagens e auxiliem no processo de transformação digital.

Transformação Digital na Educação

Nas instituições de ensino, há formas de facilitar a aprendizagem dos alunos com a transformação digital.

Os laboratórios de informática e a disponibilização online de material para estudo são algumas dessas formas. Especialmente para aqueles estudantes que possuem menos recursos disponíveis em suas casas.

Entretanto, é importante que a implementação da educação seja feita corretamente. Disponibilizar livros e lições tradicionais não basta; isso é apenas o uso de canais digitais.

A verdadeira transformação digital se trata de articular os canais digitais dinamicamente e tirar proveito da inteligência de dados fornecida pelos alunos para definir as ações a serem tomadas dentro do plano de ensino.

E consequentemente oferecer flexibilidade aos alunos, o que implica na autonomia e estimula o comportamento autodidata.

Transformação Digital nos Recursos Humanos

No RH, alguns processos automatizados ou digitalizados pela transformação digital são:

  • o uso de inteligência artificial no recrutamento e seleção;
  • contato com candidatos pelas mídias sociais ou por videochamada;
  • automação operacional (ponto e banco de horas, geração de folha de pagamento, férias…);
  • calcular taxas de rotatividade e produtividade de funcionários;
  • flexibilização da jornada e local de trabalho devido a meios remotos de comunicação e gestão;
  • análise e cruzamento de dados comportamentais.

Por que a transformação digital falha em tantas empresas?

Silos organizacionais

Um desafio enfrentado por muitas empresas durante a transformação digital é a falta de foco, ou ainda o excesso dele.

Uma transformação digital eficiente não se resume à TI, à experiência do cliente ou à digitalização de arquivos. Empresas que obtêm sucesso nessa jornada são aquelas que integram todos os seus setores de forma a revolucionar a cultura organizacional.

Essa revolução deve ser feita com o combate aos silos, com a revisão e possível mudança do modelo de negócios, e com a aquisição, retenção e evolução de talentos.

Profissionais ligados a tecnologia têm valorizado cada vez mais suas relações interpessoais com seus líderes e colegas de equipe e a experiência pessoal e profissional que podem adquirir com essas relações.

Isso exige que as empresas se preparem para receber melhor esses novos funcionários. Essa preparação inclui planos de carreira definidos de forma previsível mas flexível o suficiente para que predisposições e vocações individuais sejam valorizadas.

Isso só é possível com a integração de todos os setores, onde todos os colaboradores conhecem e entendem todas as operações organizacionais o suficiente para se sentirem parte do todo. Focar apenas na implementação de processos digitais ou apenas no setor de TI é tão equivocado quanto não ter uma estratégia de TI traçada para o futuro.

Sistemas legados e transição para Sistemas Integrados

Tratar a transformação digital como um evento é equívoco cometido pela maioria das empresas, ela é uma jornada na qual é necessário avaliar continuamente a maturidade digital da empresa e a necessidade de manutenção de sistemas legados,

Como citado anteriormente no tópico sobre transformação digital no setor bancário, em muitos casos, levando-se em conta os custos envolvidos, a melhor rota de ação é refatorar os sistemas legados e atualizá-los, ou até mesmo descartá-los por completo.

Isso deve ser feito para criar uma rede de sistemas integrados na organização. Visando melhor desempenho desses sistemas como ferramentas, consequentemente, haverá melhor desempenho comercial.

Expectativa e Realidade na transformação digital

Outro erro recorrente é a falta de alinhamento de expectativas com as realidades atual e projetada da empresa. É imprescindível que haja transparência durante toda a transformação digital. Isso evitará frustrações dos colaboradores e buracos de orçamento ao longo das etapas de mudança organizacional.

Os componentes de uma plataforma digital de negócios são: Clientes, Ecossistemas, Inteligência, Coisas, e Sistemas de TI.
A Inteligência é o centro de tudo. Os Clientes e as Coisas se relacionam pela Análise de Dados.
Cada componente possui sua própria plataforma: plataforma de Experiência do Cliente (CX), de Ecossistemas, de Internet das Coisas (IoT), e de Sistemas de Informação. Cada plataforma serve a um stakeholder: a plataforma de CX serve aos Clientes, a de Ecossistemas serve aos Parceiros, a de IoT serve às Coisas, e a de Sistemas de Informação serve aos Funcionários.
Fonte: Gartner

Como mudar a cultura da sua organização para que a transformação digital prospere?

Mudar a cultura de uma empresa pode ser uma tarefa difícil. Os líderes responsáveis por pesquisa e implementação de inovações (CIO’sCTO’sGerentes e Coordenadores em geral), precisam mostrar os meios disponíveis e para que fins essas mudanças se fazem necessárias. Entretanto, qualquer alteração na cultura organizacional depende tanto dos gestores quanto dos funcionários, com diálogo constante e possibilidades de crescimento visíveis para todos.

Revisão de processos e do modelo de negócios

Para que haja apoio da equipe nessa caminhada para uma nova cultura, avaliar operações já enraizadas no cotidiano organizacional pode revelar meios inovadores de aumentar eficiência e diminuir gastos.

É importante que todos estejam cientes da importância e urgência da transformação digital. Para isso, ter acesso a cursos que os eduquem a ser mais técnicos e possam entender ao menos o básico de cada operação nessa transformação pode ser benéfico. Essa educação geraria naturalmente uma cultura voltada ao digital e à cooperação entre setores.

Canalizar a otimização de custos para a aquisição desses cursos é uma forma de estimular o surgimento de novos interesses e novos talentos entre os colaboradores.

Investimento em talentos

É importante que a adesão às medidas educacionais tomadas nessa reforma cultural sejam incentivadas pelos líderes de cada setor. A finalidade disso é abrir espaço para que novos perfis de liderança se formem dentro das equipes.

Mapear de forma transparente os custos, riscos e expectativas de resultados da transformação digital dentro do contexto da empresa facilita a caminhada na otimização de custos e aproveitamento de talentos. Assim, há a garantia de que essa nova visão de negócios tenha longevidade.

Uma das tecnologias que podem impulsionar a Transformação Digital é a computação em nuvem. – Imagem: OnlineSites.com

Tecnologias que impulsionam a transformação digital

Tecnologias básicas

Quando se fala em transformação digital, é comum pensar nela como algo intimamente ligado a tecnologias disruptivas, mas isso não é necessariamente verdade.

Antes de pensar em aplicar BlockchainInteligência Artificial ou Internet das Coisas à transformação digital de uma organização, é preciso analisar o modelo de negócios e a cultura organizacional com cuidado, começando pelas tecnologias básicas. Pergunte a si mesmo: de que forma posso otimizar o banco de dados e a inteligência de negócios da minha empresa para aumentar o lucro com a venda de produto X ou Y?

Essas alterações de base ocorrerão naturalmente e de forma concomitante à inovação da cultura organizacional. É importante frisar mais uma vez que a transformação digital é um processo contínuo e exponencial, o que implica em algumas relações de causalidade: melhorar a comunicação interna também melhora a integração entre setores e a experiência dos funcionários, o que resulta em melhoria na qualidade dos serviços e a experiência dos clientes.

Algumas das tecnologias que facilitam a transformação digital são: automação, dispositivos móveis, computação em nuvem, análise de dados, Big Data, Business Intelligence (BI), CRM, mídias sociais e Internet das Coisas (IoT) – Fonte: Neosoft Technologies

Tecnologias disruptivas

Dito isso, após analisar as tecnologias mais simples já implementadas na empresa e melhorá-las ao máximo, o próximo passo é pensar em alternativas mais sofisticadas para resolver problemas:

  • Computação em Nuvem para não precisar se preocupar com servidores;
  • Inteligência Artificial para automatizar partes do atendimento ao cliente,
  • Big Data para auxiliar na tomada mais precisa de decisões…

Ainda aliadas a essas tecnologias, temos as Metodologias Ágeis como o Scrum. A implementação dele pode ser muito benéfica ao processo de transformação digital ao melhorar a eficiência e rapidez das entregas. As possibilidades são muitas, e cabe à gerência escolher o que melhor encaixa ao contexto da empresa.

Saiba Mais sobre Transformação Digital

Caso você queira se aprofundar, os vídeos a seguir são boas fontes de aprendizagem sobre o tema:

Cases de sucesso da Transformação Digital

Netflix

Um exemplo clássico de um case que demonstra o sucesso da transformação digital é a Netflix.

No início dos anos 2000, a Netflix estava no ramo de locação de filmes. Ao contrário da concorrente Blockbuster, a Netflix soube como e quando fazer a transição para o digital.

Magazine Luiza

A Magazine Luiza se consolidou como uma rede de lojas físicas de varejo distribuídas pelo Brasil inteiro antes de começar seu processo de transformação digital em 2017.

Os resultados foram expressivos: um crescimento de quase 600% em relação ao segundo trimestre de 2016.

Hoje, 2 anos depois, a Magazine Luiza é um dos maiores marketplaces do país.

GE Healthcare

Como citado anteriormente, o Scrum também pode ser considerado um agente na transformação digital. Na GE Healthcare, os ganhos de produtividade após a implementação do Scrum foram alcançados em um ritmo sustentável.

Devido ao ambiente de trabalho de alta qualidade fornecido pelo Scrum para os desenvolvedores, conseguiram aumentar a retenção de funcionários e a qualidade de contratação atraindo os melhores profissionais do setor.

IDX Systems (agora GE Healthcare) contratou Jeff Sutherland como vice-presidente sênior de engenharia e desenvolvimento de produtos para estender o Scrum ao desenvolvimento em larga escala.

Essa foi a primeira abordagem na IDX para organizar todo o grupo de desenvolvimento em um conjunto interligado de Scrums.

Foi uma abordagem de base de equipe, incluindo dois vice-presidentes, um arquiteto sênior e vários diretores. O problema em garantir a qualidade do processo em cada equipe foi que toda a organização teve que aprender Scrum de uma só vez.

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

O IDX alcançou ganhos produtivos médios de 240%. No início, o orçamento da organização de desenvolvimento do IDX era de quase US $ 50 milhões por ano e essas equipes eram cerca de 10% da organização.

Com o Scrum, as equipes alcançaram um aumento médio de produtividade de 666%. O ganho líquido de produtividade de todas as equipes combinadas foi de 240%.

(As informações sobre esse case foram retiradas em tradução livre do site ScrumCaseStudies.com.)

Cathay Pacific Airways

A Cathay Pacific Group, com sede em Hong Kong, oferece transporte de passageiros e de cargas para mais de 200 destinos na Ásia, América do Norte, Austrália, Europa e África, utilizando uma frota de cerca de 200 aeronaves.

Em 2015, a Cathay Pacific tinha um grande projeto em mãos: desenvolver um novo mecanismo de reservas na Internet (Internet Booking Engine – IBE). Eles precisavam de uma estrutura que os ajudasse a entregar dentro de um prazo específico.

Em fevereiro de 2017, a Cathay Pacific adotou o framework Nexus desenvolvido pela Scrum.org e pelo co-criador do Scrum, Ken Schwaber.

Eles começaram a implementar o Scrum como sua principal estrutura para entrega de software. O projeto IBE foi seu primeiro projeto ágil envolvendo várias equipes Scrum trabalhando no mesmo produto.

Como parte do projeto, a Cathay Pacific diminuiu sua equipe de 40 para 29 pessoas. O objetivo dessa diminuição era de simplificar seus processos e poder trabalhar em menos tempo e sem sobrecarga extra.

Dentro de dois meses após a implementação do Nexus para o projeto IBE, os times Scrum aumentaram a frequência de quando eram capazes de liberar incrementos integrados em 200%. De um lançamento a cada três meses, para pelo menos uma vez por mês e até duas a três vezes por mês, com melhoria na qualidade também.

Outro ponto positivo do Nexus Scrum foi o aumento do engajamento do Product Owner. Antes, ele não tinha visibilidade adequada e, portanto, não compreendia totalmente o progresso no desenvolvimento dos entregáveis.

Agora, o Product Owner consegue entender e expressar o que está realizando e entregando em termos de valor.

Outro Exemplo de Transformação Digital na Aviação

Outro case de sucesso da transformação digital no setor de aviação ocorreu em 2012, em uma outra empresa asiática de aviação comercial.

A liderança sênior dessa empresa emitiu uma ordem para aumento de agilidade 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 Scrum se formaram para aplicações web e mobile.

Em janeiro de 2015, quatro equipes Scrum se formaram para trabalhar no aplicativo de fidelidade de celular dessa companhia aérea. Cada equipe desse esquema focava em uma parte diferente do aplicativo móvel: front endback enddesign e teste da experiência do usuário, incluindo um Product Owner.

As equipes de desenvolvimento puderam extrair o feedback do usuário da seção de pesquisa e incorporá-lo ao aplicativo.

Assim, liberaram novos recursos em apenas duas semanas. Isso gerou retorno de valor aos clientes e aos negócios em geral. Agora, as equipes Scrum produzem um incremento integrado a cada duas ou quatro semanas. Isso é 30% mais rápido do que antes. O objetivo é entregar de forma mais consistente a cada duas semanas.

(As informações sobre esses dois cases foram retiradas em tradução livre dos sites Scrum.org e ScrumCaseStudies.com, respectivamente).

Transformação Digital é sobre otimizar tecnologias e utilizá-las para uma boa gestão de documentos e recursos dentro da empresa. – Imagem: Accenda Digital

FBI Sentinel Project

O Virtual Case File (ou VCF) foi um aplicativo desenvolvido pelo Federal Bureau of Investigation (FBI) dos Estados Unidos entre 2000 e 2005. O projeto não estava nem perto de ser concluído quando foi oficialmente abandonado em janeiro de 2005. Esse abandono acabou sendo um fiasco para o FBI.

Além de desperdiçar pelo menos US$ 100 milhões, o fracasso manchou a imagem da agência e de seu diretor, Robert S. Mueller III.

US$ 575 milhões de dólares desperdiçados nas duas primeiras tentativas do projeto.

O Scrum Studio foi criado no porão do Hoover Building e a equipe reduziu de 400 pessoas para 40. Ao retomar o projeto, em 1 ano e com US$ 30 milhões, o código do projeto estava completo, com uma redução de custos de mais de 90%.

(As informações sobre esse case foram retiradas em tradução livre do site ScrumCaseStudies.com).

Cateno

Aqui na Zappts nós também temos alguns cases de nossos clientes.

Cateno é uma joint venture criada pelo Banco do Brasil e pela Cielo para atuar na gestão de meios de pagamento.

Em parceria com a Zappts, a Cateno alcançou resultados de performance, de agilidade e qualidade. Reduzimos para 3 dias um processo que antes demorava de 30 a 40 dias para os usuários finais.

Desenvolvemos uma conta digital em 90 dias para clientes reais utilizarem. Com o uso, validamos hipóteses no processo de escalabilidade da solução para o mercado.

GIGA

Outro case de sucesso aqui na Zappts é a GIGA. Seu aplicativo de segurança, o Giga Monitor, teve ganhos relevantes no estudo e implementação de interfaces com base nas necessidades dos usuários finais.

Além disso, houve 67% de ganho na performance para ativação de câmeras de segurança, o que gerou uma melhora de 121,5% das avaliações na App Store e na Play Store:

Simplificando, os cinco passos para a transformação digital são: elaborar novas experiências e modelos de negócio; desenvolver uma cultura de DNA digital; aplicar novas tecnologias à infraestrutura existente; tomar decisões baseadas em dados e não em intuição; e cocriar e coinovar com novos parceiros. – Fonte: Constellation Research

Quero Implementar a Transformação Digital na minha Empresa, e Agora?

Neste artigo deixamos claro que a transformação digital é realidade e é URGENTE!

Mas iniciar esse processo sem um guia pode ser mais trabalhoso do que o necessário, mas você pode contar com um especialista no assunto, como a Zappts, que tal? Temos squads de desenvolvimento dedicados para cada projeto. O intuito dessa divisão dedicada é entregar soluções com agilidade e eficácia para nossos clientes.

Este artigo está em constante atualização. Por favor, deixe as suas sugestões, dúvidas ou críticas nos comentários!

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

  

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?

  

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

  

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: entenda de uma vez por todas o que é, como ele aumenta expressivamente os seus resultados e porquê utilizá-lo

  

O Scrum é um framework para desenvolver e manter produtos complexos. A metodologia foi definida no guia escrito pelos seus criadores, Ken Schwaber e Jeff Sutherland, e intitulado Guia Do Scrum.

Dentro desse framework, pessoas podem tratar resolver problemas igualmente complexos adaptativos, enquanto produtiva e criativamente entregam produtos da melhor forma e com o mais alto valor possível. O instrumento para isso é o desempenho de papéis, eventos e artefatos unidos e integrados por regras específicas.

O Scrum está sendo usado desde o início de 1990 e continua relevante até hoje. Isso acontece pois ele foi idealizado para ser inerentemente leve e simples de entender, porém extremamente difícil de dominar, como um jogo de pôquer.

Para explicar isso de forma aprofundada, é necessário entender o paradigma inicial da indústria de desenvolvimento e o como e porquê ele foi modificado. Começaremos conhecendo um pouco mais sobre as metodologias de desenvolvimento.

As Metodologias de Desenvolvimento

A Metodologia Tradicional

No início da indústria de desenvolvimento de software, a metodologia utilizada para gestão de projetos consolidou-se em fases bem definidas. Eram elas:

  • levantamento de requisitos,
  • análise de requisitos para esboço da arquitetura,
  • implementação via código/programação,
  • testes,
  • lançamento do produto,
  • e suporte/manutenção.

Essa metodologia foi posteriormente denominada Cascata (ou Waterfall), pois cada fase é executada hierarquicamente, uma após a outra. Uma fase só começa quando a anterior termina.

A Cascata é planejada em reunião com o cliente. A forma como isso é feito não admite mudanças, pois tudo é estabelecido logo no começo do processo. Todos os requisitos, escopos de produto e de projeto e, consequentemente, planejamento de custos são fixos. Não há análise de riscos ou maior participação do cliente até a entrega do produto finalizado.

Por ser um processo tão baseado em fases, ele acaba sendo demorado e engessado. Essa demora impede que os clientes tenham o desenvolvimento de entregáveis na velocidade que necessitam.

A longo prazo, isso gera sistemas já lançados em tecnologias ultrapassadas ou com carência de funcionalidades específicas para a resolução do problema proposto inicialmente, que pode ter mudado durante o desenvolvimento do sistema.

Além disso, cada profissional do time fica responsável por uma parte do projeto e não se comunica com frequência, sem muita consideração pelas “skills” de cada um. Para neutralizar esses problemas e diminuir a burocracia envolvida, surgiram as metodologias ágeis.

As Metodologias Ágeis

Nas metodologias ágeis (muitas vezes encurtadas para Ágil ou Agile), o time discute e elabora em conjunto a entrega do produto final.

Há distribuição de tarefas conforme o conhecimento técnico e o desempenho de cada integrante. Isso garante a viabilidade do planejamento ao levar em conta as peculiaridades dos indivíduos envolvidos.

A implementação de projetos é feita de forma cíclica e iterativa. Um projeto é composto por vários ciclos. Sempre é considerada sua efetividade na resolução dos problemas e dores propostos pelo cliente. Muitas vezes ele passa por adaptações ao final de cada ciclo de acordo com as demandas que acabam surgindo.

Isso significa que os métodos ágeis são flexíveis e proporcionam entregas constantes para o cliente, sempre levando em conta seu feedback. Contraste ao método tradicional de desenvolvimento de software.

A sinergia da equipe de desenvolvimento é imprescindível para que a Agilidade funcione. Essa sinergia, nesse caso, não é restrita apenas à equipe. Ela deve se estender a todos os indivíduos e setores envolvidos no projeto, para que o time de desenvolvimento possa manter seu foco e performance altos.

Ao identificar falhas de gestão ou de comunicação, a equipe deve utilizar de todos os agentes disponíveis na organização para neutralizá-las. Sendo, assim, autossuficiente no seu gerenciamento de riscos, processos e resultados.

Exemplos e Características de Metodologias Ágeis

O conceito de metodologia ágil foi baseado no Lean Manufacturing. O Lean é um modelo de manufatura utilizado pela Toyota após a Segunda Guerra Mundial. Mas ele só foi formalizado em 2001, pelo Manifesto Ágil.

Semelhanças comuns a todas as Metodologias Ágeis

Algumas das metodologias ágeis mais utilizadas nas empresas atualmente são o Scrum e o Kanban. O que elas têm em comum, além da Agilidade, é um conjunto de práticas baseadas em certos valores, discriminados no Manifesto Ágil como:

  • Priorizar indivíduos e interações mais do que processos e ferramentas. Todas as pessoas envolvidas no processo devem trabalhar em conjunto e diariamente, comunicando-se de forma constante e aberta. Todos devem buscar sempre manter um ambiente de trabalho sustentável que propicie suporte, motivação e confiança.
  • Valorizar o bom funcionamento do software mais do que a documentação abrangente. Software funcional feito de forma rápida e com qualidade é a medida primária de progresso.
  • Colaborar com o cliente mais do que negociar contratos.
  • Responder a mudanças mais do que seguir um plano. Avaliar o progresso do projeto a cada ciclo e aceitar mudanças de requisitos mesmo no fim do desenvolvimento. Assim o cliente pode tirar vantagens competitivas.
  • Maximizar a quantidade de trabalho que não precisou ser feito ao primar por excelência técnica dos membros do time e por design e usabilidade simples e intuitivos.
  • Construir, pela convivência diária, times auto-organizáveis. Os membros do time refletem sobre maneiras de aumentar sua produtividade e efetividade com base nos resultados de cada ciclo. Assim, ajustam seu comportamento a fim de otimizar sua sinergia e aumentar sua frequência de entregas.

Diferenças entre Scrum e Kanban

Já o que as diferencia é:

  • Scrum é sobre autogestão e sobre como os desenvolvedores interagem e o que fazem quando não estão escrevendo código.
  • Kanban é sobre evitar desperdício de recursos e otimizar a produção. Isso acontece ao limitar a carga de trabalho de cada desenvolvedor. É criada uma visualização do fluxo de recursos na linha de produção com post-its em um quadro.

O Kanban é contínuo e o Scrum é iterativo. O Scrum tem ciclos fechados com objetivos definidos que se repetem, enquanto o Kanban é mais adequado para times que possuem trabalho não planejado à vista. Por exemplo, problemas de suporte e funcionalidades requisitadas emergencialmente – pois não possui ciclos.

Agora, após esse conteúdo introdutório, vamos abordar o Scrum. Definiremos o que ele é, mostrando de onde ele veio, e destrinchando todos os seus papéis, eventos, artefatos e regras.

E então, o que é o Scrum?

Origem do termo Scrum

O nome veio do rugby, no esporte, há um movimento chamado Scrum. Ocorre quando os jogadores dos dois times formam um círculo ao redor da bola, encostando suas cabeças e medindo forças para pegá-la.

O Scrum é considerado uma demonstração da força e união da equipe para atingirem seu objetivo.

É por isso que a metodologia ágil abordada aqui adotou esse mesmo nome.

Diferença entre Scrum e Agile

É comum ter a impressão de que esses termos são iguais. Entretanto, Agile é um conjunto de métodos e práticas baseadas nos valores expressos no Manifesto Ágil.

Já o Scrum não é um processo ou uma técnica para construir produtos. Ele é uma estrutura metodológica (ou framework) incremental que é usada para implementar o desenvolvimento Ágil. Você pode empregar vários processos ou técnicas para isso.

O Scrum deixa clara a eficácia das práticas de gerenciamento e desenvolvimento de produtos das empresas em que é implementado, de modo que elas possam melhorar essas práticas.

O framework consiste nos times Scrum associados a papéis, desempenhados por membros da equipe durante eventos, com auxílio de artefatos.

Como descrito no Guia Do Scrum, cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum. As regras integram os eventos, papéis e artefatos, administrando as relações e interações entre eles.

De onde o Scrum surgiu?

O criador do Scrum

Jeff Sutherland trabalhou como militar no exército dos Estados Unidos durante 11 anos. Após esse período, ele decidiu estudar Medicina na Universidade do Colorado. Ele acabou se envolvendo com coleta de dados e desenvolvimento de sistemas.

Durante os anos 90, Sutherland enxergou um problema recorrente na sua nova área de interesse. Empresas que demandavam projetos de software com um cronograma apertado e orçamento incompatível. Ele decidiu encontrar uma solução para esse problema.

O grande diferencial do Scrum

Pesquisando, Sutherland acabou chegando ao Lean Manufacturing utilizado na Toyota e em outras empresas japonesas. Com auxílio de Ken Schwaber, criou a metodologia Scrum com base nesse sistema de manufatura.

Depois de provada a eficácia do Scrum por uma série de sucessos, essa nova metodologia popularizou-se rapidamente na indústria de desenvolvimento de produtos.

O Scrum representa a troca da visão algorítmica de projetos para uma visão heurística. As pessoas e a autogestão são a chave para resolver problemas. Eles são priorizados em tarefas individuais e delegados aos membros da equipe mais bem preparados para cada uma delas.

Imagem: Método Ágil

A Equipe Scrum

Times (ou Equipes) Scrum são auto-organizáveis e multifuncionais. Ser auto-organizável significa que os membros é que escolhem a melhor forma de realizar seu trabalho, ao invés de serem dirigidos por pessoas fora da equipe. Ser multifuncional significa que uma equipe tem nela todas as competências necessárias para realizar o trabalho sem depender de agentes externos.

O modelo de equipe do Scrum foi pensado para otimizar a flexibilidade, a criatividade e a produtividade. Geralmente um time possui de três a dez membros. Quando dez pessoas não dão conta do trabalho, o time é dividido em dois. Novos membros são adicionados a cada nova equipe, junto com os membros originais.

Dependendo do tamanho do projeto e da quantidade de times, é aconselhado aplicar o Scrum of Scrums, que abordaremos mais adiante. Os membros do time desempenham papéis específicos.

Product Owner: O Dono do Produto

O papel desta pessoa é representar os interesses do usuário final, sendo a ponte entre o time técnico – representado pelo Scrum Master – e os demais stakeholders. O PO estará sempre balanceando as demandas dessas duas partes.

Esse membro tem autoridade para dizer o que vai fazer parte do produto final ou não. Normalmente ele é um usuário chave do sistema, ou um usuário com boa compreensão dos requisitos e do que ele e outros usuários precisam.

O Product Owner precisa saber Programar?

Ele pode tanto ser alguém com background técnico (alguém que já foi um desenvolvedor front end ou um UX designer, por exemplo) como pode não ser (um analista de negócios, o CEO da empresa ou o próprio cliente).

Apesar de ser listado como parte da equipe Scrum, o Product Owner não é um elemento integrante dela.

Sua presença e disponibilidade para a equipe são constantes mas ele não faz parte do processo de desenvolvimento. O que ele faz é mais ligado a estratégias de negócio entrega de valor. Sua função é muito mais “política” do que técnica.

O Product Owner é responsável pelo Product Backlog, que é uma lista de tarefas descrevendo as funcionalidades necessárias do produto final e ordenadas por prioridade. Quem determina o grau de prioridade de cada tarefa é o Product Owner, baseando-se no valor de negócio e no ROI previsto delas.

Para isso, ele deve ter entendimento claro e profundo da visão do produto, ter autonomia para tomada de decisões, e ser comunicativo o suficiente para poder transmiti-las claramente para o resto do time.

Scrum Master: O Dono do Processo

O papel do Scrum Master é garantir que os valores e regras do Scrum sejam seguidos cotidianamente pelo resto do time. Ele é responsável por decidir o tamanho dos ciclos de desenvolvimento de software. No Scrum, esses ciclos são chamados de Sprints. Cada Sprint pode durar de uma a quatro semanas.

Além disso, ele é o intermediário entre a equipe de desenvolvedores e o Product Owner. O Scrum Master serve de “alívio” para que o Product Owner possa focar nas estratégias de negócio e na entrega de valor com os demais stakeholders. Enquanto isso, o Scrum Master lida diretamente com o time de desenvolvedores e gerencia o Sprint Backlog.

Por quê Dono do Processo?

O Scrum Master pode ser chamado informalmente de Dono do Processo pois ele é o membro que equilibra as relações internas e externas da equipe Scrum. Ele lida diretamente com o Product Owner e com o time de desenvolvimento, mas pode transitar entre outros setores da empresa ou entre outros stakeholders, por exemplo.

Isso acontece pois a outra responsabilidade do Scrum Master, além do Sprint Backlog, é blindar os desenvolvedores. Ele filtra quais informações chegam aos “devs” e evita interferências no Sprint, trabalhando sempre para resolver qualquer impedimento ao progresso da equipe.

Durante o Sprint, este membro age como mentor e gestor dos desenvolvedores, conversando com eles constantemente para resolver possíveis impedimentos. “Minha máquina está com problema e por isso não consigo programar”, “não tenho conhecimento suficiente nessa tecnologia para executar essa tarefa”, “o colega que senta ao meu lado está me irritando”, “sou interrompido muitas vezes durante o dia”, entre outros obstáculos técnicos ou pessoais, por exemplo.

O SM sempre mantém o Sprint Backlog atualizado para analisar a performance individual e coletiva. Além disso, ele vê quais tarefas são completadas e em quanto tempo, assim prevendo e ordenando quais tarefas terão de ser adiadas para o Sprint seguinte.

A estimativa do trabalho que não pode ser adiado para o próximo Sprint é calculada todos os dias, e colocada em um gráfico chamado de Sprint Burndown Chart (ou apenas Burndown Chart – Gráfico de Queima, em tradução livre).

Mentor e Facilitador para os Desenvolvedores

Sendo mentor dos desenvolvedores, o SM precisa mantê-los motivados e certificar-se de que as tarefas do Sprint estão sendo executadas do jeito certo. Ele faz isso levando os pedidos do PO e dos demais stakeholders em consideração.

Entretanto, a autoridade e autonomia do SM são menores do que as do PO, já que seu escopo de ação é restringido ao time de desenvolvedores.

As medidas de blindagem que ele pode tomar acabam dependendo da colaboração de agentes externos à equipe Scrum. Por isso, é importante que o SM seja um bom negociador e saiba conversar com os stakeholders de forma amigável.

O Scrum Master precisa saber Programar?

background técnico do Scrum Master na área de software, assim como o do Product Owner, é opcional. Porém, é interessante que ele entenda ao menos o básico dos conceitos de desenvolvimento e das tecnologias aplicadas ao projeto da sua equipe. Isso lhe trará mais segurança ao garantir a qualidade dos entregáveis.

O Scrum Master não é responsável pela execução das tarefas do Sprint, mas precisa assegurar que essa execução é feita da melhor maneira possível dentro das capacidades, limitações e acordos do time.

Desenvolvedores

Quando se fala de Time Scrum, os primeiros membros a serem mencionados geralmente são os desenvolvedores de software.

Na equipe de desenvolvedores, é necessário que os membros sejam alocados de forma que qualquer problema no software possa ser solucionado por eles em sua totalidade, sem ajuda externa.

Não existe necessariamente uma divisão dos membros por funções desempenhadas individualmente. Como, por exemplo, designer, front end, back end, arquiteto, analista de testes…

No Scrum, todos os membros trabalham juntos para entregar ao final de um Sprint aquilo que foi prometido no início dele. Por isso, todos acabam sendo fullstack em maior ou menor grau.

O Scrum é baseado em refletir sobre o desempenho passado com transparência e comprometimento. Todos os integrantes sabem o que cada um está fazendo e como cada tarefa está progredindo. Todos se comprometem em mudar o que for necessário para melhorar o desempenho da equipe.

É importante que a equipe permaneça ágil, integrada e comunicativa. Fazer parte de um time sinérgico acaba naturalmente ajudando todos os membros a se manterem motivados e empenhados em criar um processo mais eficiente.

Artefatos Scrum

Os Artefatos Scrum são disseminadores de informação que representam trabalho ou valor. Eles fornecem transparência ao dar oportunidades de inspeção e adaptação do processo de desenvolvimento.

Eles são projetados especificamente para maximizar a transparência de informações, para que todos os stakeholders tenham o mesmo entendimento do conteúdo de cada artefato.

Os artefatos obrigatórios do Scrum são apenas o Product Backlog, o Sprint Backlog e o Product Increment. Porém, além deles ainda existem artefatos opcionais, cujo uso é decidido pela equipe. Os artefatos, tanto obrigatórios quanto opcionais, são:

Product Backlog: a lista de desejos

Product Backlog – a Reserva do Produto, em tradução livre – representa uma listagem das funcionalidades desejadas pelo cliente. Em acordo entre o Product Owner e o cliente, elas precisam ser desenvolvidas com maior urgência.

Os itens discriminados neste backlog são priorizados, adiados ou descartados por valor de negócio pelo Product Owner, e podem ser tarefas técnicas ou não.

O Product Backlog não precisa estar completo desde o início do projeto. No começo os desenvolvedores podem trabalhar só com o que for mais simples ou óbvio ao sistema projetado. Depois, à medida que os Sprints são concluídos e o software é incrementado, pode-se adicionar mais coisas ao backlog.

Assim, com negociação entre os stakeholders e análise contínua das funcionalidades entregues, esse backlog pode crescer e mudar, sempre levando em conta o que se aprende sobre o produto e sobre a jornada do usuário.

Sprint Backlog: os afazeres desse ciclo

Durante o Sprint Planning, que abordaremos no tópico de Eventos Scrum, o PO prioriza os itens do Product Backlog e os descreve para o SM e para a equipe.

A equipe então determina quais dos itens descritos ela poderá completar durante o próximo Sprint. É disso que surge o Sprint Backlog, que nada mais é do que uma lista de tarefas ou afazeres.

Esses afazeres são divididos entre os integrantes do time pelo Scrum Master, de acordo com a percepção da equipe sobre as habilidades de cada membro e sobre o tempo que será empregado para completá-los.

Mudanças de escopo nos itens do Sprint Backlog após o início do Sprint devem ser evitadas ao máximo. Elas atrapalham o andamento do Sprint e tiram o foco da equipe no trabalho. Se for necessário modificar algo, o Scrum Master deve negociar com os desenvolvedores e com o Product Owner sobre como e o que mudar e quais são os motivos para essa mudança.

User Stories: Histórias do Usuário

Até agora, nós nos referimos aos itens dos backlogs como tarefas, mas nem todas as equipes Scrum falam assim. Algumas preferem falar de User Stories, ou Histórias do Usuário.

“Tarefa” é uma palavra genérica para os itens dos backlogs e que pode ser usada isolada ou conjuntamente com “Histórias”.

O cérebro humano funciona melhor quando escuta histórias. Temos maior entendimento e empatia quando um interlocutor nos transmite os motivos das suas escolhas descreve sua trajetória. Nesse contexto, o interlocutor é o usuário do sistema.

Assim, resumidamente, as User Stories são descrições simples e curtas de uma funcionalidade a ser implementada no software.

Elas são contadas do ponto de vista do usuário, apontando por qual motivo ele deseja que o software seja capaz daquela função. Geralmente, as Stories são escritas nesse padrão:

“Como USUÁRIO, eu quero FUNCIONALIDADE para que RAZÃO”.

Por exemplo: “Como gerente de estoque, eu quero poder adicionar ou remover produtos do cadastro de estoque, para que haja maior controle do fluxo de vendas”.

As User Stories geralmente são escritas em cartões ou em post its. Eles podem ser dispostos em paredes, lousas ou mesas para facilitar o planejamento e a discussão. Essa disposição também pode ser feita em ferramentas digitais, como o Trello.

Isso ajuda na visualização das funcionalidades. O foco muda da escrita sobre recursos para a discussão ativa e coletiva sobre eles. Assim, o time está exercendo os princípios Scrum de comunicação e transparência.

Como detalhar as User Stories?

Se necessário, detalhes podem ser adicionados às Histórias de duas maneiras:

  • quebrando uma História mais complexa em outras menores e mais simples,
  • ou adicionando condições de conclusão ao cartão que a descreve.

No primeiro cenário, já é presumido que as novas Stories criadas contém detalhamento adicionado a elas.

No segundo cenário, as condições de conclusão são apenas um obstáculo colocado ali para garantir maior cuidado no desenvolvimento daquela funcionalidade. É natural que todas elas sejam cumpridas por consequência desse cuidado.

Qualquer um no Scrum pode escrever User Stories. Cabe ao Product Owner aceitá-las na fila de prioridades que é o Product Backlog. Ao longo do ciclo de vida do projeto, é esperado que todos os membros do time acabem escrevendo uma História em algum momento.

A identidade do autor da User Story é irrelevante. O que realmente importa é quem vai discutir sobre ela e trabalhar em cima dela no decorrer do projeto.

Da mesma forma, não é obrigatório que todos os itens dos backlogs sejam escritos no formato de História. Às vezes, é muito mais fácil, rápido e intuitivo simplesmente escrever palavras chave, escrever casos de uso ou desenhar diagramas ou layouts simples. O Scrum descreve o que precisa ser feito, mas não há regra sobre como fazer.

Story Points: a unidade de medida do progresso

Um Story Point é uma medida abstrata do esforço necessário para implementar uma User Story. Assim como User Stories, o uso de Story Points e de Burndown Charts é opcional.

Resumindo, é um número que informa a equipe sobre o nível de dificuldade da História. Nível esse que está relacionado a particularidades, riscos e esforços envolvidos na execução de cada História específica.

Na maioria dos casos, um Story Point usa uma das seguintes dimensões:

  • Sequência de Fibonacci: 1, 2, 3, 5 ,8, 13, 21;
  • Tamanhos análogos aos tamanhos de camiseta: PP, P, M, G, GG;
  • Ou a sequência simples do 1 seguido de múltiplos de 2: 1, 2, 4, 8, 16.

Os Story Points representam estimativas de alto nível e geralmente são feitos após o Sprint Planning. O PO, o SM e o time de desenvolvimento fazem uma estimativa grosseira onde checam se:

  • o planejamento foi conduzido de forma eficiente;
  • há informação suficiente para cumprir tudo que foi designado para aquele Sprint; e
  • se as User Stories foram divididas de forma razoável entre os membros da equipe.

Estimativas baseadas em medidas de tempo como horas ou dias, em contrapartida, são estimativas de baixo nível. Elas representam o esforço palpável (relação hora/homem da mão de obra) demandado para completar aquela User Story.

Story Points são Medidas de Tempo?

Na verdade, Story Points e medidas hora/homem têm propósitos diferentes para situações diferentes e não devem ser comparados ou utilizados de forma exclusiva. O certo é evitar relacioná-los para que o Sprint e o lançamento do produto sejam melhor executados.

A hora/homem não é igual para todos os desenvolvedores, mas os Story Points sim. Isso permite que pessoas com velocidades diferentes e níveis de habilidade diferentes consigam chegar num consenso.

Atribuir determinada quantidade de Story Points para uma User Story é mais flexível do que atribuir uma quantidade de horas ou dias. Assim, a janela de entrega da Story acaba sendo a mesma para todos os membros do time.

Cada Story Point representa uma distribuição normal de tempo. Por exemplo: um Story Point pode representar um intervalo de 4 a 12 horas, dois Story Points seriam de 10 a 20 horas e assim por diante.

Essa distribuição de tempo é desconhecida durante a estimativa, pois ao usar Story Points, não é necessário saber quanto tempo leva, só é necessário ter uma indicação aproximada de quanto tempo vai demorar para aquilo ser concluído. O Planning Poker é utilizado para designar os Story Points.

Burndown Charts: uma visão geral do projeto

O monitoramento do progresso do projeto, no Scrum, geralmente é feito com um gráfico chamado Burndown Chart ao final de cada Sprint.

Existem várias formas de Burndown Chart. A forma utilizada é determinada pelo Scrum Master em conversa com os desenvolvedores.

O trabalho que ainda resta pode ser mostrado na unidade preferencial da equipe, que usualmente são Story Points. Sua finalidade é permitir que o projeto esteja no caminho para entregar a solução esperada dentro do cronograma desejado.

O Burndown não é obrigatório de forma alguma. Ele é apenas uma ferramenta para visualizar o progresso no projeto e no Sprint, e esse progresso é que deve ser medido obrigatoriamente. O ideal é que o SM meça isso diariamente.

A equipe pode escolher o método que quiser, inclusive outros tipos de gráficos ou outras métricas, desde que haja uma forma consistente de inspecionar o progresso do produto.

Product Increment: as funcionalidades ou entregáveis

Ao encerrar o primeiro Sprint de um projeto, a equipe Scrum precisa, mesmo que de forma rudimentar, resolver o problema do usuário final. Daí vem o conceito de MVP (Minimum Viable Product – Mínimo Produto Viável, em tradução livre).

O MVP é muito utilizado no mundo do empreendimento e das startups, já que a maioria dessas pequenas empresas inovadoras surge justamente com um MVP.

A grande diferença do Scrum para o Cascata está nesse conceito, já que as iterações têm por base entregar incrementos do produto ao longo do tempo. Isso é contrário ao paradigma antigo onde havia uma única grande entrega ao final do projeto.

Para que o Sprint termine com sucesso, é necessário que seu objetivo tenha sido atingido. Esse objetivo é definido pela equipe e geralmente envolve a entrega de pelo menos um incremento de software que esteja funcionando.

Por isso é que “incremento”, “entregável” e “funcionalidade” acabam sendo palavras intercambiáveis nesse contexto. O incremento precisa ser validado pelos analistas de testes e pelo PO para que seja incorporado ao produto final.

Imagem: Henrik Kniberg

Eventos Scrum

Os Eventos são usados no Scrum para criar regularidade e minimizar a necessidade de reuniões imprevistas. Todos os eventos são timeboxed, o que significa que eles têm um tempo mínimo e um tempo máximo de duração.

Todos os Eventos são ligados ao Sprint, que é o principal deles, e todos se repetem cada vez que um Sprint acaba e outro começa. Daí a natureza iterativa do Scrum.

Antes do Sprint começar, idealmente na primeira Sprint Planning do projeto, sua duração é fixada pelo Scrum Master. Ela não pode ser reduzida ou aumentada.

Os eventos restantes também têm timeboxes mas podem terminar antes do previsto caso o objetivo proposto para cada um deles for alcançado mais rápido. Assim há garantia que uma quantidade apropriada de tempo seja gasta sem permitir desperdício no processo. Os Eventos Scrum são:

Sprint Planning: o planejamento

Antes de iniciar um Sprint, o Product Owner apresenta para o Scrum Master e para os desenvolvedores os itens mais prioritários do Product Backlog. O time seleciona os itens que farão parte do Sprint Backlog.

Depois disso, o SM e o PO se retiram da reunião para que o time “dev” defina tecnicamente como serão desenvolvidos os itens do Sprint Backlog. Essa definição é auxiliada pelo Planning Poker, que veremos mais à frente no artigo. Essas são as duas etapas do Sprint Planning.

Durante a primeira etapa, o Product Owner apresenta os itens do Product Backlog sob a ótica de negócios, mostrando o raciocínio utilizado por ele para definir quais itens têm maior prioridade. O time pode tirar dúvidas com o PO e já idealizar quais são as possíveis soluções técnicas para cada item, uma vez que esses itens formarão o Sprint Backlog.

Após formado o Sprint Backlog, a equipe Scrum completa irá definir um objetivo para o Sprint, descrevendo de forma sucinta o que o time deve ter como foco para essa iteração.

Já durante a segunda etapa, os desenvolvedores se reúnem para que possam traçar o planejamento técnico de cada item do Sprint Backlog. Cada item é quebrado em tarefas menores ou transformado em User Stories caso necessário. Estima-se o tempo que será despendido neles. Essa estimativa geralmente é feita com o Planning Poker.

A análise da efetividade do Sprint Planning acontecerá no Sprint Review.

É importante que os membros da equipe lembrem-se de qualquer folga, período de férias, feriados, viagens, ou qualquer outro detalhe de programação que ocorrerá durante o Sprint e que possa afetar o seu andamento. Assim, poderão estimar com a maior precisão possível qual será a quantidade de trabalho realizada.

Planning Poker: o jogo e suas regras

Equipes que utilizam Story Points também costumam usar um exercício parecido com um jogo de pôquer. As cartas de baralho são utilizadas para estimar o esforço que será despendido em cada tarefa.

A equipe de desenvolvedores pegará um item do backlog e discutirá brevemente sobre ele. Cada um dos integrantes pensará em uma quantidade de Story Points que considera adequada para a execução dele. Todos pegam e mostram aos demais uma carta de baralho com o número equivalente à sua estimativa.

Se todos estiverem de acordo, o exercício acaba aqui. Se houver discordância, cada desenvolvedor deve entender a lógica por trás das diferentes estimativas.

A estimativa deve ser uma atividade de alto nível. Isso significa que as discordâncias não podem ser muito gritantes. Se alguns membros estimaram 1 Story Point enquanto outros estimaram 5, conversem mais um pouco, até que esses números se aproximem.

A equipe deve ter um consenso sobre o número máximo de Story Points, horas de trabalho, ou qualquer que seja a medida escolhida pelos integrantes.

As Sprint Retrospectives são o momento do time refletir sobre a precisão e eficácia de iterações anteriores daquele projeto. Essa reflexão inclui a precisão de suas estimativas.

O Quão Preciso é Preciso Ser?

Em uma sessão de Planning Poker, imagine que metade da equipe estimou 3 Story Points e a outra metade estimou 5 Story Points para uma História.

É fácil aceitar 4 Story Points como a estimativa e seguir para a próxima tarefa, mas a equipe deve ter sinergia e maturidade suficientes para entender que não é produtivo fazer isso. Isso só gera uma falsa sensação de precisão. Não há necessidade de ser 100% preciso. O que é necessário é ser preciso o suficiente para garantir o bom andamento do Sprint e planejar tudo com antecedência.

Além disso, pode haver perda de transparência no processo caso a decisão mais fácil seja tomada. Essa decisão gera uma diminuição na comunicação do time. Talvez 5 Story Points seja uma estimativa melhor e vocês nunca saberão se não conversarem sobre isso.

Sprint e seus Estados (To Do, Doing, Done)

Um Sprint é um ciclo com começo e fim, com uma duração de tempo pré-determinada pelo Scrum Master. O Sprint é o centro do Scrum. Todos os outros eventos e artefatos giram em torno dele e da sua execução.

Ao final de cada Sprint, há uma nova funcionalidade a ser validada ou barrada pelo Product Owner. Depois, implementada em definitivo ou modificada até que fique dentro das regras e valores de negócio propostos por ele.

A Duração dos Sprints

O SM precisa analisar a estabilidade dos escopos de produto e de projeto antes de definir a duração dos Sprints. Se um deles for muito mutável e essas mudanças estiverem relacionadas a tempo de entrega, é mais prudente que os Sprints tenham uma ou duas semanas de duração. Se os recursos disponíveis aos escopos são mais estáveis, Sprints de duas a quatro semanas podem funcionar melhor.

Como já mencionado neste artigo, não é comum e nem recomendável que os Sprints de um projeto variem de tamanho, pois isso gera instabilidade e imprevisibilidade na velocidade de execução do mesmo.

O Sprint termina quando o tempo de duração definido para ele se esgotar ou quando o objetivo definido durante o Sprint Planning for atingido. Para que o Sprint termine com sucesso, é necessário que haja entrega de um incremento de software.

Durante o Sprint, cada tarefa tem um estado. Esse estado serve para indicar a que pé está sua execução.

Estados do Sprint

Algo comum, e semelhante ao que é feito no Kanban, é dividir as tarefas do Sprint por colunas em um quadro físico ou virtual. Cada uma delas equivale ao estado de um cartão. Esse cartão transita pelas colunas à medida que o que está descrito nele é implementado. Os Estados mais comuns são:

  • Backlog. Designa o Product Backlog.
  • Blocked (Bloqueado). Contém tarefas que não poderão ser inseridas em To Do por algum impedimento.
  • To Do (Por Fazer). Designa o Sprint Backlog.
  • Doing ou Work in Progress (Fazendo). Lista tarefas que estão sendo feitas, com indicação do desenvolvedor responsável por fazê-las em cada cartão.
  • Verify (Verificar). Onde estão as tarefas já desenvolvidas que precisam ser testadas.
  • Done (Feito ou Pronto). São tarefas já concluídas.

Os Estados obrigatórios são apenas To Do, Doing e Done.

Para que todos os stakeholders estejam alinhados sobre o que significa a conclusão de uma tarefa, existe um documento chamado Definition of Done (Definição de Pronto). Nele há a descrição genérica de quais são os passos mínimos para a conclusão de entregáveis.

Esse documento é como uma garantia da qualidade dos incrementos. Ele pode ser modificado ao longo das iterações, à medida que é revisado em cada Sprint Review.

É obrigatório que todos os stakeholders estejam de acordo com a Definição de Pronto para que haja transparência e confiança entre eles durante o projeto.

Daily Scrum: as reuniões diárias

Todos os dias, a equipe se reúne para conversar sobre o andamento do Sprint atual. O objetivo aqui é promover o alinhamento contínuo entre todos os membros do time e ajudar o Scrum Master a prever o que poderá realmente ser entregue ao final do Sprint.

Essa reunião diária é chamada de Daily Scrum ou apenas Daily. Ela costuma durar por volta de 15 minutos. Pode ser estendida com membros específicos do time dependendo do que for conversado e de possíveis impedimentos que podem surgir.

A participação do time completo é obrigatória. Para esse evento, isso sempre inclui o Scrum Master mas nem sempre o Product Owner. A participação de outros stakeholders, como os gerentes de outros setores ou o cliente, é menos comum mas pode ocorrer, porém eles serão apenas ouvintes.

A Daily não deve se aprofundar em discussões técnicas. Qualquer questão que surja durante ela deve ser estendida apenas com os membros diretamente envolvidos ou afetados por essa questão. Se necessário, o que foi discutido nessa etapa é passado de forma resumida para os membros que não estavam envolvidos.

As questões que devem ser respondidas pelos desenvolvedores na Daily, assim reportando seu progresso ao Scrum Master, são:

  • “O que eu fiz ontem” ou “o que eu fiz desde a última Daily”;
  • “O que pretendo fazer hoje” ou “o que pretendo fazer até a próxima Daily”; e
  • “Existem os seguintes impedimentos para que eu possa concluir minhas tarefas” ou “não existem impedimentos para as minhas tarefas”.

Tendo em conta o que foi respondido, o Scrum Master deve trabalhar para eliminar os impedimentos. Caso eles não existam, deve trabalhar para que o que ainda falta nesse Sprint seja concluído com qualidade e dentro do prazo.

Sprint Review: revisando o ciclo

Após o final do Sprint, o time mostra como aconteceu o desenvolvimento dos entregáveis. Normalmente estão presentes no Sprint Review o Product Owner, o Scrum Master e o cliente ou os stakeholders que o representam. O foco da reunião é demonstrar as novas funcionalidades com o mínimo possível de bugs e funcionando relativamente bem. O ideal é que a duração do Review não seja maior do que duas horas.

Os incrementos devem ser revisados de acordo com o objetivo do Sprint que foi acordado no Sprint Planning. A equipe deve sempre se esforçar para alcançar esse objetivo.

Sprint Retrospective: refletir para melhorar

O último Evento Scrum é a Retrospectiva. A equipe analisa o rendimento do Sprint que acabou e conversa sobre maneiras de melhorar seus processos de trabalho para o próximo Sprint. Há discussão e exposição de dificuldades e como a equipe acha que pode evitá-las.

Isso está relacionado com alguns fatores. São eles:

  • empenho de cada desenvolvedor,
  • divisão de tarefas feita no Sprint Planning,
  • e os impedimentos apontados na Daily, além das decisões do SM para resolvê-los.

A equipe decide como agir dali em diante para melhorar sua eficiência no próximo Sprint. Os integrantes devem visar o aumento da sua produtividade sem perda de qualidade.

Assim como a Daily, a Retrospectiva também tem uma duração ideal. Nesse caso é de uma hora, mas os envolvidos em alguma questão mais complexa podem continuar conversando após a reunião.

Uma das técnicas de Retrospectiva é o start-stop-continue:

  • “Devemos começar a fazer…” (start)
  • “Devemos parar de fazer…” (stop)
  • “Devemos continuar a fazer…” (continue)
Imagem: Blog Europneumaq

Scrum of Scrums: a solução para projetos grandes

Scrum of Scrums ou Meta Scrum é um mecanismo de escalabilidade criado na IDX Systems (atual GE Healthcare).

É definido pela Agile Alliance como “uma técnica para escalar Scrum até grandes grupos (mais de uma dúzia de pessoas), consistindo em dividir os grupos em equipes ágeis de 5 a 10 integrantes”.

Ainda, é definido por Jeff Sutherland como “responsável por adequar o software de todas as equipes à Definição de Pronto no final do Sprint, ou a lançamentos durante o Sprint”. Quando trabalhavam na IDX, Jeff Sutherland e Ken Schwaber implementaram-no como uma técnica para dimensionar equipes Scrum individuais para o nível corporativo.

O Gerenciamento de um Scrum of Scrums

A coordenação das várias equipes é feita em uma reunião do Scrum of Scrums. Essa reunião pode ser realizada diariamente, duas vezes por semana ou, no mínimo, uma vez por semana.

Cada equipe Scrum tem seu representante. Ele pode ser o Scrum Master ou outro membro da equipe escolhido pelos outros integrantes. Se o assunto que uma das equipes quer discutir é muito técnico, tanto o membro da equipe tecnicamente qualificado quanto o Scrum Master podem querer participar.

A reunião do Scrum of Scrums é executada de forma muito semelhante à Daily Scrum. Apesar de não ter uma duração de tempo predeterminada, é comum que ela dure 15 minutos, assim como a Daily de Scrums comuns. Na reunião do Scrum of Scrums, cada “embaixador” de cada time Scrum deve responder:

  • O que sua equipe realizou desde a última reunião;
  • Quais problemas ocorreram (se ocorreram) e como afetaram negativamente sua equipe;
  • O que sua equipe deseja realizar antes da próxima reunião;
  • Quais ações da sua equipe em futuros Sprints podem interferir nos Sprints das outras equipes;
  • E se sua equipe vê alguma interferência proveniente de outras equipes.

O propósito da reunião do Scrum of Scrums é assegurar a coordenação e integração dos resultados das várias equipes, eliminando todos os impedimentos. Para isso, pode haver envolvimento de duas ou mais equipes trabalhando juntas por um tempo ou renegociando responsabilidades.

Isso precisa ser gerenciado com um Product Backlog próprio do Scrum of Scrums e mantido pelo Scrum Master eleito como chefe desse processo. Ou, ainda, por um Gerente de Projetos que tenha o Product Backlog do Scrum of Scrums como sua principal demanda.

Como Organizar o Scrum of Scrums

Um framework Scrum of Scrums pode ser eficaz mesmo em organizações maiores com múltiplas equipes. Ou em projetos com Scrums distribuídos em locais diferentes. Desde que as reuniões próprias dele sejam conduzidas adequadamente.

A ênfase deve estar na coordenação das várias equipes e na resolução de impedimentos. O objetivo é garantir que as equipes individuais cumpram suas metas. Assim, o objetivo geral do projeto de todas as equipes será atingido.

O desperdício de tempo, trabalho e recursos é diminuído ao máximo por um time formado especificamente para ajudar o Scrum Master ou Gerente de Projetos encarregado do Scrum of Scrums. Os membros são selecionados de cada Scrum ou são integrantes exclusivos.

Isso garante a manutenção da transparência e boa comunicação entre todas as equipes Scrum. Ken Schwaber chamou isso de Integration Scrum (Scrum de Integração) em seu livro The Enterprise and Scrum (“As Empresas e o Scrum”, em tradução livre). Ter pelo menos um lançamento a cada três meses é a meta.

Como implementar o Scrum na sua empresa

A implementação do Scrum tem muito a ver com a implementação da Transformação Digital. Além do Scrum ser uma ferramenta de Transformação Digital, ambos os processos dependem diretamente de mudanças na cultura organizacional.

Essas mudanças só podem ocorrer de forma efetiva se forem feitas gradualmente e com muito engajamento dos líderes da empresa e dos colaboradores. Os líderes sempre terão que balancear os prós e contras com transparência diante de suas equipes, visando integrar todos os setores da empresa.

Metodologias Ágeis para Organizações

O que acontece em implementações organizacionais de métodos ágeis não é o uso do Scrum propriamente dito, mas sim de frameworks modificados.

Eles também são baseados nos princípios do Manifesto Ágil, porém com essa integração de setores já considerada desde a sua concepção.

Um exemplo desses frameworks é o SAFe, que aborda todas as camadas de uma organização. Dean Leffingwell, o criador do SAFe, o define como “uma estrutura para implementar práticas ágeis em escala corporativa”.

Transição para o Scrum

A transição de tradicional para ágil deve ser cuidadosa e muito bem alinhada internamente. Assim como qualquer outra mudança de cultura organizacional, devido ao impacto que isso trará aos colaboradores.

As equipes de cada setor devem ser multidisciplinares. Os silos organizacionais devem ser diminuídos ao máximo para que a sinergia entre setores seja sempre priorizada.

Essa sinergia e multidisciplinaridade ajudarão na Agilidade, já que colaboradores proficientes em várias frentes poderão auxiliar uns aos outros e trazer visões diversas para a empresa.

É esperado que alguns dos colaboradores demonstrem resistência ao processo de transição. Aí é que se encaixa o papel principal dos líderes dos setores. Eles devem alinhar expectativas de forma sempre transparente e explicar quais serão as melhorias obtidas para cada setor com a implementação do Scrum – ou de qualquer outra metodologia ágil.

Saiba mais sobre o Scrum

Scrum – Aprenda Scrum em 9 minutos por Denisson Vieira

Scrum // Dicionário do Programador pelo canal Código Fonte TV

Scrum ou Kanban na Metodologia Ágil? – Beer For Devs (parte 2) pela TOTVS

Scrum – Metodologia Ágil: o que é e para que serve? por Mário Conde

Metodologias Ágeis – Scrum pelo canal Tu quer saber mais?

Scrum Cases de sucesso

O Scrum é uma das ferramentas que podem fazer parte da Transformação Digital. Por esse motivo, alguns dos cases de sucesso do Scrum foram citados no nosso artigo de Transformação Digital.

Dois dos cases mais simbólicos são o da GE Healthcare (antiga IDX Systems) e o do FBI. O case da GE foi citado na seção de Scrum of Scrums deste artigo. Ele está disponibilizado traduzido na íntegra aqui no nosso blog.

Na Zappts, os times de desenvolvimento são geridos com Scrum. Cada time é dedicado para cada projeto, não recebendo demandas de projetos paralelos. Isso garante a agilidade e o bom andamento dos Sprints. A qualidade das soluções que oferecemos aos clientes é assegurada dessa forma.

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

  

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…

  

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?

  

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!