Blog

5 estrategias para destruir Agile en tu organización

Es oficial: El mundo es Agile.

Viendo que la palabra de moda se menciona en todo tipo de foros y organizaciones, hay que confirmar que todas las previsiones que los más optimistas hacían hace 10 años se han quedado cortas.

Tras observar la evolución, hay que aceptar que lo Agile ha sustituido al Project Management, si no en su totalidad, en un gran número de corporaciones y gobiernos.

Los Project Managers han dejado paso a los Scrum Masters, los Product Owners y hasta a los mismísimos Agile Coaches.

Ahora que todos que somos ágiles y lo hacemos increíblemente bien, es hora de destruirlo.

He recopilado cinco estrategias que las verdaderas organizaciones ágiles nunca pondrían en práctica porque podrían dañar o destruir todo el esfuerzo conseguido.

Estrategia nº 1: Plásmalo todo en un manual del Agile y obliga a todos a que se rijan por él

Elaborar un buen manual de procesos es fundamental para así poder evaluar el cumplimiento Agile de las iniciativas y controlar quién lo hace bien y quién lo hace mal.

Si este manual del Agile además puede indicar un número exacto de minutos para los eventos, con cuántos equipos puede trabajar un Scrum Master y además obliga a documentarlo todo muy bien en JIRA, mejor que mejor.

Al cabo de poco tiempo verás como el objetivo es cumplir y al cabo de unos meses tu organización empezará a sufrir del acartonamiento provocado por la consecución de objetivos de proceso.

Si tu organización es de las que había fomentado autonomía y autogestión en los equipos, asegúrate de especificar una buena matriz RACI para que las personas no tengan duda de que su papel es ser un recurso, una FTE dentro de la organización.

Alternativamente, si quieres evitar este doloroso sufrimiento y la fricción que provoca, investiga técnicas de budgeting y compliance que sean compatibles con equipos autoorganizados orientados a objetivos de negocio.

Estrategia nº 2: Céntrate en certificar a todo el mundo

No importa si los Scrum Masters no han aprendido todavía que su papel no es el de convertir las retrospectivas en fiestas de cumpleaños dónde se hacen collares de macarrones.

Tampoco si los Product Owners nunca han hablado con un cliente de verdad y su Product Backlog es una lista a los Reyes Magos de Oriente.

Lo importante es certificarlos. Mucho.

Aunque no hayan tenido la oportunidad de conocer un entorno donde se practiquen mínimamente los valores de Scrum, asegúrate que tienen el PSM uno, dos, tres y cuatro.

Si se te acaban las ideas, certifícalos en OKRs, en Kanban o en ESS (Estudios del Santo Sudario). Mientras estén bien certificados, cumplirás con los objetivos del establecidos por la organización.

Alternativamente puedes colaborar con las personas de tu organización y dejarles que sean ellos los que decidan como quieren formarse y aprender conforme lo vayan necesitando.

Estrategia nº 3: No formes a nadie

Todo el mundo sabe que Agile se puede aprender leyendo artículos y viendo videos de Youtube igual que se puede construir una iglesia románica.

Si tienes dudas, lo mejor es contratar a un consultor que te dirá cómo hacerlo todo y así los recursos no tendrán que dedicarle tiempo a pensar, que no se les paga para ello.

Si alguien desea formarse, asegúrate que lo hace en su tiempo libre. Tardes y fines de semana es lo mejor.

No les proporciones facilidad ni bolsa de formación. Si les formas, entonces querrán irse a otra empresa a trabajar.

Alternativamente, puedes ayudarles a dirigir sus esfuerzos a aprender como desarrollar mejor su trabajo ya sea con formación, libros o actividades de comunicación dentro de la jornada laboral.

Estrategia nº 4: Mantén múltiples jerarquías dentro de la organización

Una vez que comienzas con una iniciativa de transformación, asegúrate de que las estructuras tradicionales no se modifican. En lugar de eso, convierte a los Scrum Masters y Product Owners en jefes. Si puedes, además, convierte a uno o dos Agile Coaches en los jefes de éstos.

Así conseguirás una nueva y flamante capa de gestión que luchará por el poder con otras capas de gestión a modo de juegos del hambre del parking de la empresa.

Sabrás que has tenido éxito cuando al cabo del tiempo los que están más arriba de la capa de gestión del Agile decidan pelear para ver quién es el jefe supremo. El ganador obtendrá el título de Head of Agile y como recompensa obtendrá los poderes del otro heredando las salas de Mural.

Alternativamente, trabaja en ablandar las jerarquías existentes y potencia las habilidades de resolución de conflictos. Algunas personas no estarán contentas con esta decisión. Esto es bueno, ya que tampoco estarían contentas con las iniciativas Agile.

Estrategia nº 5: No permitas que la gente Agile se salga del Agile

Si escuchas a un Scrum Master decir que hay impedimentos en el delivery que impiden que los equipos sean más ágiles a la hora de entregar, ten miedo.

Si una Product Owner expresa su preocupación en torno a los sistemas de planificación anual, tienes que tomar acción.

Esto es malo.

Los Scrum Masters deberían centrarse en hacer a la gente feliz y los Product Owners en redactar historias de usuario. Tocar las estrategias de delivery o cambiar las formas de estructurar trabajo quedan fuera de su órbita.

Si se da el caso, acúsales de ser fanáticos de Agile y explícales que en tu organización siempre se ha hecho así. Si además puedes referirles la página concreta del manual del Agile donde viene explicado, habrás ganado la partida.

Jaque mate.

Photo by Stephen Radford on Unsplash

Herramienta gratuita para evaluar el nivel de Agile de la organización

Autor: Víctor Fairén.

Cada día son más, las organizaciones que se enfrentan al reto de la transformación digital. Cuando se habla de transformación digital se suele hacer referencia a las “5D de la transformación digital” que identificamos como:

Detenerse
Diagnosticar
Dimensionar
Demostrar
Despegar

Entendemos la transformación digital como la integración de la tecnología digital en todas las áreas de una empresa, cambiando fundamentalmente la forma en que opera y brinda valor a sus clientes. Cuando hablamos de evolucionar la forma de aportar valor a los clientes y nuestra operativa, aparece el concepto diferenciador del Business Agility.

Hoy queremos compartir como una de las herramientas de SAFe es muy clave y nos puede ayudar en uno de los puntos anteriores, en la parte de Diagnosticar: Diagnosticar el nivel de Business Agility.

¿Realmente las empresas Agile son Agile?

Es difícil poder concluir si una empresa es Agile o no lo es. Ya que no existe un mecanismo único para poder determinarlo: no podemos fijarnos solo en las herramientas que usan, ceremonias que hacen o roles que tienen. Esto no es concluyente.

Agile es la adaptación al entorno competitivo desarrollando nuevos modelos de trabajo, pero la evaluación debe ser respecto a nuestro estado pasado. En SAFe podemos encontrar una herramienta de autodiagnóstico que nos permitirá conocer nuestro nivel de madurez sobre determinados ámbitos en un momento dado del tiempo.

Evaluación del Business Agility

La evaluación del Business Agility de SAFe es una evaluación de alto nivel que resume qué tan ágil es el negocio en cualquier momento. El informe de evaluación proporciona una visualización que muestra las medidas de progreso a lo largo de las 21 dimensiones. Puedes ver un ejemplo en el siguiente dibujo.

Puedes descargarlo aquí

Como puedes ver se enfoca en las 7 competencias básicas para desarrollar la agilidad de negocio: Agilidad a Técnica y de equipo, Agilidad en la entrega de producto, Entrega de soluciones a nivel organización, Gestión Lean del porfolio, Liderazgo Lean-Agile, Agilidad organizacional y Cultura de aprendizaje continuo.

No se trata de evaluar todas las dimensiones sin más. Antes de empezar hemos de identificar que dimensiones tiene sentido evaluar, pues no todas las organizaciones tienen porque necesitar desarrollar las 7 competencias. Sobre todo, la referente a la entrega de soluciones o incluso a la gestión Lean del porfolio.

¿Y cómo lo uso?

Evaluar el estado de agilidad empresarial no es algo trivial. Las opiniones abundan, los datos son desiguales y las formas de trabajar están evolucionando al mismo tiempo que se lleva a cabo la evaluación. Por lo tanto, el simple hecho de enviar la evaluación a varios participantes y pedirles que completen los datos probablemente no proporcionará la experiencia adecuada o resultados precisos.

Para maximizar el resultado, se recomienda que la evaluación se haga en una sesión coordinada y facilitada por una persona capacitada en SAFe.

Antes de intentar la evaluación, es importante asegurarse de que todos los participantes tengan un conocimiento básico de la terminología SAFe.

Esta evaluación generalmente se aplica al principio del roadmap de la transformación Agile. Aunque hay algunas empresas que lo utilizan esta evaluación como línea de base para iniciar el viaje hacia el Business Agility.

También es importante establecer la expectativa de que el comienzo del viaje es solo eso, el comienzo, y todos deben tener cierta sensibilidad sobre cuán diferente es la nueva forma de trabajar, y cómo incluso el léxico es tan diferente que puede resultar potencialmente confuso al principio.)

Se pueden usar dos patrones de evaluación:

Cada participante completa la evaluación de forma independiente y luego, el grupo discute y analiza los resultados juntos.

Todos los participantes discuten juntos cada afirmación y llegan a un consenso sobre la puntuación de cada afirmación.

Ambos patrones tienen sus ventajas y desventajas. Escoger una manera de llevar a cabo la evaluación dependerá de la dinámica del grupo, la distribución y el marco de tiempo.

Si quieres aprender más sobre SAFe y como puede ayudar a tu organización, no dudes en contactarnos y asistir a nuestra próxima formación:

Leading Safe 5.0

Autor: Víctor Fairén.

¿Qué hemos aprendido aplicando Lean Change Management? Una aproximación desde el pensamiento de la complejidad

Dentro de nuestro equipo siempre hemos estado relacionados con la puesta en marcha de procesos del gestión del cambio de diferente naturaleza: desde proyectos de mejora de procesos, implantación de grandes Cores de negocio en el ámbito bancario, transformaciones Agile etc.. En muchos de estos proyectos, años atrás, hemos usado modelos basados en Kotter y fundamentalmente en CAP (Change Acceleration Process de GE), y fueron modelos realmente excelentes y de los cuales hemos aprendido mucho. Sin embargo, tenían la característica de ser lineales o predictivos. Es decir, nos basábamos en proyectos con un inicio y un fin, dando a entender que íbamos a ser capaces de predecir el comportamiento de la organización o del mercado ante el cambio que estaba por suceder. ¡Nada más lejos de la realidad!

Nuestra conclusión era siempre la misma, y muy a pesar de lo creativos que éramos: proponer un modelo de gestión del cambio con fechas fijas, acababa con el tiempo no dando el resultado que queríamos. En términos de procesos sí, pero no en términos de impacto en la organización.

Esto nos llevó a buscar enfoques alternativos. Fue cuando conocimos el framework de Lean Change Management. LCM parte de la base de que es complejo predecir el impacto de un cambio, por tanto, en lugar de un tener un plan cerrado en tiempo y alcance, es mejor disponer de un backlog de cambios e ir introduciendo esos cambios en el sistema como si de experimentos se tratasen. Luego se va modificando la estrategia de cambios en base al feedback recibido, y evidentemente hacia la dirección del cambio que se está promoviendo.

En un inicio, este enfoque nos hizo “explotar la cabeza”. Se trataba de una cuestión de perspectiva. Nuestro enfoque había sido considerar las organizaciones como si fueran máquinas: capacidad de predecirlo todo, procesos de trabajo repetibles, decisiones top-down etc… Esto nos obligó a repensar no sólo como enfocar los “proyectos” de gestión del cambio, sino que también nuestra perspectiva como agentes del cambio.

Este cambio de perspectiva nos llevó a territorios para nosotros desconocidos como el pensamiento de la complejidad y el diseño de sistemas sociotécnicos. De todo ello, el gran aprendizaje, ha sido reconsiderar la organización como un sistema vivo. Esto nos ha llevado, como agente del cambio, a replantearte muchas cosas.

Pensamiento de la complejidad: lo que hemos aprendido de los sistemas vivos

Existen muchos trabajos de investigación que han propuesto aplicar la complejidad a diferentes ámbitos. En nuestro caso nos hemos basado mucho en todo el trabajo de Snowden y su equipo.

Lo interesante de este enfoque, como agentes del cambio, es observar las características de un sistema complejo vivo, y sus implicaciones para los sistemas organizativos:

Un sistema vivo está formado por un gran número de elementos interconectados entre sí, intercambiándose energía o información. Una organización compleja viene determinada por la naturaleza de sus relaciones, por tanto, las cosas ocurren durante la interacción, de ahí pueden emerger muchas propiedades (autoorganización, liderazgo, etc.)
las organizaciones complejas son sistemas abiertos, y al fluir gran cantidad de información, no son deseables los estados estables. Una organización que busque el equilibrio estará perdiendo capacidad de adaptación. El equilibrio es por ejemplo lograr controlar todos los riesgos, disponer de suficiente burocracia para tener los procesos bajo control etc…
En un sistema vivo existen muchos circuitos de retroalimentación. Una organización que sea capaz de usar el feedback para percibir las señales débiles de cambios de tendencia, tendrá mayor adaptación al medio.
un sistema abierto no tiene límites claramente definidos, y en muchos casos las declaraciones de misión o visión, o incluso marcos de procesos muy determinísticos, son intentos de definir los límites, y por tanto pueden ir en contra de la capacidad de adaptarse por parte del sistema humano
la historia determina la naturaleza del sistema vivo. A nivel de organización, la historia está contenida en las narrativas que se distribuyen a lo largo del sistema. Esto es una información muy importante para un agente del cambio, de cara a entender los patrones de comportamiento.
de una organización pueden emerger muchas características imprevistas, como liderazgo o creatividad, pero incluso otras no tan positivas, aunque ello no indica un mal funcionamiento del sistema
las organizaciones complejas no pueden avanzar cuando hay demasiado control centralizado
los sistemas complejos adaptativos toman ventaja de la inteligencia de los nodos, y les deja autonomía para lograr una mayor adaptación al medio. Aplicar autogestión en organización no significa caos o inexistencia de control, más bien, el control es sutil y consistente en puntos de chequeo para permitir a los equipos de gobierno resolver tensiones

Estas características, nos hicieron entender la perspectiva reduccionista de los modelos mecanicistas, que hablan de conocer el problema y encontrar objetivamente la solución, dividiendo el problema en elementos más pequeños o discretos para ser abordados por expertos. El pensamiento mecanicista siempre intenta desagregar un sistema. Sin embargo, un organismo vivo no puede ser desagregado, sino estudiado desde una perspectiva sistémica.

La visión mecanicista de la gestión del cambio pone los procesos en el centro, para obtener la máxima eficiencia, mientras que la perspectiva más orgánica pone en el centro a las personas y las conexiones entre ellas, apoyándose en un propósito de impacto de la organización en el ecosistema, buscando maximizar la efectividad del impacto de la organización para sobrevivir en el tiempo. Este mindset, esta aproximación, nos permitió enfocar los procesos de gestión del cambio desde otro enfoque.

Diseño de sistemas sociotécnicos

Resulta interesante conocer el origen de esta forma de organizar el trabajo que, bajo el nombre de diseño de sistemas sociotécnicos, e inspirados en la teoría general de sistemas, se desarrolló en el ámbito de la industria de la minería en Inglaterra durante la posguerra. Su surgimiento viene producido por las caídas de productividad en minas de carbón, que impulsó una fuerte mecanización acompañado de un diseño organizativo taylorista. Dado que los resultados no fueron los esperados, solicitaron un análisis al Instituto Tavistock en los años 50. Entre sus conclusiones ponían en duda que el enfoque taylorista fuese la única forma de mejorar la productividad. Los cambios introducidos en las minas habían desestimado el funcionamiento anterior de pequeños equipos de mineros, multifuncionales y autónomos. Por tanto, ante esta situación, los investigadores propusieron un modelo de organización del trabajo, denominado diseño de sistemas sociotécnicos. El enfoque del diseño de STS (Sistemas Sociotécnicos) considera la organización como un ente de tres elementos indisociables:

Social: constituidos por las personas, sus necesidades, la cultura, los mecanismos de gratificación y las relaciones entre todos ellos
Técnico: las capacidades, tareas, actividades, procesos herramientas y tecnología
El sistema en sí, que viene representado por las relaciones de todos los elementos, incluyendo el ecosistema.

La conclusión más importante es que para lograr incrementar la productividad tenemos que ser capaces de ver el sistema organizativo como un todo (social, técnico y ecosistémico), ya que, desagregando esos elementos, los resultados serán totalmente inciertos. Recordemos lo mencionado en el apartado anterior, que un sistema no se puede desagregar. Hacerlo, sería una aproximación mecanicista.

La combinación que plantea STS, de los 3 elementos (social, técnico y sistémico), como un todo y no como elementos desagregados es crucial. Esto permite una nueva comprensión de cómo funcionan los sistemas humanos. Es fundamental entender que, si queremos introducir un nuevo cambio organizativo, estos diferentes elementos tendrán velocidades diferentes. En muchas ocasiones, cuando queremos cambiar procesos de trabajo, nos solemos centrar en acciones que solo afectan a uno de los elementos. En estas situaciones el sistema tendrá la tendencia a volver a su estado inicial y no se produce el cambio buscado. Es simple ir a un sistema humano y cambiar una herramienta o un proceso, pero se necesita afectar a todos los elementos o dimensiones para que el sistema humano modifique su trayectoria, y esto es más complejo.

¿Cuáles fueron nuestros aprendizajes?

Tengo que reconocer, que, al movernos en entornos complejos, a veces se me hace difícil verbalizar los aprendizajes que hemos podido tener. Sin embargo, hemos vivido varias situaciones que nos han ayudado a convertir estas lecciones en pilares claves, para lograr ser un agente del cambio que tenga mayor impacto en las organizaciones. Aspectos como haber podido impartir muchos talleres de LCM en diferentes contextos y por tanto compartir con muchas personas sus retos. Igualmente haber participado en proyectos de gestión del cambio usando LCM. Incluso participar en foros sobre diseño organizativo y seguir la estela de personas como Snowden o Niels Pflaeging. Y, sobre todo, empezar a adentrarnos en el pensamiento de la complejidad y el diseño de sistemas sociotécnicos.

El cambio no es un fin en sí mismo

No se trata de un viaje, de un proyecto que tiene un principio y un fin. Se trata de olas cambio, durante las cuales tenemos que ser capaces de recoger feedback, ya que recibiremos información clave para movernos hacia la dirección que nos marcan los objetivos. El propósito tendría que ser lograr que la organización tenga mayor capacidad de adaptación, pero no el cambio en sí.

No se trata de resistencia al cambio: es una respuesta del sistema

Normalmente solemos percibir la resistencia al cambio como algo negativo y nuestra primera intuición es gestionarla. Pero si la tratamos como una respuesta del sistema, buscaremos la solución creando contextos diferentes que nos permitan aprovechar sinergias.

El problema suele estar en el sistema

Hay un ejemplo de los sistemas vivos que me ayudó mucho en entender este aprendizaje. Si tengo un jardín con flores marchitas, el mayor impacto no vendrá de las acciones a llevar a cabo sobre la flor, sino sobre el ecosistema de la misma. Me quedé sorprendido al ver una afirmación de Deming que indicaba que el 94% de los problemas vienen del sistema y el 6% de las personas. Por tanto, formaremos, acompañaremos a personas, pero impactaremos a los sistemas humanos.

El cambio de comportamiento organizacional tiene mucho de social y menos de técnico.

Un aprendizaje clave para nosotros, fue recoger las narrativas o historias que se dicen sobre la cultura de trabajo de una organización. Las narrativas nos permiten entender patrones o las limitaciones, pero incluso ya nos permiten identificar varias iniciativas de cambio que podrían ser puestas en marcha con facilidad, y aportando mucho valor.

Por tanto, crear espacios de conversaciones significativas con los afectados por el cambio tiene un gran impacto para observar el sistema y su reacción ante el cambio. Esto se ha venido identificando con el verbo “cocrear”, pero cocrear no significa satisfacer a todos, no significa crear el cambio con todos. Significar aclarar, compartir el impacto del cambio, incluso detectar aquellos que no lo quieren.

Lean Change Management no va solo de aplicar una receta

Si bien es cierto que LCM te da unas guías para iniciar la gestión el cambio, e incluso te propone tomar de las mejores prácticas de diferentes ámbitos (proponiendo herramientas, dinámicas etc..), sin embargo, no es una receta “mágica”. Posiblemente obtendrás mayor impacto, si como agente del cambio, evolucionas de perspectiva y empiezas a considerar a los sistemas humanos como sistemas vivos en lugar de aplicar una perspectiva mecanicista.

Para concluir ….

Sin duda alguna el mayor aprendizaje que hemos tenido al aplicar un enfoque de Lean Change Management, fue el cambio de perspectiva al pensamiento de la complejidad y el diseño de sistemas sociotécnicos, que nos dio unas nuevas lentes y esto nos ha llevado a una vuelta de tuerca como agentes de cambio, y sin lugar a duda, poder ser de gran valor en las organizaciones en las que colaboramos.

Si quieres saber más sobre nuestra experiencia, asiste a nuestro:

Meet Up Gratuito de Abril 2021

Hola, soy José Antonio

Facilitador Certificado de Lean Change Management

Me apasiona descubrir nuevas formas de hacer las cosas buscando siempre la aportación de valor. Tiene más de 25 años de experiencia en consultoría de diseño y desarrollo organizativo que le han hecho dirigir líneas de negocio en grandes multinacionales, liderar proyectos internacionales de transformación y realizar intervenciones de equipos directivos para gestionar el cambio.

Además de ser Facilitador Certificado por la Lean Change Management Association, este ingeniero informático tiene varias certificaciones de organizaciones como Scrum Alliance, Kanban University, o del ICC en el mundo del coaching y facilitador en Lego® Serious Play®. Es miembro honorario de la Global Coaching Federation.

Además cuenta con experiencias en formación en procesos innovadores en KAOSPILOT, IDEO U y el MIT

Igualmente posee formación en Programas Directivos por el ESADE.

Las novedades de la guía de Scrum 2020

Durante el año pasado, en Scrum.org trabajamos junto con los creadores de Scrum, Jeff Sutherland y Ken Schwaber, así como Scrum Alliance y Scrum Inc. en una actualización de la guía de Scrum.

Aunque estaba previsto que se anunciara en Primavera, la pandemia provocada por el COVID-19 hizo que se pospusiera el anuncio de la nueva guía, que no se había actualizado desde 2017.

En este post repaso la evolución de Scrum y su guía a lo largo de este tiempo, para sentar las bases de los próximos cambios que vendrán en breve.

Pulsa aquí si quieres leer la nueva guía

Scrum, quién te ha visto y quién te ve

En Noviembre, Scrum cumplió 25 años desde que se anunció en la OOPSLA en el año 1995. Y durante estos últimos 25 años, Scrum ha cambiado mucho.

La primera vez que llegó a mis manos un manual de la “Metodología SCRUM”, tenía 160 páginas que describían detalladamente todas las mecánicas, roles y artefactos de lo que entonces era una metodología, no un marco de trabajo. Varias decenas estaban orientadas a explicar en profundidad cómo hacer estimaciones.

Por aquel entonces, lo único que necesitabas para ser Scrum Master era el manual, valor y mucha paciencia para aplicar todo aquello en un equipo.

Sin embargo, conforme pasó el tiempo y más organizaciones fueron adoptando Scrum, se hizo evidente que era imposible describir todas las posibles situaciones a las que un equipo usando Scrum podían enfrentarse.

Para entonces, ya habían pasado más de cinco años desde la edición de aquel pesado manual de 160 páginas y se había producido una explosión de personas que usaban Scrum junto con otros métodos, como XP.

Así, surgió la iniciativa de los autores para producir una guía más ligera, más enfocada en los aspectos clave y menos en los superficiales, que fuera una referencia a la que acudir ante la miríada de versiones sobre los que ocurría en Scrum, fuertemente avivadas por la explosión de formadores y formadoras que habían aprendido Scrum y lo enseñaban a través de sus propias experiencias.

Así, en 2010, nació la guía oficial de Scrum.

2010 – La primera guía oficial de Scrum

En la versión 1.0, además de la sustancial reducción de literatura, se hacía referencia por primera vez a Scrum como un “marco de trabajo” en lugar de una metodología.

El cambio no es gratuito. Los fans de las metodologías exigían una explicación minuciosa de cada detalle de las partes que gobernaban Scrum, llevando habitualmente a reducciones ad absurdum.

Cambiando la palabra metodología por marco de trabajo se expresaba que Scrum, de manera efectiva, es una herramienta que puede ser usada de diferentes maneras, y que es responsabilidad del que la usa conocerla y adaptarla a su realidad -o viceversa-.

En esta versión se hace referencia a la metáfora de los cerdos y las gallinas, a un release planning meeting y como artefactos obligatorios se listan el release burndown y el Sprint Burndown.

Quizás una de las referencias más interesantes sea, por primera vez, la de undone work o trabajo no finalizado. Algo que a los que llevábamos tiempo practicando Scrum nos surgía muy a menudo y para lo que no había una solución clara.

2011 – Definición de Scrum, Grooming y descripción de los Roles

Las dos grandes cambios de la primera gran revisión, en Julio de 2011, fueron definir Scrum como un framework en el que se lidia con problemas complejos adaptativos para construir productos del mayor valor posible y la adición del Grooming para preparar historias de usuario.

De nuevo, un pequeño cambio de lenguaje como es el uso de “producto” en lugar de “proyecto”, supone un cambio sustancial en la manera de usar Scrum. Marca la dirección de los siguientes años en Scrum, que donde realmente aporta valor es ayudando a resolver la incertidumbre del desarrollo de productos, más que a ayudar al cumplimiento de fechas, presupuestos y alcance de los proyectos.

El Grooming deja de ser una sugerencia para convertirse en una práctica para hacer Scrum y el Sprint Plan deja de ser un compromiso para convertirse en una previsión.

También se pone énfasis en realizar una descripción de qué hacen los roles en Scrum. El Scrum Master aparece como ScrumMaster -lo cual tenía poco sentido y se elimina poco después- y se eliminan la referencia a Cerdos y Gallinas, aunque ésta tardará años en salir del ideario de los practicantes de Scrum.

Por último, en Octubre de ese mismo año se produce un cambio menor orientado a relajar el foco en las reglas de Scrum.

2013 – Las tres preguntas en la Daily Scrum y el foco en el Sprint Goal

En la versión que se publicó en Julio de 2013 se pone el foco en el Sprint Goal. Muchos de los equipos que utilizaban Scrum nos estaban viendo mejoras sustanciales porque habían convertido al equipo Scrum en una caja negra que ingería requerimientos y digería código, lo que no estaba de ningún modo relacionado con la capacidad de aportar valor a la organización de los equipos que estaban utilizando Scrum.

Así, la palabra valor toma mucha relevancia a lo largo de toda esta iteración. Además se añade una sección en cómo los artefactos de Scrum facilitan la transparencia. De nuevo, se pone el foco en el control empírico de procesos como la base de Scrum

De nuevo, se reduce el lenguaje de la guía y se introducen cambios sutiles. El más prominente es el cambio de las preguntas del Daily Scrum: ¿Qué hiciste ayer? a ¿Qué hiciste ayer para ayudar a conseguir el Sprint Goal?.

2016 – Los valores de Scrum

Tras la desaparición en 2011 del commitment del Sprint, se debatió mucho sobre la necesidad de trabajar con equipos comprometidos, y el uso de la palabra previsión podía dar lugar a pensar que cumplir con una entrega de valor continua es algo opcional. Eso se arregla en la versión de 2016.

Además, para que funcione el control empírico de procesos -Transparencia, Inspección y Adaptación-, la transparencia es condición necesaria. Si no, no puede haber inspección y adaptación

Sin embargo, muchos practicantes de Scrum observaban cómo los equipos, más veces que menos, carecen de transparencia y profesionalidad.

Por primera vez, la conversación se dirige hacia los valores que tienen que tener estos equipos y no hacia las skills o conocimientos de los mismos.

Así, se introducen el compromiso, la apertura, el foco, el respecto y el coraje. Son descritos como un sustrato sobre el que trabajar para hacer que Scrum tenga éxito dentro de una organización.

Esto, además, proporciona unos principios guía para los Scrum Masters con los que poder dirigir la evolución cultural que Scrum requiere para proporcionar los máximos resultados.

2017 – Las preguntas en el Daily Scrum son optativas y los usos de Scrum

En la última versión publicada por primera vez se reconoce que las preguntas en el Daily Scrum son optativas y solamente una manera de dirigir el evento. Además, se relajan otra serie de reglas y se eliminan prácticas, para dejar los conceptos clave más a la vista.

También se introdujo una sección sobre los usos de Scrum, para reconocer que es algo que ha evolucionado más allá de los equipos de tecnología. También se hizo menos dependiente de la palabra Software, ya que hay multitud de equipos no relacionados con la tecnología usando Scrum en todo el mundo.

Además se incluyen multitud de pequeños cambios de lenguaje para hacerlo más claro.

2020 – Autogestión, Product Goal y Scrum más allá del Software

La última versión de la guía de Scrum continua con los cambios orientados a hacer Scrum agnóstico y a reconocer que se usa en muchas industrias más allá del desarrollo de Software.

Por eso se ha trabajado mucho en eliminar no sólo la terminología relacionada sino el trasfondo de desarrollo de productos digitales que hay de fondo. En esto entraré a fondo en un próximo post.

Además se ha puesto el acento en producto, producto y más producto. Desde la guía del 2013, la evolución ha sido principalmente a intentar alejar Scrum de la gestión de proyectos, que por su naturaleza de tiempo, coste y alcance cerrados no aprovechan la principal ventaja de Scrum, la capacidad de adaptación a la incertidumbre y la entrega continua de valor.

Entre los cambios, hay tres muy importantes.

La introducción del Product Goal

La meta del Product Goal es servir de guía para entender como los esfuerzos de cada Sprint van dirigidos a un objetivo de negocio concreto. El Product Goal habitualmente consistirá en un gran objetivo de negocio a ser conseguido a lo largo de uno o múltiples Sprint.

Para situarnos en el lugar correcto, pensemos en el Product Goal como releases de nueva funcionalidad. Los equipos de desarrollo trabajan consiguiendo alcanzar Sprint Goals y una vez que se cumple el Product Goal, se pasa al siguiente.

De hecho, es tan importante que se ha ligado la propia existencia del Product Backlog a la existencia del Product Goal. Ahora, en el Sprint Planning, el equipo Scrum tiene que desarrollar un Sprint Goal que sirva de paraguas para el trabajo desarrollado durante el Sprint y que además esté asociado al Product Goal.

El Product Goal es, además, una medida de progreso que la organización puede valorar a la hora de medir el valor generado.

Equipos autogestionados

Durante muchos años se ha debatido sobre el poder de la auto organización en Scrum. Es un tema recurrente en la mayoría de los foros, pero lamentablemente hay que reconocer que aunque el término es poderoso, se habla más de él por su ausencia que por su presencia.

La realidad es que la mayoría de los equipos Scrum no tienen capacidad de organización, simplemente porque las organizaciones no dejan espacio para que esta auto organización ocurra.

Si permitimos a los equipos auto organizarse pero decidimos sobre salarios, incentivos, horas de trabajo, herramientas, políticas de vacaciones, organización del desarrollo de producto y hasta en qué mesa pueden sentarse, ¿Que nos queda para organizar nosotros? ¿La retrospectiva? Y muchas veces ni siquiera eso.

Sutherland y Schwaber han querido dejar esto claro en la nueva guía, donde ahora se puede leer que el equipo Scrum se autogestiona.

De hecho, ya no diferencia entre Scrum Team y Development Team. Ahora el equipo Scrum es UN sólo equipo. Incluso deja entrever que el Scrum Master o el Product Owner tienen que sentarse a trabajar en producto si es necesario.

Incrementos útiles y de valor

Por último, el cambio que a mi más me ha gustado ha sido con respecto al incremento. En guías anteriores se hablaba de incrementos potencialmente entregables. Eso daba lugar a sesudos debates en torno a qué era potencialmente entregable. ¿Es en producción? ¿En preproducción? ¿En postproducción? ¿Pri, pra, pre, pro o pra?

En resumen: En todos sitios menos en las manos del usuario.

Con la nueva guía queda claro que los incrementos tienen que ser útiles y de valor. ¿Qué significa esto? Pues que tiene que estar en manos de un usuario. Que tienen que ser útiles para el usuario, y que además tienen que generar valor y medirlo.

Esto supone un salto de calidad grande sobre lo que teníamos anteriormente, que era un lenguaje vago que la mayoría de las veces conducía a una discusión sobre que significaba potencialmente entregable en lugar de trabajar para hacerle ganar a la organización.

Aunque existen más cambios, estos son los que más poderosos me han parecido. ¿Y a ti? ¿Qué cambios de la guía te han gustado más? Puedes dejárnoslo en los comentarios.

Servant leadership, separando el grano de la paja

Si has leído la guía de Scrum o asistido a uno de nuestros cursos, habrás oído hablar del término servant-leader. Al contrario de lo que muchas personas piensan, el concepto de Servant-Leadership no es nuevo, tiene un fundamento científico fuerte detrás y ha sido adoptado mucho más allá de entornos ágiles por distintas organizaciones a lo largo de muchos lustros.

El Servant-Leadership es un modelo de liderazgo en donde la meta última del líder es servir, a diferencia de los modelos tradicionales en donde la meta del líder es crear una organización o una empresa próspera, lo que puede -o no- alinearse con la meta de servir a la organización.

Alguien que lidere a través del servicio comparte poder, anteponiendo las necesidades de los empleados y ayudando a las personas -incluyendo a los stakeholders- a desarrollar su máximo potencial.

En la formulación original de Robert K. Greenleaf, la pregunta que debe hacer el líder es: ¿Están creciendo aquellos a los que se sirve? ¿Son más saludables, sabias, libres, autónomas, se sienten mejor, más capaces para convertirse en en servidoras también?

Esto, que puede intuitivamente ser asociado a un entendimiento superfluo del liderazgo, ha sido ampliamente estudiado. En un estudio de investigación del año 2002, Sendjaya y Ramos analizan cual es el impacto del Servant Leadership en las organizaciones que deliberadamente han decidido adoptarlo como modelo de liderazgo.

Servant Leadership, un término con más de 50 años

Aunque parezca un término nuevo, el término Servant-Leadership (liderazgo a través del servicio) fue formulado hace casi medio siglo. La idea le surgió a Greenleaf tras leer el libro Viaje al Oriente, de Herman Hesse, que describía la épica aventura de un grupo que decide viajar a Oriente y cuya figura más aparentemente innecesaria, Leo, desaparece, provocando el desarraigo y la separación de un grupo aparentemente cohesionado.

Durante el viaje, Leo se encarga de realizar tareas mundanas y aparentemente veniales: Fregar platos, recoger materiales, pero también animar al resto en cuerpo y alama. Nadie diría que Leo es el pegamento del grupo hasta que éste desaparece.

A Greenleaf le cautivó la idea de que el sirviente fuera realmente el líder y decidió conceptualizar la idea de Servant-Leadership en una persona cuyo éxito se mide por el crecimiento y el éxito de otros, no de sí mismo.

Las características de un Servant leader

En 1998, Larry Spears publicó otro artículo de investigación en el que describía las características más importantes de un líder servicial a raíz de las formulaciones posteriores a la conceptualización inicial de Greenleaf. Éstas 10 características son:

Escucha. Aunque los líderes son valorados por su capacidad comunicativa y de decisión, éstas tienen que estar reforzadas por una profunda capacidad de escucha activa hacia los demás. Dado que el compromiso del líder servicial es hacia los demás, aprender a escuchar tanto lo que se dice como lo que no es fundamental para poder accionar decisiones.
Empatía. La empatía se puede describir como la habilidad para ponerse en la piel del otro, desprendiéndose de los propios juicios -y prejuicios-. Es importante no confundirlo con la simpatía -sentir lo que siente el otro-. De esa manera, el líder puede utilizar mejor su capacidad de acción.
Curación. Ser capaz de sanar y reforzar relaciones es una potente capacidad transformadora y de integración. Una de las grandes fortalezas de un líder servicial es ser potencialmente capaz de sanar las relaciones propias y ajenas.
Conciencia. La conciencia de lo que ocurre a su alrededor, y especialmente la auto-conciencia, son dos capacidades que tiene el servant-leader a su disposición para hacer crecer a otros y desarrollar un entorno en el que puedan alcanzar nuevas cotas de potencial.
Persuasión. Lo que diferencia la persuasión de la manipulación es la intención. Persuadir es la habilidad de conseguir convencer a alguien para hacer algo en pro de un bien común. La manipulación consiste en convencer a alguien para hacer algo solamente en pro de un beneficio personal.
Conceptualización. La capacidad de observar un problema desde una perspectiva de conceptualización significa que uno debe de mirar más allá de los problemas del día a día. Conceptualizar problemas a través del modelado es una habilidad fundamental para un líder servicial.
Previsión. Muy relacionada con la conceptualización, la habilidad de preveer los resultados de una acción es difícil de definir pero sencilla de identificar. La previsión es una capacidad que permite al líder servicial aprender del pasado, entender los problemas del presente y generar espacio para la resolución de problemas complejos a través de aquellos a los que sirve.
Gobernanza. A diferencia de la dirección, la gobernanza se manifiesta en la capacidad de conseguir consenso en un entorno complejo para alcanzar resultados mayores. Mientras que la dirección implica la toma de decisiones individual, la gobernanza se centra en la creación de marcos donde los miembros del sistema tienen libertad para conseguir metas.
Compromiso hacia el crecimiento de las personas. No debería de sorprendernos saber que la mayoría de los líderes consideran a las personas como medios para conseguir sus propios fines y no cómo entes autónomos con sus propias motivaciones cuyo crecimiento ayuda a sumar al sistema.
Construcción de comunidad. Por último, los líderes serviciales están muy orientados a la creación de comunidades donde otros pueden tomar el papel de liderazgo en cualquier momento.

Es interesante hacer un inciso para aclarar que en Psicología se distingue entre rasgos y características del carácter. Mientras los primeros pueden no ser modificados y van implícitos en el carácter de la persona, los segundos se adquieren a través del entrenamiento y el aprendizaje.

SLBS-6, midiendo el Servant Leadership

En 2019, Sendjaya junto con su grupo de investigación publicó un cuestionario corto de 6 preguntas, basado en un estudio de dos años antes, para validar la fiabilidad del constructo de Servant-Leadership.

En Psicología, cuando se pretende medir algo a través de un cuestionario, hay que refutar que realmente las preguntas miden aquello que se pretende estudiar. Esto es lo que se determina mediante la validación de las propiedades Psicométricas de las preguntas. En particular se analizan la fiabilidad, la cohesión y la validez del constructo. La escala del estudio consta de seis elementos:

[Mi jefe…]

Utiliza su autoridad en servicio de otros, no para su propia ambición
Me da el derecho a cuestionar sus acciones o decisiones
Me respeta por quien soy, no por cómo le hago sentir
Realza mi capacidad para acciones morales
Me ayuda a generar un sentido de propósito del trabajo diario
Contribuye a mi crecimiento personal y profesional

Servicial no es servil

Es fácil pensar que el objetivo de un líder servicial es servir las necesidades de todas las personas con las que trabaja. Nada más alejado de la realidad.

En la mayoría de las ocasiones y ante un problema, un líder servicial actuará con el objetivo de empoderar a la persona, en lugar de resolverle el problema. Ésta es la diferencia entre servicial -sirve- y servil -lame culos-.

Para terminar, merece la pena hacer una referencia a que el conjunto de prácticas de Management 3.0 puede ayudar a un servant-leader a entender cuales son las motivaciones y obtener retroalimentación para las primeras características que mencionábamos más arriba.