Se comparte en esta presentación el framework Nexus y retos que conlleva al usarlo como estrategia de escalar scrum, Uno de estos riesgos es la generción de deuda técnica.

1. por: Jorge H. Abad L – jorge.abad@gmail.com
twitter@jorge_abad –
blog: www.lecciones-aprendidas.info
Nexus – El Exoesqueleto para Escalar Scrum y
la Deuda Técnica

2. Mis objetivos con esta sesión:
- Compartir sobre Nexus
- Elevar nuestro nivel de
conciencia sobre la deuda
técnica

4. Esto no es del todo mío, se basa en crecer sobre el compartir
 Presentación esta basada en las
diapositivas de mi amigo
Lucho Salazar @LuchoSalazarC
 Blog:
http://www.gazafatonarioit.com/

5. A planes más largos, mayores serán los supuestos y
mayores los riesgos. No permitas que la incertidumbre
te gobierne
@ourfounder

11. Historias de la vida real
¿Cuál de los siguientes procesos de software estás usando en
tu organización?
• Lean (Software Development)
• Kanban
• DevOps
• SAFe
• DAD
• LeSS
• eXtreme Programming
• Scrum

12. Historias de la vida real
¿Has estado involucrado en esfuerzos para escalar Scrum?
Levanta la mano si tu organización define ‘escalar’ como:
• Múltiples equipos trabajando en un producto
• Múltiples equipos trabajando en sus productos individuales
• Múltiples equipos trabajando en una suite de productos
integrados
• Un equipo trabajando en varios productos en paralelo
• Toda la organización TI adoptando Scrum
• Una transformación organizacional de 180º hacia Ágil

13. Historias de la vida real
¿Has estado involucrado en esfuerzos para escalar Scrum?
Levanta la mano si tu organización define ‘escalar’ como:
• Múltiples equipos trabajando en un producto
• Múltiples equipos trabajando en sus productos individuales
• Múltiples equipos trabajando en una suite de productos
integrados
• Un equipo trabajando en varios productos en paralelo
• Toda la organización TI adoptando Scrum
• Una transformación organizacional de 180º hacia Ágil

14. Scrum: diseñado para la complejidad
• Fomentar la creatividad
de las personas
• Controlar el riesgo
(Time-Boxing)
• Permitir el aprendizaje
validado
• Dirigido por metas
• Exitoso en el
descubrimiento
• Entrega de valor
• Un entorno delimitado
para la acción

15. DNA de Scrum
Autoorganización
• Los componentes de un
sistema interactuando con
un único propósito hacia
una meta compartida,
evitando cualquier poder
externo
Empirismo
• Las decisiones frecuentes
de adaptación se basan en
el conocimiento ganado vía
la inspección y la
experiencia

16. SIN EMBARGO…

17. ¿Qué tal si empezamos haciendo Scrum antes de
intentar escalarlo?

18. La Esencia de Scrum
1. Un equipo saca
trabajo de una
Lista de
Producto
2. Cada Sprint
entrega un
Incremento
distribuible del
producto
Incrementos
Equipo Scrum
Lista de
Producto

19. Definición de Scrum a Escala
• Cualquier implementación de Scrum
donde múltiples Equipos Scrum
construyen un producto o un
conjunto de características de un
producto en uno o más Sprints.
• Cualquier implementación de
Scrum donde múltiples Equipos
Scrum construyen múltiples
productos relacionados o
conjuntos de características de
productos en uno o más Sprints.

20. La Esencia de Scrum
1. Un producto
tiene una Lista
de Producto
manejado por un
Dueño de
Producto
2. Múltiples
Equipos crean
Incrementos
integrados
Lista de
Producto
Equipos Scrum
Incrementos (Integrados)

21. ¿Cuáles son tus mayores obstáculos al
escalar Scrum, implementar Scrum a
gran escala?
Los desafíos de escalar Scrum

22. La integración del trabajo (o la ausencia de ella)
Código pobremente mantenido produce
EL EFECTO MEDUSA

23. Un Equipo Scrum Haciendo el Trabajo
Lista de
Producto

24. Algunos Equipos Scrum Haciendo el Trabajo
Lista de
Producto

25. Lista de
Producto
Muchos Equipos Scrum Haciendo el Trabajo

27. Tu habilidad de escalar depende de tu habilidad para:
– Manejar dependencias
– Integrar el trabajo en todos los niveles
– Crear Incrementos integrados
continuamente

29. Pausa…
Despues volveremos sobre lo de la deuda tecnica

30. Nexus
Scrum Profesional a Escala
“Un hombre que toma un gato por la cola
aprende algo que no puede aprender de otra
forma”.
- Mark Twain

31. Nexus
–noun
ˈnek-səs
: a relationship or connection between people or things
http://www.merriam-webster.com/dictionary/nexus

33. ¿3-9 Equipos Construyendo un Producto? ¡Ayuda!
Incrementos (Integrados)
Equipos Scrum
Lista de
Producto

34. Nexus™ – Un Exoesqueleto para 3-9 Equipos Scrum

35. Identifica y trabaja alrededor
de las dependencias:
 Antes de que se haga el trabajo
 Continuo
 Persistente
 En todas las dimensiones
Revela dependencias que
permanecen desapercibidas:
 Integración Frecuente
 Pruebas de aceptación
 Compilación y entrega continua
 Reduce la deuda técnica
Diseñado para Manejar Dependencias
Proactivo Reificación*
*Reificación:
Hacer que algo se vuelva real o hacer
que algo abstracto se vuelva concreto

36. Nexus Aumenta Scrum
Construido sobre los principios, valores y fundamentos de Scrum
 Crea rutas de comunicación
 Extiende y profundiza los mecanismos de inspección y adaptación
 Fomenta la transparencia continuada
 Depende en la inteligencia hacia arriba
Evita soluciones fijas y definidas que agregan sobrecostos.

37. Nexus - Roles, Eventos y Artefactos
Roles Eventos Artefactos
Equipos de Desarrollo El Sprint Lista de Producto
El Equipo de Integración
Nexus*
Planificación del Sprint
Nexus*
Lista de Pendientes del Sprint
Nexus*
Dueño de Producto Planificación del Sprint Lista de Pendientes del Sprint
Scrum Master Scrum Diario Nexus* Incremento Integrado
Scrum Diario
Revisión del Sprint*
Revisión del Sprint
Retrospectiva del Sprint
Nexus**Específico de Nexus

38. El Equipo de Integración Nexus
 Un Equipo Scrum
 Trabaja con la Lista de Producto
 Los Miembros están tiempo
completo o medio tiempo
 Su composición puede cambiar
entre Sprints
 Se enfoca en las dependencias y en
la facilitación de la integración

39. Scrum Diario Nexus
• ¿El trabajo del día anterior fue integrado
exitosamente? Si no fue así, ¿por qué
no?
• ¿Cuáles nuevas dependencias han sido
identificadas?
• ¿Qué información necesita compartirse
entre los equipos del Nexus?

40. Prácticas de Scrum Profesional a Escala
Dependencias Reificación
Equipos de Características Automatización de artefactos ALM
Micro-servicios Desarrollo conducido por pruebas
Metadatos de la Lista de Producto Integración continua de todo el trabajo
Refinamiento continuo de la Lista de Producto Compilaciones frecuentes
Story mapping Pruebas Frecuentes
Mapeo de dependencias entre equipo de la Lista de
Producto
Limited branching
Comunidades de práctica Descaling and Scrumble
La Arquitectura contiene experimentación Porciones de los elementos de la Lista de
Producto componen los Pendientes del Sprint
para ATDD

41. Desescalar
 Escale con precaución
 Adicione prácticas o herramientas
 Reduzca el paso total, disminuyendo el
número de equipos a un número más
sostenible (o la velocidad)
 Limpie e integre el software actual
para que se pueda compilar sobre él
en futuros Sprints
Velocidad
Equipos

42. Scrumble
 Cuando la deuda técnica, el
conocimiento del dominio y los
resultados de las pruebas abrumen el
progreso, haga ‘Scrumble’
 Scrumble es un periodo de duración
desconocida y de reclutamiento de
personal cuando se trabaja para lograr
que el progreso se reinicie
 El reclutamiento debería minimizarse y el
talento aplicado maximizado
Equipos
Velocidad

43. Nexus interconecta 3-9 Equipos Scrum que:
– Exhiban los principios y el DNA de Scrum
–Creen un Incremento de producto reificado
– Reduzcan sobrecostos, maximicen resultados

46. Volvamos al tema de la Deuda Técnica

48. Indaguemos

49. La deuda técnica son
las consecuencias de un
desarrollo apresurado
de software o un
despliegue descuidado
de hardware.
Wikipedia

51. La deuda técnica son las consecuencias de:
• un desarrollo apresurado
• un desarrollo inconsciente de software
• o un despliegue descuidado de hardware
Que se terminará pagando ya sea con:
• baja velocidad de desarrollo
• inversión de tiempo removiéndola o
• bajo rendimiento del sistema
@jorge_abad

57. ¿Quienes han estado en
un Proyecto que fue
cancelado debido a que
era más práctico iniciar
de cero que continuar
trabajando en el?

62. ¿Y CÓMO LUCE?

64. Nuestro servidor agotado por :
• La carga
• Necesita continuos reinicios
• Carecemos de
• buen hardware
• Software liviano adecuado
para el hardware
• Software bien construido
(por lo general las últimas dos)

66. Ejemplos

79. ¿Algún ejemplo más?

80.  Presiones de Negocio
 Poco entendimiento del proceso
 Software no modular, clases muy acopladas
 Falta de una buena suite de pruebas
 Falta de documentación
 Falta de colaboración entre equipos
 Falta de acompañamiento a desarrolladores jóvenes
 Desarrollo paralelo (en dos o más branches)
 Postergar la refactorización
 Inexistencia de estándares o no alineación con ellos
 Poco conocimiento por parte del desarrollador de buenas prácticas
 Poca apropiación del código
 Pobre liderazgo técnico
 Subutilización del software base
 Sobreutilización del software base
 Presiones por cambios de último minuto
 Entre otros
Causas

82. Síntomas
 Despliegue lentos
 Constantes reinicios del servidor por consumo de
memoria
 Código inmantenible
 Código inestable o con el síndrome de castillo de
naipes
 Toco aquí y daño allá
 No sé donde tocar
 Tengo miedo a tocar
 Costo alto de cambios
 Costo alto de corrección de código
 Disminución de la velocidad de los sprints
 Entre otros

84. Efectos

87. Deuda técnica a ser pagada

93. Process Debt
Methodology Debt

106. Prácticas Técnicas compartidas por todo el
equipo
• Revisiones de código
• Pruebas de Aceptación
• Pruebas Unitarias
• Propiedad Colectiva de Código
• Clean Code
• Test Driven Development
• Integración Continua
• Entrega Continua (Continuous Delivery)
• Diseño Simple
• Programación por pares
• Mob Programming
• Estándares de codificación
• Refáctoring
• Monitoreo de la deuda técnica

109. Como resolverla

110. Como resolverla

113. Cerrando

114. Qué nos ha enseñado la experiencia

115. Qué nos ha enseñado la experiencia
Colaboración
Entrega de
Valor
(Temprana, continua
y con excelencia
técnica)
Adaptación
al Cambio
Mejora
Continua
– Alistair Cockburn
Maximice el
“Corazón de Ágil”

116. Qué nos ha enseñado la experiencia

117. Qué nos ha enseñado la experiencia

118. Qué nos ha enseñado la experiencia

119. Donde No hay
• Ni compromisos
• Ni planes
• Ni métricas
• Ni Arquitectura
• Ni ingenieria
AGILE NO es desarrollo hippie

121. PREGUNTAS

122. Sobre el material utilizado
 Esta presentación se basa en el trabajo de Guther Verheyen (@Ulizee) y otras personas de Scrum.org
 Adicional en
– Lucho Salazar @LuchoSalazarC
– Javier Garzas @jgarzas
– Ángel Nuñez @snahider
 Además de las referencias explícitas, esta presentación puede contener material o ideas de otras
personas u organizaciones que omití sin intención.
 Nota: Trate de dar crédito a todos, pero si consideras que faltaste por que no te
referencié o debo modificar algo de tu propiedad, por favor, no dudes en hacérmelo
saber, contactándome a: Jorge.abad@gmail.com

123. Aviso de Copyright
 Eres libre de:
– Compartir- copiar, distribuir y transmitir este trabajo
– Modificar- adaptar el trabajo
 Bajo las siguientes condiciones
– Atribución: debes atribuir el trabajo en la manera especificada por el autor o
licenciante (pero de ninguna manera que sugiera que ellos aprueban su uso del
trabajo).
 Nada de lo dispuesto en esta licencia menoscaba o
restringe los derechos morales del autor.
 Para más información ver http://creativecommons.org/licenses/by/3.0/

124. Información de contacto
 Jorge Hernán Abad Londoño
–Jorge.abad@gmail.com