“La curiosidad es una de las más permanentes y seguras características de una vigorosa inteligencia”

Samuel Johnson

Uno de mis próximos objetivos, no se si para lo que queda de año, o ya par el año que viene, es adquirir más conocimiento en algún marco de escalado, formarme y certificarme, para poder ponerlo en práctica bien (de antemano, siento el post tan largo, espero que os resulte interesante o de utilidad, tenía la necesidad de dejarlo plasmado e ir profundizando más).

A día de hoy tengo conocimientos de lo que yo he ido buscando, aprendiendo, de forma autodidacta, pero si bien es cierto, prefiero aprender de profesionales que tengan experiencia y certificados en ellos.

Hoy traigo este post porque tengo dudas de en qué certificarme. Y explico por qué. Pienso que a día de hoy el que más posibilidades tiene en el mundo empresarial, lo que más se pide y más se está implantando es SAFe, pero realmente no estoy segura de que sea el mejor marco.

También es cierto que depende de la organización, el proyecto, etc., quizá cuadra unos más que otros. Por eso tengo la duda.

Este post me va a servir para echar un vistazo rápido de los diferentes marcos de escalado agile, en cuál puedo llegar a creer más, si alguno en concreto me interesa más o me parece más curioso o me puede aportar, escribiré un post a parte con más detalle.

Así que bueno, en el título del post, podéis ver los marcos en los que estoy interesada, tengo conocimientos básicos en alguno de ellos, pero no quería dejar la oportunidad de también conocer algo del resto de marcos para así tomar una elección más inteligente.

También decir, que no soy experta, esta información es lo que he ido investigando, por lo que, si hay algo que no está bien, o no está en lo cierto, también agradecería que me lo comentaseis, aunque intento que la info que busco sea lo más oficial posible.

Y también de lo que busco iré dejando como comentarios y mi opinión personal, para ver si puedo ir decantándome. Lo iré dejando en otro color para diferenciarlo bien.

Así que vamos a ello:

LeSS

LeSS viene de Large-Scale Scrum (scrum a gran escala).

A priori, por el título tiene buena pinta.

LeSS es un framework para el desarrollo de producto creado por Craig Larman y Bas Vodde en 2005 trabajando juntos en Nokia Siemens Networks aplicando Agile y scrum al desarrollo de productos muy grandes en múltiples sitios. Dentro de las opciones de escalado ágil, es un marco muy flexible con un coste de implantación bajo, y muy acoplado a Scrum. 

El método LeSS busca reducir la metodología Scrum a sus niveles básicos, para poder expandirlos a diferentes equipos. Es decir, se toma Scrum y se lo resume a su nivel básico, luego se integran nuevos equipos (uno a la vez), que serán coordinados por el mismo Product Owner.

No se yo, en mi opinión, varios equipos y un solo PO no sé hasta qué punto puede ser bueno

Cada equipo responderá al mismo Product Backlog, y si bien funcionará de forma autónoma (con sprints propios), también compartirá ciertos hitos del proyecto, para llevar sprints sincronizados. Estarán juntos en:

• Planificación del sprint o Sprint Planning.
• Revisión del sprint o Sprint Review.
• Sprint Retrospective.

Cuando estuve en otra empresa, hacíamos algo similar, pero era como un súper PO que organizaba el PB y POs por equipo. Y también tiraban del mismo PB pero claro, estaba gestionado y organizado entre todos los POs. Creo que puede funcionar, evidentemente compartiendo tiempos e hitos, para una mayor eficiencia.

Puede ser una buena opción, aunque también sé que esto es muy muy básico, por detrás hay una profundidad importante. Si tengo que saber algo más para tomar la decisión y decantarme por este o no, por favor, recomendarme =).

En resumen: LeSS mantiene el núcleo de Scrum intacto: exponer las debilidades del diseño organizativo a través de un marco mínimo y permitirle resolver los complejos problemas inherentes al desarrollo, a través del control empírico del proceso y la mejora continua.

LeSS trata de aplicar los «principios, el propósito, los elementos y la elegancia de Scrum en un contexto a gran escala, de la forma más sencilla posible. 

En un post, me dedicaré más específicamente a este marco, hablando de reglas y principios.

Nexus

Nexus es la propuesta del creador de Scrum, Ken Schwaber, junto con el equipo de Scrum.org para escalar Scrum usando Scrum

La guía oficial de Nexus lo define como una Unidad de desarrollo. Si en Scrum la unidad son los equipos Scrum, en el caso de Nexus la unidad se compone de 3 a 9 equipos Scrum junto con un equipo de integración Nexus trabajando en un unido Product Backlog, que integra su trabajo al final de cada Sprint.

Nexus es una palabra inglesa que se traduce como una relación o conexión entre personas o cosas, y da nombre a este marco metodológico que consiste en roles, eventos, artefactos y las reglas que los unen, al igual que la definición de Scrum.

Básicamente Nexus, es un Scrum a escala: Si un Scrum Team lo forman entre 3 y 9 personas, un Nexus lo forman entre 3 y 9 equipos Scrum. Además se añaden:

• 1 rol nuevo: el NIT(Nexus Integration Team)
• 1 artefacto nuevo: Nexus Sprint Backlog,
• 4 eventos nuevos: Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Reviewy Nexus Sprint Retrospective, 

Principalmente, la manera de abordar las dependencias y la integración del trabajo es a través del NIT, que se reúne en el Nexus Daily Scrum previo al Daily Scrum de cada equipo, con el fin de llevar a estos las acciones necesarias para conseguir progresar hacia el Incremento Integrado

No se vosotros, pero puedo llegar a ver, a priori y con los conocimientos básicos, cierto parecido con LeSS. La verdad que Nexus es el marco que hasta ahora, he conocido y que más creo y me cuadra.

En otro post más adelante, igual que para LeSS también escribiré algo más concreto y detallado, ya que me parece interesante este marco.

En resumen, Nexus sigue la misma filosofía de Scrum: Escalar mientras se entrega Software debe ser un proceso orgánico, en el que se eliminan impedimentos al mismo tiempo que se miden las limitaciones que permiten seguir creciendo. 

SAFe

Como ya he comentado, veo que este marco es el más usado en las empresas, y que veo en ofertas que piden o deseables conocimientos en SAFe. Pero este marco es el que a mi me crea dudas. Veamos cositas.

Scaled Agile Framework® (SAFe®) es un conjunto de patrones de organización y flujo de trabajo que sirve para implementar prácticas ágiles a escala empresarial. El marco constituye un cúmulo de conocimientos que incluye instrucciones estructuradas sobre las funciones y responsabilidades, la forma de planificar y gestionar el trabajo, y los valores que hay que defender.

Dean Leffingwell y Drew Jemilo publicaron SAFe en 2011 para ayudar a las organizaciones a diseñar sistemas y software superiores que satisfagan mejor las necesidades cambiantes de los clientes.

Por lo que veo, es el marco que más se enfoca en el mundo empresarial, y no tanto, o al menos eso parece en scrum. Quizá por eso sea lo más pedido en las ofertas de trabajo.

Scaled Agile, Inc. proporciona una hoja de ruta de implementación de SAFe que contiene pasos detallados sobre cómo empezar y configurar la organización para su adopción generalizada en todas las carteras. 

Se estructura en tres niveles que abarcan desde la planificación estratégica (portfolio) hasta el nivel de ejecución (equipos). Los tres niveles de arriba abajo son:

• Portafolio
• Programa
• Equipo

Cada uno de los niveles implican un conjunto de roles, eventos y artefactos propios que permiten que se coordine la acción de todos los niveles en cascada.

Por lo que he leído, me sigue sin convencer, pero voy a escribir un post más detallado de este a ver el atractivo para las empresas y si consigo empatizar más con este marco. También creo que si es lo que más se pide en lo profesional, voy a tener que empaparme de ello.

Scrum of Scrums

Jeff Sutherland y Ken Schwaber, dos pioneros del marco de scrum, implementaron la metodología de scrum de scrums por primera vez en 1996. Tanto Sutherland como Schwaber necesitaban dar con una forma de coordinar ocho unidades empresariales con múltiples líneas de productos cada una y de sincronizar equipos individuales entre ellos.

Por tanto, probaron una forma nueva de escalar los equipos de scrum para alcanzar su objetivo. La experiencia inspiró a Sutherland a publicar un artículo en 2001 titulado “La metodología ágil se puede escalar: invención y reinvención de scrum en cinco empresas“, en el que menciona el scrum de scrums por primera vez públicamente.

Trata de una técnica para usar Scrum de forma escalada cuando varios equipos trabajan en un único producto o una familia de productos única.

Un scrum de scrums consiste en un equipo virtual compuesto por delegados con enlaces integrados en los equipos de entrega de origen. Al contrario de las jerarquías organizativas habituales y los equipos basados en proyectos, estas estructuras de equipos interconectados reducen las vías de comunicación. La finalidad es coordinar equipos independientes más pequeños.

Según puedo ver, el foco en scrum de scrums está en la comunicación y reducir el número de vías de comunicación. Pero también se parece considerablemente a los dos primeros marcos bajo mi punto de vista, sin entrar en profundidad.

También entiendo que el objetivo de todos es el mismo, de ahí que encuentre similitudes, y que cada uno pone foco en algo en concreto que ven importante, y luego roles y reuniones es lo que también puede variar.

Este escalado me interesa, también sacaré un post detallado, para ver en profundidad y poder comparar bien con respecto a los anteriores. La verdad que este me resulta especialmente útil por quién fue creado, los mismos que scrum, así que ls valores y principios serán los mismos

Scrum at Scale

Scrum@Scale se desarrolló a partir de una iniciativa conjunta entre Scrum Inc. y la Scrum Alliance bajo la batuta del Dr. Jeff Sutherland, uno de los creadores de la metodología scrum y coautor del Manifiesto para el desarrollo ágil de software. Scrum@Scale se basa en los fundamentos de la metodología scrum y en la teoría de los sistemas adaptativos complejos.

  Creo que al ser algo creado por dos entidades me resulta menos interesante investigar, aunque sean dos entidades prestigiosas y certificadoras en este mundo.

El marco Scrum@Scale se basa en tres conceptos fundamentales:

• Equipos pequeños
• Escalado en toda la organización
• Aplicación de la burocracia mínima viable

Se logra una estructura de escalado mediante el uso del concepto de scrum de scrums, en el que varios equipos entregan al final de cada sprint un conjunto totalmente integrado de incrementos de productos que se puedan lanzar.

Al final parte de scrum of scrums, así que prefiero centrarme en el anterior a no ser que alguien me diga que investigue más.

DAD

Conocido como Disciplined Agile Delivery o simplemente Disciplined Agile es uno de los frameworks para escalar la agilidad que más está creciendo y gracias, entre otras, a su capacidad de adaptación a casi cualquier supuesto.

Esto hay que verlo bien…

Una de las bases principales de Disciplined Agile es no decir qué es lo que tienes que hacer, sino dejarte a ti, a tu empresa, a tus circunstancias la opción de elegir qué quieres o qué puedes aplicar. Esto no significa que Disciplined Agile no te recomiende unas opciones antes que otras, pero lo hace como un consejo, no como una obligación de lo que tienes o no que utilizar. 

Tienen pinta de ser algo más abierto y adaptable, pero esto me da la sensación de que puede derivar en que cada uno haga lo que le de la gana

Disciplined Agile define un ciclo de vida completo. Cuando digo completo es que el ciclo de vida recoge desde la idea inicial del proyecto hasta la entrega a los usuarios finales con el entorno y todo lo necesario. Este ciclo de vida completo se alcanza dividiendo los proyectos en 3 macro fases o bloques:

• Inception. Donde queda recogida la concepción del proyecto. Tareas previas como la formación del equipo, obtener el presupuesto, definir los riesgos principales, etc.
• Construction. Sería el desarrollo propio del Proyecto. Esta fase sería la que coincidiría con la definición de Scrum.
• Transition. Puesta en producción del proyecto, la entrega.

Interesante e importante que tenga en cuenta desde el inicio del proyecto. Profundizaré más par saber más tema roles, estructura…

Conclusión

Necesito más información específica de cada uno de ellos, creo que los que más me gustan son Less, Nexus y scrum of scrums. ¿Vosotros qué me decís? Cada vez se hace más difícil coger conocimiento, aprender, con tantas cosas. Siento que somos aprendices de todo y maestros de nada y no sé hasta que punto puede ser bueno.

Cuando escriba un post de cada uno de ellos, entraré a temas de certificaciones, precios, etc. Además de un cuadro comparativo más detallado, especificando roles, estructura, eventos, artefactos, objetivos…

Terminando…

También quería aprovechar este post para hacer un llamamiento y pedir recomendaciones, sugerencias, opiniones, comentarios sobre esto. Desde vuestra experiencia, qué me recomendáis.

Este año me estoy centrando más en inglés ya que creo que es muy importante hoy día y me estaba quedando un poco atrás, pero ya me estoy replanteando esto que os digo, así que vuestras recomendaciones son bienvenidas.

Además del inglés, también me certifiqué de Management 3.0 así que este año cumplí con mis objetivos de aprendizajes, y economía dedicada a ello (además de un curso de nutrición, que no tiene que ver con esto, pero quería aprender más) por eso me estoy replanteando si que entre en este año o para el año que viene mejor. Pero de lo que si que estoy segura es que quería empezar a moverme ya porque creo que hay mucho por donde tirar, y no es una decisión que tomar a la ligera.

Podéis escribirme a través de comentarios o bien por mail, o por dónde queráis, estaré encanta de leerlos.

¡Feliz miércoles!