Scrum Case

Por Luciano Osorio – Scrum Master en Zappts

Traducción Libre y Adaptada del texto Original del ValueGlide, escrito por John Coleman.

Un gran banco europeo tenía varios equipos por producto que querían una alternativa a Scrum, Kanban o Lean Startup.

Los equipos querían un estándar para estos métodos. Así surgiu el Nexus+, que es igual al framework Nexus pero con la adición del papel de Architecture Owner. Nexus+ fue adoptado como herramienta de Transformación Digital en este banco.

En una instancia de Nexus+ en este banco, había 5 equipos en un Nexus. Cuatro equipos eran Scrum y un equipo era Kanban. Uno de los otros Nexus tenía tres equipos: uno Lean Startup, uno Scrum y uno Kanban.

El Alcance

La meta para los primeros 6 a 12 meses de la transición al uso de Nexus fue la entrega más rápida. En paralelo, se producía la retirada gradual del híbrido Cascata/Scrum utilizado anteriormente. Esto promovió una buena agilidad, sostenible y con propósito. DevOps era la mayor prioridad, con Lean Finances en segundo lugar. El objetivo en cada caso fue poder, más tarde, enfocarse en el cliente y en la innovación.

Las puntuaciones DICE del Boston Consulting Group para la preparación para el cambio de este banco solo serían verdes/amarillas si la meta de 6 meses fuera diluida o si el alcance de la organización fuera limitado.

Los colaboradores del banco comenzaron a apuntar a mejores tiempos y tasas de entrega con el objetivo de atraer más clientes en la ola de 6 a 12 meses de seguimiento posterior.

El alcance fue de US$25 millones en gasto aproximado.

Transición a Nexus+ y sus Instancias

Nexus se utilizaba para tener Sprint Reviews más o menos mensuales en toda la cartera. Las predicciones se hacían con simulaciones probabilísticas Monte Carlo para identificar “planes increíbles”.

También hubo desarrollo de capacidad interna. Cuando hubiera recortes de costos, la organización podría continuar su jornada de agilidad sin perder el ritmo.

En una de sus instancias, Nexus+ fue implementado con equipos distribuidos. Las responsabilidades y metodologías de cada uno eran:

• Europa: infraestructura (DevOps y automatización de pruebas). Kanban con tiempo estructurado de aprendizaje.
• Europa: desarrollo de aplicaciones. Scrum.
• India: desarrollo de aplicaciones. Dos equipos Scrum.
• Estados Unidos: desarrollo de aplicaciones. Scrum.

Roles y Desafíos de Nexus+

El Architecture Owner es un papel importante, ya que es responsable del flujo del back end. En el caso de este banco, el back end involucraba la autorización de tarjetas de crédito y débito.

Los 5 equipos implementaron automatización de pruebas y lanzamientos mensuales. Anteriormente, los lanzamientos eran irregulares e impulsados por la ejecución del proyecto. Esto reducía la previsibilidad y causaba problemas de secuenciación.

Por ejemplo, si un proyecto tuviera un componente con entrega retrasada, los proyectos relacionados necesitaban reconsiderar y rehacer sus pruebas. Esto permitía alrededor de 6 a 10 lanzamientos por año.

Todo esto se hizo en tecnología legada. Por esta razón, hubo necesidad de recurrir a pruebas automatizados de extremo a extremo, en lugar de TDD (Test Driven Development – desarrollo guiado por pruebas).

Todas las transacciones con tarjetas pasaban por la tecnología legada. Los equipos la estaban cambiando cada mes utilizando DevOps.

Los equipos tenían un Product Owner disciplinado, un Architecture Owner orientado a la agilidad, Scrum Masters apropiados, Scrum apropiado, Kanban apropiado. Esto eliminó el híbrido Cascata/Scrum rápidamente.

Siempre hay nuevos desafíos. Las soluciones causan nuevos problemas. Por ejemplo, uno de los desafíos en esta instancia de Nexus+ era la sincronización entre la costa oeste de EE.UU. e India.

Resultados

A pesar de todos los cambios, la presión de los organismos reguladores y de la junta directiva fue significativa. Como resultado, la gerencia retrocedió a lo que saben – planificar en páginas, gráficos de Gantt e hitos inmutables para los próximos 6 meses.

Los hitos se alcanzaban alterando el contenido de las entregas. Irónicamente, aunque este “equipo de equipos” había argumentado contra los hitos, sus mediciones eran increíblemente buenas, con gráficos de quemado de hitos (Burndown Charts).

El control financiero insatisfactorio dificultó argumentar el caso del Agile. La junta creía que, si hubieran rastreado el costo en relación con los entregables, habría sido más fácil mostrar valor (o la falta de él). Les era difícil medir el valor de un sistema que la mayoría de las personas simplemente consideraban natural.

La reubicación del equipo de EE.UU. a la Costa Oeste causó una caída masiva en la productividad. Esto agravó el desafío de la diferencia de zonas horarias. Las personas en Europa e India tuvieron que esforzarse para intentar hacer que el equipo de EE.UU. se sintiera más conectado.

Herramientas de Cambio

Las herramientas de DevOps (con excepción de la automatización de pruebas) fueron interrumpidas debido a la falta de financiamiento, pero aún continúan como actividad paralela y conforme el equipo percibe el valor en ellas.

La primera etapa será hacer build automáticamente a partir de Git usando Jenkins para hacer push del código a la plataforma NonStop. Dado que no hay un cliente NonStop Git adecuado, con el build siendo ejecutado por Jenkins usando macros (de un lenguaje de scripts muy antiguo, llamado TACL) ya existentes.

El retrabajo de pruebas usando VersaTest produjo un paquete de pruebas mucho más preciso, con mejor cobertura. Las pruebas ahora son limpias y, aunque no son automatizadas, basta presionar un botón para ejecutarlas.

En general, el saldo fue positivo. En los 6 meses siguientes, se implementaron builds automáticos. Las métricas utilizadas sobre lo que realmente puede ser entregado por el desarrollo son decentes. Los equipos en India tuvieron buenos resultados.

Conclusión

La pasión, el enfoque y la energía de estas personas fue lo que movió al equipo. Nexus fue un trampolín hacia LeSS. Se necesita más apoyo para las Feature Teams y la Teoría Y es necesaria para esta siguiente etapa.

Convenientemente, cuando el cambio estaba llegando a la junta directiva, hubo resistencia. Los colaboradores ya están saliendo de allí e yendo a otras empresas. Empresas que no tengan resistencia a las metodologías ágiles.

No hay mejora si la junta directiva no comprende esto.