¿El framework SAFe® es a una compañía ágil como Scrum a un equipo ágil?

Big picture con la versión 3.0 del framework
cortesía de ScaledAgileFramework.com

Había oído, y hasta hace poco tenía la creencia, de que SAFe® (Scaled Agile Framework®) es un framework que está concebido para absorber la jerarquía de una gran compañía y así poder vender un producto dirigido a hacer negocio con las grandes compañías. Por otro lado había oído de la rigidez del modelo, que ciertamente se basaba en principios ágiles, pero que en conjunto no era un modelo muy ágil.

Recientemente me certifiqué como como SAFe Program Consultant y he adquirido una perspectiva algo distinta. SAFe se basa en principios ágiles, en Lean y en tres niveles de abstracción, cada uno sobre los principios del Manifiesto Ágil, así como cada uno con su pila de producto, niveles a coordinar entre sí para implantarlo en una gran compañía:

• Equipo: pila de producto a nivel de historias de usuario.
• Programa (con su ART, un equipo de equipos de entre 50-120 personas): pila de producto a nivel de funcionalidad.
• Portfolio: pila de producto a nivel de epics provenientes de una lista de temas estratégicos.

Mirando el modelo en el big picture podemos ver que el compromiso de Scrum en no variar la pila de sprint, se traduce en el modelo SAFe en el compromiso de no variar la suma de pilas de sprint de un incremento de programa (PI). Eso implica cierta rigidez, pero tiene todo el sentido, cuando hablamos de una gran compañía todo es a lo grande, el producto de software que pueda necesitar, como puede ser un software de gestión crediticia para una banco, es un software muy extenso. Por tanto el modelo es algo menos ágil en ciclos tan cortos como un sprint, ya que lo ha de ser cada 4 o 5 sprints, en equilibrio con el tamaño del producto. Resaltar que el tamaño del PI lo definimos nosotros y por tanto podemos ser más ágiles si en vez de PIs trimestrales hacemos PIs más cortos.

La idea de un framework para absorber la jerarquía de directivos y mandos intermedios no es correcta. Es cierto que SAFe implica una jerarquía, pero de roles, cada uno con sus responsabilidades independientes, con líderes participativos y al servicio orientados a personas que se dedican a mejorar el sistema, organizar, hacer de apoyo y desarrollar a sus equipos, fomentando la creatividad y la colaboración. Lo que vemos en el big picture son roles, ni títulos ni cargos.

A nivel de programa encontramos roles ágiles como:

• System Team
• Product Manager
• System Architect
• Release Train Engineer (RTE)
• UX and Shared Resources
• Release Management Team

Y por supuesto es posible que mandos anteriores, las personas, puedan hacerse cargo de estos roles del framework, pero para ello han de pasar por un cambio cultural hacía la Agilidad, basado en el Manifiesto Ágil; algunos tendrán la actitud apropiada, otros no y si no la adquieren no tendrán cabida en el nuevo modelo.

SAFe funciona porque toma un enfoque holístico y crea partnership entre la dirección y los equipos. Los equipos no están controlados por la dirección, y esta no tiene la única función de eliminación de los impedimentos, sino el foco en el verdadero pensamiento sistémico y desarrollo de las personas de la compañía.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

¿Cómo crecer e incorporar nuevos equipos en compañías maduras en Scrum?

Hace unos días participé en un curso de SAFe® (Scaled Agile Framework), y mientras tomábamos el café estuvimos hablando sobre cómo incorporar nuevos miembros y equipos a una compañía ágil. La idea es crear huecos en los equipos existentes sacando un miembro de cada uno de ellos para formar con estos un equipo nuevo, para después incorporar en esos huecos nuevos miembros. De esta manera el impacto de estos nuevos miembros se mitiga y el aprendizaje y adaptación a la compañía se maximiza. El nuevo miembro se encuentra directamente situado en un equipo con amplia base de conocimiento y que conoce perfectamente el marco con el que trabaja la compañía, por tanto su curva de aprendizaje está maximizada. Una vez rodados se puede volver a componer los equipos originales, quedando el equipo nuevo perfectamente adaptado e integrado en la compañía.

Sala con varios equipos trabajando en un mismo producto
a modo de Agile Release Train

En nuestro entorno TI en España, dónde impera la subcontratación de equipos y proyectos a consultoras, este sistema permite absorber y formar rápidamente a los equipos nuevos, a la vez que filtra a "miembros de equipo" que no tienen cabida en Scrum. Me refiero a jefes de proyecto y gerentes desconocedores de Scrum y que en ocasiones se pueden ver sentados junto a "sus" equipos, y que bajo la perspectiva ágil resultan en verdaderos impedimentos, sobre todo para la autoorganización y autogestión del equipo. El hecho de mezclar personas de diferentes consultoras en un equipo tiene por tanto una parte positiva, eso sí, sólo funciona si la compañía cliente es ágil y lidera el desarrollo de sus productos.

Yo era reacio a la creación de equipos por personas de diferentes consultoras, yo lo había vivido bajo una perspectiva waterfall. Lo que acabó ocurriendo es que se formaron 3 jerarquías con intereses diferentes, lo que resultó en un verdadero caos: jerarquía del cliente hacía los externos que están en sus dependencias, jerarquía de la propia consultora y jerarquía interconsultoras. Siempre ocurre que hay consultoras con más peso o más ambición que intentan destacar y crean muros entre las personas de diferentes consultoras. Bajo la perspectiva de Scrum, la solución de equipos con personas de diferentes consultoras, conocedoras y practicantes de los valores ágiles, es una solución que funciona, y resulta muy compacta a interferencias exteriores. Añadir que no deben de existir diferencias entre personas de diferentes consultoras, ni entre externos e internos, y se debe de velar por la continuidad y motivación de todos ellos.

Mis agradecimientos a Marc Florit por darme esta nueva perspectiva de equipos multiconsultora :-)

¿Cómo gestionar en un marco ágil la mantenibilidad del software cuando hay rotación de miembros en el equipo?

Esta pregunta viene de un alumno que tiene un equipo dedicado al mantenimiento de un producto que se dedica a incidencias y pequeñas mejoras, equipo que tiene rotación y la compañía parte de la idea de que el mantenimiento no debe depender de una persona, debe poder hacerla cualquier persona que se vaya incorporando en el equipo.

La única ley de la naturaleza que aplica a la informática es la entropía, si no se dedican recursos, y no me refiero sólo a personas, específicamente a la mantenibilidad del producto, y este está pensado para operar a largo plazo, lo más probable es que se vuelva caótico. El problema de no tener un equipo propietario a cargo del producto es que la persona nueva no tiene sentimiento de propiedad de un código que no es suyo, y la persona que lo escribió ya no está, y si tuviera que hacer una modificación habrá perdido el sentimiento de propiedad porque ya no es suyo, su código original lo han modificado otros.

Hay que hacer gestión de cambio de personas:

Taller de transmisión de conocimiento facilitado por el coach ágil

• Más que nunca es necesario un Scrum Master o un coach ágil que forme y acompañe a los nuevos miembros en la incorporación al equipo, y al equipo a integrarlos.
• Cuidando del bus factor para mantener la base de conocimiento en todo el equipo. Se pueden realizar talleres de transmisión de conocimiento entre la gente del equipo, programación por parejas, actividades medio lúdicas de team-buidling... con cada persona que rote, con cada salida y cada incorporación, hay que hacer acciones que mantengan la motivación del equipo.

Hay que invertir en todo aquello que facilite la mantenibilidad:

Aplicar técnicas de desarrollo ágil
- cortesía de Raúl Herranz

• Tener una documentación del diseño del producto mínima y suficiente, y sobre todo mantenible. Crear una base de patrones de desarrollo y documentación en el código, desde dentro y para el equipo. Algo que sea fácil de hacer y usar, por ejemplo una wiki. Para ello hay que crear cultura wiki, el equipo ha sentir que la wiki es una herramienta para ellos, y que se sientan proactivos a enriquecerla continuamente.
• Refactorización frecuente, hacer que el equipo en curso revise el código crítico y refactorice si lo cree conveniente. Así se consigue sentimiento de propiedad mientras el equipo sea estable.
• Stop-and-fix, para los workarounds y problemas que surjan parar completamente el desarrollo, para que el equipo resuelva completamente la causa raíz y luego, una vez resuelta, siga desarrollando. Evitar caer en paliativos y en chapuzas, futuros miembros del equipo las desconocerán y el problema se convertirá en una bola de nieve.
• Si se adquiere deuda técnica, gestionarla, apuntar cada deuda en un post-it y dejarlo bien visible en algún área del scrumboard. De tanto en tanto hay que abordar una de estas tareas. 
• Situar un banner bien grande y visible con mensajes como "NO QUEREMOS CODIGO BASURA" y hacer partícipe al equipo en la motivación de mejorar el código cada vez que les parezca que algo no esté suficientemente bien.
• Implantar integración continua y pruebas automatizadas, ir a máximos, a BDD.

Todo esto sin duda tiene costes, pero no hacer nada tiene un coste mucho mayor. He vivido equipos que adquieren deuda técnica y se acaban ahogando en ella simplemente porque el software sobre el que trabajan está lleno de chapuzas y workarounds. En la naturaleza del ser humano está el síndrome de la ventana rota, si entramos en una habitación con una ventana rota no nos importa que se rompan otras cosas. Un vidrio roto transmite una idea de deterioro, desinterés, despreocupación que va destruyendo los códigos de convivencia, tales como la ausencia de ley, de normas, de reglas, dejando la sensación de que todo vale nada. Lo mismo pasa con el software, cuando te encuentras código basura generas código basura...

Quiero dar mi agradecimiento a los asistentes al curso que me dieron permiso para utilizar la foto del taller de transmisión de conocimiento, entre ellos Ovidio, Marcos, Antonio, Daniel y Patricia.

¿Realmente un Scrum Master está comprometido?

¡El Scrum Master es un cerdo!
caricatura cortesía de pixabay

Esta pregunta la realizó un alumno de un curso on-line después de estudiar los roles de Scrum y conocer la parábola del cerdo y la gallina. Decía que no entendía porqué el Scrum Master es un "cerdo" cuando su foco central es Scrum y no el proyecto/producto.

La idea de que el Scrum Master no esté comprometido no es correcta, tiene que estar totalmente comprometido con su objetivo, con su responsabilidad, que es la de acompañar a los equipos y a la compañía en la correcta implementación de Scrum.

El Scrum Master no está comprometido directamente con el producto/proyecto, su objetivo no es directamente el éxito del proyecto, sino en el cómo el equipo de desarrollo está construyendo asegurando que aplica Scrum y es capaz de entregar de forma continua valor al cliente, que tome las decisiones de la forma más ágil posible y estas sean guiadas por valor de negocio, y también que está aplicando sentido común. Usualmente un Scrum Master tiene capacidad para acompañar a 3 equipos, su foco es el equipo y Scrum, no los proyectos que haya detrás. Una persona con foco en un proyecto pierde de vista la perspectiva desde fuera, y justamente esta es la que necesita un Scrum Master.

Resaltar que el Scrum Master no es una figura de metodología que encorseta a los demás, el Scrum Master acompaña al equipo a encontrar sus propias soluciones para la entrega continua de valor, no hay nada más productivo que ajustar los procesos desde dentro, desde el equipo. Es un guía, alguien que les escucha y por el que se sienten acompañados. Los "procesos" y/o "prácticas" las explicita el equipo una vez que las cosas funcionan y hayan llegado a la madurez.

Para ilustrar el nivel de compromiso del Scrum Master podemos imaginarnos en la situación en que un project manager nos da 5 tareas y se nos pega al hombro para preguntarnos una y otra vez como vamos, además de repriorizar las tareas un par de veces, ¿os suena esa situación? Y en esa situación ¿cuántas veces hemos pensado que ojalá nos diese las 5 tareas y nos dejase organizarnos a nuestra manera, no nos molestase y que de esta forma haríamos un buen trabajo en la mitad de tiempo? Llevar a equipos enteros hacía esa autoorganización que expresa nuestro deseo es parte del compromiso del Scrum Master. Acompaña al equipo para que tome y crea en sus propias decisiones, que se sienta libre de incluir las historias que honestamente crea capaz de poder hacer dentro del sprint para que finalmente se sienta comprometido a construir las historias de la pila de sprint. A modo de analogía podríamos decir que es el aceite que hace que el motor ruede.

Para resumir; como parte del equipo ágil o equipo Scrum, la responsabilidad máxima de los tres roles, Scrum Master, Propietario del Producto y equipo de desarrollo es la entrega continua de valor, por tanto los tres roles son roles comprometidos o "cerdos".

Parábola del cerdo (comprometido) y la gallina (involucrada)

¿Hay alguna técnica de retrospectiva que permita ver de forma evolutiva las mejoras?

Actualmente estamos probando la técnica evolutiva basada en el decremento del valor de la retrospectiva Estrella de Mar de Patrick Kua, con una pequeña variación, hemos incorporado los agradecimientos. Los post-its se colocan de forma gradual y a lo largo del proyecto en un tablero, que registra e incorpora las mejoras en un flujo de valor desde su puesta en marcha hasta su retirada. Según el valor, cada mejora se sitúa en el área correspondiente, cuando se propone tiene un alto valor, luego va cambiando de área a medida que pierde valor hasta que finalmente, cuando deja de aportar valor, se retira. Como vemos es una técnica guiada por valor, una característica fundamental de la Agilidad. 

La técnica nos está dando buenos resultados y beneficios:

• El equipo se siente cómodo con la técnica, agradecen que sus aportaciones no solo se limiten al blanco y negro.
• Nos focaliza en aquello que enriquece y contribuye a la mejora continua.
• Se ve claramente el grado de madurez de cada práctica/mejora introducida.
• Nos permite retirar de forma consensuada todo aquello que ya no aporta.
• Permite ver la evolución del producto/proyecto en base a la resolución de problemas.
• Nos da una muy buena perspectiva visual de la salud del producto/proyecto.

Nuestro tablero modificado tiene un área central para los agradecimientos:

Tablero Estrella de Mar

Agradecimientos: cada miembro del equipo agradece a través de un post-it a otro miembro la ayuda o colaboración desinteresada recibida, generando motivación en el equipo y team-building.

Alrededor de los agradecimientos hay cinco áreas más para colocar los post-its en forma de flujo de valor. Colocamos "seguir haciendo" en la parte superior para lanzar un punto de partida en positivo y evitar centrarnos en lo negativo:

Empezar a hacer: área que da la entrada a cosas totalmente nuevas, innovaciones creativas, incluso disruptivas que vienen a ser experimentos por los que apostamos. Entrañan riesgo por su novedad y nuestra inexperiencia.

Más de esto: para ideas que aporten valor y mejora, refinamiento de alguna práctica existente y pruebas de cosas sobre las que el equipo quiera poner el foco.

Seguir haciendo: vienen a ser aquellas cosas que se encuentran bien afianzadas, que actualmente gustan al equipo y que de seguir haciendo aportan valor tal como se hacen.

Tablero Estrella de Mar
en el último sprint del proyecto

Menos de esto: son aquellas cosas que quizá se hayan de refinar o que ya no tengan la utilidad esperada, el equipo ya no está contento con ellas y no son útiles en nuestro escenario actual.

Parar de hacer: cosas que no aportan ningún valor al marco de trabajo del equipo, cosas que hasta pueden ser bloqueantes y se quieran eliminar.

A la derecha muestro el tablero 5 sprints después, justo en el último sprint del proyecto. Es interesante hacer una lectura de en lo que ha evolucionado el tablero dentro del marco de un proyecto cerrado. Podemos distinguir el área "seguir haciendo" con prácticas bien afianzadas, el área "dejar de hacer" con bastantes cosas que fueron mejoras que ya están implementadas y por tanto obsoletas, y sorprendentemente el área de "agradecimientos" desierta. Cuando le pregunté al equipo sobre el porqué, la respuesta fue con tono jocoso y de buen rollo "donde hay confianza da asco"... están totalmente integrados y conscientes del final del proyecto ya no sienten la utilidad ni necesidad de dar agradecimientos.

Cuando los equipos ya son maduros y las retrospectivas son un hábito para ellos, estos están motivados e implicados y en más de una ocasión me cuentan: "cuando me pongo a escribir los post-its para la retrospectiva todos me salen en positivo". :-)

Quiero dar mis agradecimiento a Alberto por colaborar en esta técnica.

¿Qué tipo de retrospectiva hacer al finalizar un curso o un evento?

Estuve haciendo co-trainig con Marcos Garrido y me ha gustado mucho su forma de hacer la retrospectiva a final de curso. La idea trata no sólo de obtener feedback del curso, sino de que los propios alumnos se lleven lo que sea esencial para ellos. Pronto me di cuenta de que esta técnica es aplicable a cualquier evento en el que haya transmisión de conocimiento. El tablero propuesto tiene 4 áreas:

Tablero con 4 áreas

• Sentimientos
• Aprendido
• Desafíos
• Plan de acción

Cada alumno escribe 1 post-it por área y los coloca en el área correspondiente.

Nuestro tablero de retrospectiva

Sentimientos: La primera área es para recoger feedback de los alumnos y ocurre a través de lo emocional, desde la experiencia que estos han vivido. Aparecen sentimientos como satisfacción, ganas de aplicar lo aprendido, smileys sonrientes así como smileys tristes...

Las otras tres áreas son para el alumno, están pensadas en forma de flujo para que guíen al alumno hacía la implantación en su día a día profesional de algunas de las técnicas aprendidas.

Aprendido: En primer lugar el alumno hace inventario de lo aprendido y expone lo que más le interesa o lo que más importante le parece.

Desafíos: En segundo lugar proyecta ese conocimiento nuevo a su trabajo e identifica dónde hay retos y desafíos para la implantación de lo aprendido y que considera interesante.

Plan de acción: Una vez asumidos los retos y desafíos el alumno identifica qué técnica aprendida querría aplicar y dónde, de forma que a modo de PNL se lleva un plan de acción consigo.

Mis agradecimientos a Marcos por su técnica y por todo lo aprendido a su lado :-)