Estos dos últimos días he asistido al curso de Jerónimo Palacios (@giropa832), que podéis encontrar aquí https://jeronimopalacios.com/training/scaled-professional-scrum/
Después de la charla que di en la CAS2016, Jerónimo me propuso que fuera a una de sus formaciones para que viera la posición oficial de Scrum.org y me pareció muy buena idea: seguro que algo aprendería. Mi visión de la agilidad es muy libre, y tomo de cada metodología y el sentido común lo que creo más razonable, y no está mal ver otros planteamientos más “corporativos”.
Dentro de las recomendaciones de la formación, proponía llevar los deberes hechos habiendo leído la guía de Nexus (os recomiendo que visitéis también los Whitepapers). Realmente son 12 hojas, y en principio tenía dudas de lo que podría dar de sí un curso de 2 días completos.
Ya os tengo que adelantar que ha merecido claramente la pena. Sobre todo porque, adicionalmente a la guía en el curso, se presentan un montón de prácticas complementarias (voy a mezclar una cosa con la otra en el resumen). Lo que se trata de diferenciar es el núcleo de Nexus de la otras prácticas.
También he de decir que en el curso había gente muy avanzada en Agile de otras empresas, que ya estaban experimentando con Nexus y tenían dudas concretas. Las conversaciones han sido muy enriquecedoras y amplias, no solo relacionadas con escalado de Agile: modelos de formación de empresas, frustraciones a la hora de ayudar a implantar Agile, diferencia entre Scrum y gestión del cambio organizacional, etc. A un curso también se va a conocer otra gente interesante.
Como siempre, adelanto la frase “vemos la vida como somos, no como es” por lo que voy a contar un conjunto de cosas que me han gustado. No sé si seré del todo preciso respecto a lo que Nexus dice, ya que la capacidad de aprendizaje es limitada. Seguro que otra persona le podría sacar otro partido en base a su expertis: tendréis que ir porque esto son sólo unas pinceladas. Claramente, Jerónimo tiene un buen discurso en amplitud y profundidad (no está mal acordarnos de eso de “una comunidad de profesionales” valorando/validando el talento y conocimiento de compañeros).
————
Lo más destacado podría decir que es lo más evidente: hacer Scrum de verdad antes de escalar. Muchas organizaciones tienen al Product Owner ausente, es un delegado de un jefe controlador que luego le desautoriza, el Scrum Master está poco formado, hay poco conocimiento sobre técnicas de integración continua, los equipos no son cross-funcionales, hay poca auto-crítica en las retrospectivas, etc. Parece lógico que para escalar hay que partir de una buena base. Las empresas se empeñan en meter Scrum en sus estructuras de poder, cuando lo que hay que hacer es cambiar la estructura.
Hay que formar a toda la organización y si el CEO/área financiera o área de compras tienen formación, no se producirán desajustes.
Nexus sigue los principios de Scrum, con más de 2 equipos. Con dos parece razonable seguir usando Scrum.
En Nexus hay un refinamiento como práctica formal al principio, donde se define un único back-log para los distintos equipos. El PO puede tener mucha carga de trabajo lo que no significa que tenga que estar solo. Tampoco significa que el Scrum Master tenga que estar recordándole constantemente cuál es su trabajo para que el equipo no se quede sin carga (volvemos a los del mal Scrum de base). Jerónimo recomendaba dejar que los niños se caigan a poca altura, y se tuviera que poner solución desde la dirección, para que no llegase a ser la altura demasiado elevada.
Otra cosa interesante de la que se habló es la de hacer responsable al PO de la rotación el equipo técnico (en parte). La rotación tiene un coste muy elevado. También se contó lo contrario, y como Jerónimo está recomendando a sus clientes el contratar equipos externos y si no son capaces de hacer entregas de valor, prescindir de ellos. Siempre que esto no sea una perversión, puede parece muy razonable para ganar capacidad y servir de muestra (a esto sí jugamos en Autentia).
Para definir las prioridades, parece razonable mapear un user-history-mapping con los objetivos de negocio. Los equipos tienen una capacidad y parece lógico hacer estimaciones rápidas para determinar la correlación entre el coste y el alineamiento con el objetivo. El modo de hacerlo me pareció simple y brillante simplemente poniendo los objetivos a la izquierda, como filas, de las épicas estimadas. Obviamente estamos a un nivel de detalle alto y esto tendría que repetirse a nivel de historias cuando se haya hecho un plan de releases.
Los miembros de los equipos se pueden auto-asignar al equipo más conveniente en base al valor que pueden aportar. Esto como siempre con cariño, para que estén equilibrados y pensando en lo mejor para el Nexus y no estar con los amiguitos.
La entrega de valor es una entrega integrada de todos los equipos. La duración del Sprint puede ser distinta en cada equipo pero deben ser múltiplos (uno puede ser de 2 y otro de 4 pero no de 3) para coincidir tanto en el refinamiento como en la revisión y retrospectiva del Nexus, independientemente de las prácticas del equipo. Esto suena muy razonable en organizaciones por componentes, que Nexus no condiciona a que no existan (por ejemplo con un host, eso de 2 velocidades).
Hay un Nexus Integration Team (NIT) que esta formado por el PO, SM y miembros de los distintos equipos cuya prioridad es entregar ese valor integrado. Tendrá funciones de coach, delegación y ejecución, según sea el caso.
Si no se produce una entrega de valor el NIT puede pasar a modo de emergencia. Esto significa subordinar el trabajo de los equipos a la integración. En el curso se habló varias veces de la fijación por hacer que la gente tenga ocupadas todas las horas. Pongamos un caso: si tenemos tres equipos y no somos capaces de integrar su trabajo en el ciclo ¿parecería lógico que los equipos siguieran construyendo para ocupar sus horas y complicar todavía más el ciclo de integración? Parece lógico bajar la “productividad” y automatizar la integración. Obviamente si integras con facilidad y no dispones de mecanismos de pruebas automáticas, esto de integrar más deprisa no vale para nada: no tienes red de seguridad.
Es importante mapear las dependencias entre historias y tareas. La integración es la clave por lo que visualizar las dependencias es fundamental.
En la reunión de revisión (esto aplica a Scrum en su amplio sentido), que normalmente mal llamamos de demostración, se debe hablar del incremento del proyecto y el PO también debe contar el estado actual del negocio, para que los equipos se alineen.
Fue divertido ejercer de CEO cuando los presente en el curso decían de hacer partícipes a la dirección de sus herramientas. Ya os adelanto que a la dirección le tienes que resumir la información y, a la vez, disponer del detalle si lo piden. Si no lo haces así, te pondrán una oficina de proyecto. Se hablaron de distintas técnicas de comunicación con Nexus de muchos equipos, como el modo feria de muestras, donde cada equipo contase sus avances. Esto que podría parecer una tontería puede ser muy útil para hacer conscientes a los equipos de las necesidades de no solo hacer, sino poner en valor el trabajo: saber venderlo en grandes organizaciones.
Las retrospectivas del Nexus se hacen en tres fases: NIT-equipo-NIT. Tienen como objetivo obtener feedback del incremento integrado. La auto-organización del individuo en Scrum se ve limitada por la de su equipo. En Nexus la auto-organización del equipo se ve limitada por la decisiones a nivel de NIT, por lo tanto también la de los miembros. Esto no significa que dentro de cada equipo no puedan tener sus propios mecanismos internos de retrospectiva o mejora.
A escala, los time boxes son relativos, no están definidos/limitados por la metodología Nexus.
Jerónimo dijo una frase muy interesante: «los desarrolladores deben dejar de amar su código y empezar a amar el valor aportado por ese código». Y esto no significa que el código no deba ser excepcional. Otra frase destacada para equipos que se enredan o pierden encadenando retos técnicos es “no hables en la reunión diaria si no puedes decir el incremento de valor que has entregado”.
Surgieron comentarios sobre empresas que con personal cualificado, interno y haciendo Scrum de verdad no tuvieron que escalar más equipos.
También hablamos de las estrellitas o héroes dentro de los equipos. Agilidad es que una empresa vaya a por un objetivo. Si se cambia la dirección, toda la organización se debe alinear al nuevo objetivo. Posiblemente en las organizaciones (por la oferta/demanda) se entre produciendo un alto paternalismo donde los programadores imponen hacer solo los que les gusta. Cada vez me encuentro más incluso que imponen las tecnologías o los días de la semana que quieren trabajar.
Una de las preguntas iniciales que planteé es si el Scrum Master es un rol a tiempo completo y cómo encaja en el Nexus, ¿uno por Nexus?, ¿uno por equipo?. Jerónimo insistió en que es el equipo o Nexus el que debería querer que el Scrum Master no se fuera. Además, le pagas por disponibilidad, para que cuando tengas una movida, esté allí. Es interesante mirarlo desde esta perspectiva.
Bueno, supongo que habréis percibido que hay chicha. Gracias Jerónimo por el curso, y estaré agradecido a todo el que me quiera invitar a uno suyo, me encanta ser un eterno aprendiz y tratar de compartir lo aprendido.
Visitaré su web porque comentó que estaban trabajando en su comunidad sobre el cambio organizacional, donde supongo que estamos todos de acuerdo en que todavía está más en la comunidad de ideas que en la de experto.
