Por Luciano Osorio – Scrum Master da Zappts
Tradução Livre e Adaptada do texto Original do ValueGlide, escrito por John Coleman.
Um grande banco europeu tinha várias equipes por produto que queriam uma alternativa ao Scrum, ao Kanban, ou ao Lean Startup.
As equipes queriam um padrão para esses métodos. Daí surgiu o Nexus+, que é igual ao framework Nexus mas com acréscimo do papel de Architecture Owner. O Nexus+ foi adotado como ferramenta de Transformação Digital nesse banco.
Em uma instância do Nexus+ nesse banco, haviam 5 equipes em um Nexus. Quatro equipes eram Scrum e uma equipe era Kanban. Um dos outros Nexus tinha três equipes: uma Lean Startup, uma Scrum, e uma Kanban.
O Escopo
A meta para os primeiros 6 a 12 meses da mudança para o uso do Nexus foi a entrega mais rápida. Em paralelo ocorria a retirada gradual do híbrido de Cascata/Scrum usado antes. Isso promoveu uma boa agilidade, sustentável e com propósito. O DevOps era a maior prioridade, vindo o Lean Finances em segundo. O objetivo em cada caso foi poder, mais tarde, focar no cliente e na inovação.
As pontuações DICE do Boston Consulting Group para prontidão para mudança desse banco só seriam verdes/amarelas se a meta de 6 meses fosse diluída ou se o escopo da organização fosse limitado.
Os colaboradores do banco começaram a visar melhores tempos e taxas de entrega com o objetivo de atrair mais clientes na onda de 6 a 12 meses de acompanhamento posterior.
O escopo foi de US$25 milhões em gasto aproximado.
Transição para o Nexus+e suas Instâncias
O Nexus era utilizado para ter Sprint Reviews mais ou menos mensais em todo o portfólio. As previsões eram feitas com simulações probabilísticas Monte Carlo para identificar “planos incríveis”.
Também houve desenvolvimento da capacidade interna. Quando houvesse corte de custos, a organização poderia continuar sua jornada de agilidade sem perder o ritmo.
Em uma das suas instâncias, o Nexus+ foi implementado com equipes distribuídas. As responsabilidades e metodologias de cada uma eram:
- Europa: infraestrutura (DevOps e automação de testes). Kanban com tempo estruturado de aprendizado.
- Europa: desenvolvimento da aplicação. Scrum.
- Índia: desenvolvimento de aplicação. Dois times Scrum.
- Estados Unidos: desenvolvimento de aplicação. Scrum.
Papéis e Desafios do Nexus+
O Architecture Owner é um papel importante, pois é responsável pelo fluxo do back end. No caso desse banco, o back end envolvia a autorização de cartões de crédito e débito.
As 5 equipes implementaram automação de testes e lançamentos mensais. Anteriormente, os lançamentos eram irregulares e impulsionados pela execução do projeto. Isso reduzia a previsibilidade e causava problemas de sequenciamento.
Por exemplo, se um projeto tivesse um componente com entrega atrasada, os projetos relacionados a ele precisavam reconsiderar e refazer seus testes. Isso permitia por volta de 6 a 10 lançamentos por ano.
Isso tudo foi feito em tecnologia antiga. Por esse motivo, houve necessidade de recorrer a testes automatizados de ponta a ponta, ao invés do TDD(Test Driven Development – desenvolvimento guiado por testes).
Todas as transações com cartões passavam pela tecnologia antiga. As equipes estavam alterando-a a cada mês utilizando DevOps.
As equipes possuíam um Product Owner disciplinado, um Architecture Owner orientado à agilidade, Scrum Masters apropriados, Scrum apropriado, Kanban apropriado. Isso eliminou o híbrido Cascata/Scrum rapidamente.
Há sempre novos desafios. Soluções causam novos problemas. Por exemplo, um desses desafios nessa instância do Nexus+ era a sincronização entre a costa oeste dos EUA e a Índia.
Desdobramentos
Apesar de todas as mudanças, a pressão dos órgãos reguladores e da diretoria foi grande. Com isso, a gerência recuou para o que eles sabem planejar em páginas, em gráficos de Gantt, e marcos imutáveis para os 6 meses seguintes.
Os marcos eram atingidos pela alteração do conteúdo da entrega. Ironicamente, embora essa “equipe de equipes” tenha argumentado contra os marcos, suas medições eram incrivelmente boas, com gráficos de queima de marcos (Burndown Charts).
O controle financeiro insatisfatório tornou difícil argumentar o caso do Agile. A diretoria achava que, se tivessem rastreado o custo em relação aos entregáveis, teria sido mais fácil mostrar valor (ou a falta dele). Era difícil para eles medir o valor de um sistema que a maioria das pessoas simplesmente considerava natural.
A realocação da equipe dos EUA para a Costa Oeste causou uma queda maciça na produtividade. Isso agravou o desafio da diferença de fusos horários. As pessoas na Europa e na Índia tiveram que se esforçar para tentar fazer a equipe dos EUA se sentir mais conectada.
Ferramentas de Mudança
As ferramentas de DevOps (com exceção da automação de testes) foram interrompidas devido à falta de financiamento, mas ainda continuam, como atividade paralela e conforme a equipe percebe o valor nelas.
O primeiro estágio será fazer build automaticamente a partir do Git usando o Jenkins para dar push no código para a plataforma NonStop. Já que não há um cliente NonStop Git adequado, com o build sendo executado pelo Jenkins usando macros (de uma linguagem para scripts bem antiga, chamada TACL) já existentes.
O retrabalho de testes usando o VersaTest produziu um pacote de testes muito mais preciso, com melhor cobertura. Os testes agora são limpos e, embora não sejam automatizados, basta pressionar uma tecla para rodá-los.
No geral, o saldo foi positivo. Nos 6 meses seguintes, houve implementação de builds automáticas. As métricas utilizadas sobre o que realmente pode ser fornecido pelo desenvolvimento são decentes. As equipes na Índia tiveram bons resultados.
Conclusão
A paixão, foco e energia dessas pessoas foi o que moveu a equipe. O Nexus foi um trampolim para o LeSS. É necessário mais suporte para as Feature Teams e a Teoria Y é necessária para essa próxima etapa.
Convenientemente, quando a mudança estava chegando à diretoria, houve resistência. Os colaboradores já estão saindo de lá e indo para outras empresas. Empresas que não tenham resistência às metodologias ágeis.
Não há melhora se a diretoria não compreender isso.