8 modelos para escalar Scrum y Ágil

Cuando una organización comienza a considerar el adoptar o escalar el marco de trabajo Scrum, se enfrenta a preguntas y desafíos, muchos de las cuales no conducen a conversaciones productivas o acuerdo entre las partes.

Un gran número de empresas ha crecido y madurado durante años en una red de interdependencias internas de estructuras sumamente complejas, y debido a ello, esperan que Scrum o su escalado posterior se ajuste a sus formas de trabajo.

magic-mirror

Un síntoma común de éstas es que piensen en Scrum únicamente como una ventana que permitirá el  incremento de la producción y su posterior escalado  a través del aumento del número de personas, procesos, fases, roles, etc. Ésto es en definitiva una forma de pensamiento que ha reinado por muchos años, y que principalmente deriva del  modelo Tayloriano y su paradigma de gerencia científica.

Está claro que una de las consultas más habituales se centra en buscar o seleccionar un marco de trabajo que pueda escalar y a su vez ayudar a las personas con lineamientos concisos para así comprender que hacer y como actuar. No obstante, este es un tema delicado ya que mucha dirección transformará el marco en un modelo prescriptivo (o lo que se denomina una metodología), limitando así las posibilidades de aprendizaje, evolución y adabilidad de la empresa, alejándola finalmente de la agilidad  (presta atención a la diferencia que hago entre marco de trabajo y metodología).

Un marco escalable efectivo debe ofrecer cierta guía inicial pero permitir a su vez a los equipos el cambiar su forma de trabajo tan pronto como encuentren otra que sea más efectiva, sustentable, y que apoye el descubrimiento,  aprendizaje continuo (o su primo hermano la innovación), las personas, la entrega de valor y la satisfacción de los clientes en el mediano y largo plazo.

medicióndeÉxito

 

Modelos, marcos de trabajo, metodologías y modelos para escalar Scrum.

Está claro que debe haber una mejora continua que haga posible una evolución de la organización poniendo siempre el énfasis en la simplificación y cambio hacia la auto-conciencia crítica de la compañía sobre sus procesos actuales, políticas, desperdicios y supuestos sobre sus empleados.

Cualquiera sea el marco o técnica elegida para comenzar con ágil o escalarlo tendrá que ajustarse a los desafíos únicos de cada equipo y empresa. Un modelo estricto o relativamente cerrado que estipule roles, procesos, fases, prácticas, etc., alejará a la organización de una adaptación y evolución progresiva, requisito necesario para encaminarse hacia la agilidad.

Las metodologías (formas prescriptivas), ofrecen un sentido de falsa seguridad en el corto plazo, lo que aumenta el riesgo y anula la evolución positiva en el mediano y largo, imposibilitando el acople de la empresa al universo de cambios continuos y profundos del mundo actual (ver mi artículo sobre SAFe).

En mi experiencia, este tipo de preferencias redimirá en conductas (o anti-patrones) que fijan formas de pensamiento (ver La cárcel psiquiátrica), lo que no ayudará a la organización a competir con empresas realmente ágiles

Existen dos puntos adicionales a prestar atención a la hora de elegir una forma de escalado: el marco de medición de avance a utilizar y la flexibilidad que se cuente cuando se encuentren entornos dispares. ¿Cómo sabrás si la compañía va en la dirección correcta a la hora de escalar Ágil?

relativity

La medición constituye un elemento activo fundamental que debe ser abordado correctamente. En los modelos más tradicionales, las mediciones de avance de implantación de marco de trabajo se realiza mediante hitos y políticas normalmente “invasivas”, que comúnmente exigen a los subordinados que brinden información sobre el avance, la que será posteriormente examinada y evaluada por los mandos gerenciales o área de metodología. Estos últimos como contrapartida tomarán decisiones que afectarán finalmente a los primeros.
Se puede apreciar entonces que la medición de avance y acciones se ejecutan en forma vertical.

En la agilidad, cada grupo cuenta con autonomía y es responsable por su propia mejora. Es entonces que los informes del avance del marco de trabajo o escalado se producen mayoritariamente de forma horizontal, esto es,  cada equipo se informa a si mismo sobre sus posibilidades de mejora y actúa en base a los resultados, pero sin perder de vista las dependencias, las cuales se expresarán en retroalimentación positiva hacia la organización.

¿Cómo medirás entonces si avanzas sobre terreno firme al escalar Scrum?

El segundo punto a considerar es la flexibilidad en entornos dispares. Es una realidad que muchas empresas cuentan con departamentos en diferentes partes del mundo. Los modelos más predictivos requieren normalmente de personas que sean capaces de enseñar cada una de las recetas de cocina de la metodología, formaciones interminables para llegar a ser un cinturón negro y sus posteriores cientos de certificaciones adicionales para así estandarizar sus procesos, cargos, y rutas de crecimiento personal de cada individuo dentro de la organización. Esto es lógicamente una restricción clara ya que aumentará exponencialmente el coste de la implementación del escalado y lo hará inviable en aquellos proyectos en sitios geográficos donde los presupuestos sean menores. Es así que la organización deberá apostar por modelos simples y evolutivos para conseguir un escalado sustentable y flexible.

Es por ello que es importante no caer en promesas de corto y mediano plazo y analizar realmente la problemática considerando diferentes aspectos que permitan mantener la flexibilidad, adaptación y orientación para las diferentes áreas de la empresa.

 

xsl

Comparativa de 8 modelos para escalar Ágil o similares en formato excel.

Visitar el sitio Agilescaling.org

 

Gracias por escucharme,
Erich.

3 thoughts on “8 modelos para escalar Scrum y Ágil”

  1. Hola Erich, un buen post sin duda, pero me quedan varias ideas en el aire respecto a dos cosas: 1. No comprendí el gráfico de Medición de éxito de los Modelos, marcos de trabajo, metodologías y modelos para escalar Scrum; la parte roja es buena o mala? y 2. El nivel de prescripción de los frameworks.

    Antes de hablar de escalamiento y eso, sólo centrémonos en Scrum. Qué es Scrum? Un framework. Este framework propone varios roles, una dinámica general, varias ceremonias y algunos artefactos, además de un grupo de valores y pilares. Un conjunto de elementos necesarios para trabajar ágilmente en busca crear mejores productos en un contexto de mucha incertidumbre. Algunos equipos y empresas lo usan tal cual, y varias lo personalizan en función de su contexto, negocio, aprendizaje, etc.

    Hablemos ahora de otro framework, por ejemplo SAFe. Posee varios roles, una dinámica general, varias ceremonias, algunos artefactos, algunas prácticas y un grupos de valores y principios. Conceptualmente, no hay diferencia con Scrum. Ambos son frameworks. Pero cada uno es más útil en diferentes niveles y contextos de la organización. De todos los casos de estudio de SAFe, no he visto un uso idéntico de empresa en empresa. De hecho, trabajo en una empresa donde lo estamos utilizando, y hemos eliminado cosas, modificado, agregado otras…personalizando en función del contexto, el aprendizaje, etc.

    La diferencia que marcas entre metodología y framework es correcta para mí. El nivel de flexibilidad o de seguimiento de la prescripción será evaluado y adaptado para cada empresa, cada realidad, cada contexto. Son sólo herramientas, el clave para lograr un escalamiento exitoso, es comprender y preservar los valores y principios que queremos escalar.

    En cuanto a medición de la “agilidad” de la compañía, estoy usando una variación del Agility Index con varios elementos relevantes para la organización. El propósito, desde el punto de vista organizacional, no es saber si todos están usando Scrum o TDD, o si lo están usando bien o mal. ASpectos relevantes al negocio, Time To Market, Satisfacción de Clientes, Motivación de Empleados, Calidad, etc.

    Me gusta el tema porque plantea una buena discusión y aclarar mal-entendimientos. Buen post!

    Like

  2. Gracias Johnny por tu comentario.
    Hay varias metáforas que se utilizan para describir una organización, muchas de las cuales, se vienen empleando desde hace ya años.
    Ágil y Scrum de alguna forma han deliberadamente seleccionado 2 de ellas para representar su forma de pensamiento:

    1. La metáfora de complejidad
    2. La metáfora de flujo y transformación

    La primera es la más usada e indica que las empresas son muy entidades complejas e imprevisibles, y debido a ello, lo que lo único que se pueden identificar son patrones, ya que las interacciones internas y externas hacen que las mismas no puedan ser controladas directamente. Cada cambio traerá consigo un conjunto infinito de repercusiones (o efectos) totalmente imprevisibles (he visto algunos comentarios tuyos al respecto, por lo que me consta que lo conoces).

    BCG institute realizó un estudio donde se puede ver que desde 1955 hasta ahora, la complejidad en las empresas se ha multiplicado por 6, y su nivel de complicación (roles, carreras, estructuras, coordinación, cadenas de control, etc.) por 35. De acuerdo a esta teoría y lo visto en este estudio, cada vez que se adiciona una nueva posición, role, departamento, etc., se está aumentando la complejidad de la empresa en vez de hacer lo contrario.
    Lo que en principio puede resultar una buena idea, termina incrementando la complejidad y complicación (y por ende burocracia), creando un círculo vicioso que hace que ella siga subiendo aún más y de forma infinita. Por ejemplo, lógicamente habrá que crear debido a las nuevas posiciones sus respectivas carreras, formas de evaluación, formas de comunicación, coordinación, etc.

    El único antídoto que se divisa de acuerdo a este paradigma es el hacer lo contrario, esto es, simplificar y eliminar roles, analizar las cadenas de poder y reducir todo aquello que se pueda a su mínimo de complejidad y complicación y brindar autonomía.

    La segunda metáfora es la de flujo y transformación, ella se toma en cuenta solamente cuando, por ejemplo, Scrum se introduce de forma orgánica, esto es, se va aplicando poco a poco.
    Esta forma de pensar indica que las empresas son como un remolino de agua donde hay fuerzas en todas las direcciones y en todo momento, pero el flujo continúa y se mueve en una dirección final estable. De acuerdo a ella, la empresa está siempre cambiando, día a día, y no existe el criterio de transformación. Lo único que se puede hacer es modificar un pequeño punto, el que desviará el rumbo en un unos grados, y de a poco, con muchos pequeños cambios, el agua modificará su rumbo. Lo importante de esta idea es que elimina el término de transformación ya que considera que la organización siempre cambia.

    Es entonces que nos enfrentamos a dos paradigmas complementarios.

    Scrum se ha focalizado en ofrecer el mínimo marco de trabajo posible, el más sencillo, y aboga por que este se mantenga así. Ágil también lo apoya ya que piensa que la simplicidad es aquello que no se hace. Debido a ellos, estos coinciden en revindicar la solución que la metáfora sobre complejidad aboga, la cual se basa en limitar para simplificar (no crear posiciones nuevas si hay una solución más sencilla y simplificar todo aquello que se pueda todo el tiempo). En el caso de Scrum se usan a su vez algunas herramientas, tales como la retrospectiva, las reuniones de día, etc. para segurar que todo se vaya simplificando.

    Por su parte SAFe hace lo contrario, si bien es opcional lo que se puede incluir, no aboga por simplificar las tareas, roles, cadenas de aprobación, coordinación o capas de la empresa, simplemente se centra en resolver un problema concreto sobre escalamiento. Ello lleva nuevamente y en el largo plazo a la trampa de la complejidad y complicación, que si bien parece una buena idea, termina no resolviendo el problema principal. Ahora bien, hay que tener cuidado ya que estos modelos en el corto plazo pueden ofrecer un efecto positivo.

    La flecha entonces indica en el lado rojo aquellas formas de trabajo que aumentan la complejidad y en verde las que abogan por su disminución (simplicidad).

    Algunos coaches tienen en cuenta el problema ya que conocen la idea, pero en aquellos lugares donde se espera una solución a través de una metodología y la creación de nuevos elementos, es difícil poder hacerlo, sino imposible.

    Finalmente, en muchos sitios donde se utiliza SAFe y por lo entrelazado del modelo como está planteado, los equipos no pueden cambiar su forma de trabajo, por ejemplo, un grupo que decida que no desea emplear Scrum ya que encontró otro método mejor de trabajo. Ello hace que aquellas partes que producen el valor para el cliente no se puedan optimizar de verdad, lo que frena la entrega de valor.

    Like

    1. Hola Erich, qué tal. Gracias por tu respuesta, muchos elementos valiosos. Estoy de acuerdo que entre más niveles y roles tiende a aumentar la burocracia. La complejidad que mencionas -y por ende la burocracia- es resultado de la multiplicidad de unidades estructurales en las que se agrupan los miembros de una organización. Herencia Taylorista, de acuerdo.

      Sin embargo, esta complejidad no es igual a la complejidad organizacional en el sentido de Pensamiento Complejo; es algo más allá a los roles y estructuras. Complejidad organizacional es el grado en el que una organización dinamiza o interactúa entre sus redes y reacciona frente a un conjunto de factores que en conjunto determinan su comportamiento. De esta forma, una organización es un Sistema Adaptativo Complejo (CAS), que pretende una estructura de gestión auto-organizada.

      De hecho, Scrum es un enfoque para trabajar en entornos complejos: varios factores que cambian constantemente y suman incertidumbre. La naturaleza del software es compleja. De la misma forma, hacer software a gran escala es algo complejo; cientos de factores adicionales que incrementan aún más la incertidumbre, el riesgo y presenta mayores desafíos de alinear a muchas personas, sincronizar el trabajo, velar por la calidad y la entrega de valor. SAFe y otros frameworks similares son más útiles en estos escenarios.

      No es del todo cierto que en SAFe los equipos no pueden cambiar su forma de trabajo, puedes usar Scrum, Scrumban, Kanban o enfoques personalizados (incluyendo normalmente prácticas de XP en todos). Lo importante en mantener el alineamiento y sincronización del trabajo que se va realizando en períodos cortos.

      De lo que he leído, SAFe no pretende transformar la estructura organizacional en su adopción. Los roles pueden representados por varias personas incluso de varias áreas, no hay o no debe necesariamente existir un match. Sin embargo, hay empresas que la modifican frente a lo que representa el nuevo paradigma de trabajo, y esto es normalmente evolutivo (adopción vs. transformación).

      Recuerdo algo que leí hace un tiempo de Jurgen Appelo: “Todos los humanos son sistemas adaptativos complejos, por lo tanto cualquier sistema que contenga humanos es por definición complejo.”. Un sistema adaptativo complejo (como un organismo vivo) es para mí la mejor metáfora de ver una organización.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s