• Saltar a la navegación principal
  • Saltar al contenido principal
  • Saltar a la barra lateral principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

Blog

5 argumentos en contra de usar Scrum

Durante los últimos meses he observado un cierto encarnizamiento en torno al debate sempiterno de las metodologías ágiles y en especial de Scrum del que he preferido mantenerme a distancia.

Este tipo de debates no es nuevo y creo que cada dos o tres años experimentan un renacimiento a causa de la decepción que muchas personas experimentan con los métodos ágiles.
​
El objetivo del presente artículo hoy es dar contexto a los argumentos en contra de Scrum, en un intento de intentar ayudar a entender qué es y qué no es.

Me he centrado en cinco: La excelencia técnica, el rol del Scrum Master, el intrusismo, la mercantilización de las certificaciones y la muerte de Scrum.

Scrum no promueve la excelencia técnica.

Muy cierto. Ningún equipo de desarrollo de Software que hiciera una basura de producto con clases de mil líneas, acomplamiento extremo, spaghetti code y cuyo concepto de test es “funciona en mi máquina”, tras aplicar Scrum, han conseguido ninguna mejora.
​
Es más, muchos de ellos, debido a la presión inherente al proceso de Scrum, han terminado haciendo cosas incluso peores, fruto de una falta absoluta de orientación a producto y una Definition of Done.
​
Porque puedes coger cualquier cosa en este mundo, y de la forma más amateur del mundo, destrozarla y decir que no promueve lo que tu quieres que promueva.
​
Y eso está bien, porque Scrum no promueve la excelencia técnica. Son las personas que hacen Scrum las que tienen que promover la excelencia técnica. En concreto el Equipo de Desarrollo (Dev Team).

No concibo trabajar en 2020 con un equipo que no entienda cómo escribir buenas Historias de Usuario ayuda a dirigir una arquitectura hexagonal u onion. Tampoco que no entendamos las bondades que aporta reducir los ciclos de feedback a través del uso de herramientas de integración y despliegue continuo como Azure. O del uso de telemetría para identificar quick wins y el impacto que el software que escribimos tiene en el valor que nuestros usuarios perciben.

Azure application insights permite integrar telemetría de la aplicación directamente en Visual Studio

Que Scrum no hable específicamente de excelencia técnica no significa que Scrum excluya la excelencia técnica.

Significa que es un framework ligero, usado en multitud de industrias y sectores en todo el mundo; como tal, es imposible describir todas las opciones que existen para mejorar la excelencia técnica sin caer en el error de intentar hacer el diccionario Larousse del Scrum: Una iniciativa noble, épica pero inútil.

​
El Scrum Master es un rol, no es una persona.

Totalmente cierto. Y todavía no he encontrado quien diga lo contrario. Sin embargo, es habitual que dada la naturaleza física del mundo, el rol del Scrum Master termine realizándolo una persona y no el espíritu santo.

Es más, debido al caos que suele generar un cambio de contexto continuo en caso de que una persona comparta varios roles, muchas de esas personas querrán dedicarle tiempo completo al rol, mientras que otras no.

El tiempo que le dediquen afectará a la efectividad del rol.
​
También afectará a la efectividad del rol la capacidad y el conocimiento que la persona o personas que ejerzan el rol tengan sobre Scrum y sus posibles consecuencias o ramificaciones.

Si su exposición a Scrum está limitada al popular episodio: “Peppa Pig y su familia desarrollan Software usando Scrum” es posible que su capacidad de entendimiento esté limitada por una falta de conocimiento sobre las consecuencias de hacer Scrum.
​
E incluso así, se puede hacer Scrum.

Igual no es un Scrum maravilloso que además cae en los problemas expuestos en el punto anterior pero la naturaleza de Scrum, que es ser libre para ser usado por quien quiera, permite usarlo.

Los Scrum Masters y Product Owners no han programado nunca. Son unos intrusos.

​
​Bingo, otra en la frente. Ahora mismo hay muchas personas ejerciendo el rol de Scrum Master, Product Owner, enseñando Scrum y certificando gente que no tienen ni idea de programar.

Es más, hay organizaciones y partes de organizaciones con cientos y miles de personas que no producen software utilizando Scrum.

E incluso hay personas que utilizan Scrum o partes de Scrum en cosas que no tienen nada que ver con la Tecnología.

Este es precisamente uno de los motivos por los que Scrum es tan popular. Porque no tiene una legión de policías diciéndote lo que no puedes hacer sino que son unas reglas de juego que puedes utilizar para múltiples cosas.
​
Y no sólo hay personas haciendo Scrum en equipos de tecnología que no saben programar. Hay CTOs, CIOs, Development Managers, Arquitectos de Software e incluso programadores que no tienen ni idea de programar.
​
Por un lado, yo nunca contrataría a un Scrum Master para trabajar con un equipo de tecnología que no tiene un conocimiento mínimo de Software. Y si ese es el caso, le invitaría a hacer al menos dos o tres cursos de los miles gratuitos que hay en línea para que aprendiera qué es programar, para qué sirve el control de versiones o por qué una arquitectura monolítica puede superar en beneficios a una de microservicios en equipos pequeños y cross-funcionales.
​
Por otro, los técnicos tendemos a pensar que el valor de nuestro Software reside en el código. Y el ciclo de vida del Software es mucho más que eso. Podemos hacer un código maravilloso y ofrecer cero valor a nadie. En la mayoría de los casos hacen falta personas de producto, de proceso, de operaciones, de administración de sistemas, de marketing, de ventas y de administración para ofrecerle valor a alguien.
​
Los programadores hemos de dejar de estar enamorados del código que escribimos y empezar a enamorarnos del valor que el código que escribimos crea.

​
El mercado de Scrum y las metodologías ágiles se ha mercantilizado. Las certificaciones no valen nada.

Absolutamente cierto. En la fiebre del oro del lejano Oeste quienes tenían ganancia asegurada no eran los buscadores de oro, sino los vendedores de palas.
​
Lo cual no quiere decir que no hubiera buscadores de oro que no se hicieran tremendamente ricos.
​
Hoy en día hay compañías completamente alejadas de estos debates que están usando Scrum para ser tremendamente ágiles: competitivos, adaptativos e innovadores.
​
​Durante una reunión en 2015 a la que asistí en Boston, cuna de Scrum, descubrí que existe un acuerdo total entre las compañías certificadoras para identificar a individuos influenciables y a través de campañas dirigidas de Facebook Ads, anuncios en conferencias ágiles y una campaña orquestada por redes sociales, fabricantes de post-its, rotuladores y el lobby de las jirafas, para certificarlos a todos. Todo se hizo con conocimiento del club Bilderberg y la aprobación del Conde Drácula y Don Pimpón.

A pesar de que alguien haya leído el párrafo anterior y le haya dado un vuelco al corazón – ¡Lo sabía! – es ironía. Lo cual no cambia el hecho de que Scrum se haya mercantilizado.
​
No hay más que crear una sensación de demanda para dirigir un comportamiento.

No es nuevo.

En 1775 se hizo en Francia para fomentar el consumo de la patata, que se veía como un alimento para el ganado.
​
Las compañías, sobre todo en el último lustro, han demandado más profesionales con conocimientos de Agile. Y Agile se ha asociado tradicionalmente a Scrum. Es por ello que han surgido cientos o miles de compañías dedicadas a la fabricación en masa de certificaciones ágiles cuyo marketing es cuestionable o puede llevar a engaño.
​
Y hoy en día, tenemos un maravilloso y variado mercado de limones.

No es algo exclusivo de Agile, es algo inherente a cualquier sector emergente en cualquier industria en cualquier país.

Desde las mascarillas para el COVID a los másteres que no son másteres.
​
Un momento. ¿No soy yo, Jerónimo Palacios, parte de esa mercantilización? Por supuesto que sí, en la medida en que todo el que tiene que ver con las certificaciones cae dentro del mismo saco.

Sin embargo, creo que dado el posicionamiento que hemos tenido, intentando mantener la calidad -y por ende el precio- por encima de la media, centrándonos en hacer de la formación -y no de la certificación- una palanca de transformación en las organizaciones con las que he trabajado y aportando experiencia haciéndolo.
​
Como ser humano es imposible no caer en contradicciones. Estoy seguro de que he formado personas que utilizan Scrum como un báculo con el que golpear a otros. Personas que han terminado formando parte de equipos de Software como Scrum Masters sin saber de tecnología.

Siempre he creído que lo importante de mi trabajo es explicar las cosas, la importancia que tiene la tecnología y las personas en torno al valor que creamos, pero siempre lo he hecho desde la perspectiva de Scrum.
​
Además, no es ningún secreto que puedes ir a Scrum.org y pasar la certificación PSM sin necesidad de asistir a nuestra clase ni a la de ningún Professional Scrum Trainer. Es más, con un poco de google fu puedes buscar archivos con cientos de preguntas por la red que te ayudarán a pasar la certificación sin saber siquiera cuantas preguntas está obligado a responder el Team todos los días al Scrum Manager.
​
Y eso hace que la certificación no valga nada. Porque la certificación certifica -¡Sorpresa!- que en un momento dado has pasado un examen de conocimiento básico sobre Scrum. Lo que vale es el conocimiento, ideas, habilidades y capacidades de la persona que ostenta esa certificación de ejercer ese rol en una organización.


Scrum ha muerto.

Toda la razón. Llevo viendo morir a Scrum y Agile desde que empecé a aplicar técnicas de desarrollo ágil y XP en 2007, cuando me subí al carro de Ruby on Rails. Hay pocas cosas tan viejas en el desarrollo de Software moderno como Scrum, que ya tiene 25 años.
​
Dentro de unos años Scrum no existirá. Y con ello habrá desaparecido la mercantilización, la falta de excelencia técnica y el rol del Scrum Master.

Ojalá el motivo de la desaparición de Scrum tiene como motivo que las organizaciones que desarrollan productos complejos han entendido que todas las cosas que promueve Scrum, incluyendo la agilidad de negocio, forman parte de su ADN, y por tanto no tienen que recurrir a ningún framework, método, certificación o bala de plata para mantenerse competitivas.

SAFe: Ni tan bueno ni tan malo

Autor: Víctor Fairén

Dentro de la comunidad Agile que conozco encontramos 3 tipos de posturas muy distintas sobre SAFe. Si es realmente Agile o no es Agile, y si sirve o no sirve para nada:

SAFe es el Santo Grial: defensores acérrimos de las bondades y vicisitudes de este marco de trabajo. SAFe es Agile! Sin duda, y sobre todo es el único modo de llevar Agile a las grandes organizaciones.

SAFe es maligno: opositores convencidos que SAFe no tiene nada que ver con Agile. Algunos aluden a que cuando se publicó el “Agile Manifesto” su creador todavía estaba con métodos de trabajo incrementales (que no iterativos).

Todos los puntos de vista son respetables, por supuesto. A veces, estas posturas tan radicales se deben a falta de conocimiento o malas experiencias. Tendremos personas que han visto como las iniciativas Agile fracasaban en su empresa hasta que se usó SAFe como marco de trabajo y entonces empezaron a cambiar cosas. Otros han sufrido como trabajaban en equipos ágiles y cuando la organización ha empezado a usar SAFe todo se ha vuelto procesos estrictos y se trabaja desde una perspectiva de control sobre los equipos. En ambos casos, su opinión puede estar sesgada por su experiencia.

Hay un tercer grupo de personas:

SAFe… depende! SAFe puede ser muy útil para las organizaciones siempre y cuando se utilice bajo una perspectiva Agile. Por suerte este grupo cada vez es más numeroso. De hecho, a pesar de ser formador oficial de SAFe desde 2015 (SPC) me considero en de este grupo y ayudando a los indecisos descubrirlo y a la gente de los dos grupos anteriores a ver la otra cara de la moneda.

Generalmente, las personas tienen directamente la visión de SAFe que es la del propio formador que les ha explicado de que trata SAFe. No es poco habitual, por mala suerte, encontrarme gente que me espeta “SAFe no es para aquí”, “Como PO pierdo toda capacidad de influencia”, “antes era SM y ahora soy un PM venido a menos”. Ayudar a reconducir estas situaciones no es tarea fácil, es todo un reto… ¡y me encanta!

SAFe: pasar de Waterfall a Agile

En ocasiones, he oído que SAFe es la solución para las empresas para pasar de trabajar con modelos tradicionales predictivos a Agile o modelos empíricos. ¡Esto no es cierto! Lo siento no es tan fácil.

SAFe no es un marco “plug and play” donde un día somos waterfall y al siguiente Agile. O bueno, podemos ser un waterfall con elementos Agile pero realmente nada ha cambiado, solo cambios de nombres en los roles, usar post-its y nuevas ceremonias que se añaden a todas las que existían previamente.

Lo cierto es que SAFe nos puede ayudar en el cambio de waterfall a Agile:

SAFe puede ser la palanca para el cambio!

Aquí es donde empieza realmente el cambio, entender su uso como palanca. Y nos servirá para evitar caer en los principales y típicos errores que se dan en las organizaciones cuando usan SAFe:

  • Nuevos roles que se usan para perpetuar la jerarquía existente sin importar las competencias.
  • Reducir costes de ciertos eventos, quitando el potencial que podrían aportar.
  • No considerar los tiempos de coordinación al escalar.
  • Planificar sin considerar la incertidumbre del entorno ni la necesidad de flexibilidad.
  • No considerar las distintas competencias a adoptar en la organización.

Si quieres conocer más sobre SAFe y como puede ayudarte en tu evolución hacia Agile te animo a asistir a mi próxima formación. Veremos cómo SAFe puede servir tanto para evolucionar de un modelo tradicional a Agile o a escalar Agile dentro de la propia organización.

Próxima formación de safe

Autor: Víctor Fairén

Compromiso y Scrum, una guía para tomar decisiones

En ocasiones, entender el funcionamiento de los compromisos en Scrum es difícil dada la diferencia de comprensión sobre qué es un compromiso y los conceptos de simetría y asimetría en el mismo. Veámoslo con una pequeña historia.

María quiere casarse con su pareja. Llevan siete años juntas, pero han tenido algunas dificultades.

A pesar de estar dentro de una relación, María se siente tentada a abrirse a otras personas y a otras experiencias.

Esto no quiere decir que no la quiera, todo lo contrario.

María entiende las relaciones como algo abierto, mientras que su pareja lo entiende como algo cerrado.

Este es un caso clásico de simetría y asimetría del compromiso.

Mientras que la pareja de María entiende que cuando se está en una relación de pareja el compromiso de fidelidad es mutuo (simétrico, igual para los dos actores), María entiende que no tiene por qué serlo (asimétrico, distinto para los dos actores).

En ocasiones tampoco existe transparencia acerca del compromiso, así que cada uno de los actores asume que su manera de entender el compromiso es la bueno. Es la vara de medir que utilizará para atizar al otro.

Esto dará lugar a problemas en la relación de María y su pareja en el futuro.

Compromiso en El Mundo Real™

¿Y en las organizaciones? Ocurre igual.

Mientras que algunos jefes les piden a sus subalternos cosas en las que ellos no creen, los subalternos piensan que en la misma posición ellos lo harían de forma diferente.

Error.

El problema de nuevo es la simetría del compromiso.

Cuando el departamento de gestión de calidad encarga un nuevo proyecto y pide un alcance, tiempo y coste cerrado, el departamento de Software entiende que las estimaciones y compromisos estarán atados a que no haya cambios.

Sin embargo no es así.

Tanto por un lado como por el otro es imposible tener un compromiso simétrico.

Calidad querrá que Software se atenga a su compromiso mientras ellos no respetan el su parte del trato y Software luchará para que haya simetría de nuevo, indicando que es imposible mantener el compromiso inicial cuando se han cambiado las reglas del juego a medio camino.

Y al igual que en la relación de María, esto genera problemas continuos en las organizaciones con las que trabajamos.

¿Y cual es la solución? No se trata de establecer procesos pesados que definan el compromiso para siempre, se trata de asegurarse de que cuando las reglas cambian, todos los implicados están de acuerdo con los cambios y aceptan que los compromisos iniciales quedan invalidados de acuerdo a la nueva situación. Esto es la capacidad de adaptarse a nuevas situaciones.

La principal ventaja de la agilidad.

Para poder mejorar la simetría, lo primero es establecer un “punto de compromiso”, dentro del marco en el que trabajamos, que obviamente es uno en el que se acepta que los cambios pueden surgir. En este punto de compromiso, se realinean expectativas y se hace transparente hasta donde se está dispuesto a llegar.

Compromiso en Scrum

En Scrum, esto ocurre durante el Sprint Planning. Los Sprints en Scrum permiten dar flexibilidad al cliente y constancia al equipo. De esta manera, se fija un Sprint Goal (simétrico, no cambia para el Development Team y para el Product Owner) y un Forecast o previsión (asimétrico, puede cambiar en función de las necesidades que surjan).

Este proceso se hace transparente a través del Sprint Backlog, que junto el Sprint Goal y el Forecast o previsión para el Sprint, nos ayudan a definir una guía sobre la que trabajar durante el próximo mes -o menos-.

En el método Kanban ocurre de forma similar. Mientras que los tickets se encuentran a la izquierda del punto de commitment (normalmente una columna llamada Next, que se elige durante el Replenishment), son solamente opciones. Los peticionarios pueden pedir pero hasta que los tickets no entran dentro del sistema. No se establece la relación de simetría o asimetría.

Una vez que pasan este punto de no retorno, se convierte en simétrico: ahora hay un acuerdo explícito y transparente. Hay que evitar abortar a toda costa cosas que ya están dentro de nuestro sistema, porque tenemos un compromiso de entrega.

¿Qué ocurre cuando el equipo no es capaz de responder a toda la demanda?

Entonces lo protegemos y ordenamos la demanda por prioridad, dejando que sea el equipo el que haga tantas cosas como puede hacer. De esa manera maximizamos la eficacia de ese equipo.

Si además limitamos la cantidad de trabajo en curso, usando límites WIP, conseguiremos que el flujo de entrega sea más estable y de esa manera, responder adecuadamente a un compromiso simétrico.

Tampoco es decir a todo que sí

Es evidente que decir a todo que sí, o su variante “No puedo decir que no” es una receta desastrosa para mantener una simetría del compromiso. Si decimos a todo que sí, o no podemos negarnos a nada, nuestra capacidad de mantener un compromiso estable de entrega de valor es completamente asimétrico.

Nuestro compromiso no vale nada.

No tenemos control sobre lo que podemos comprometer. Evidentemente eso afecta a la capacidad de adaptarse a nuevas situaciones en nuestra equipo u organización.

Precisamente saber cual es la capacidad real de compromiso y esforzarse por fomentar una simetría a través de la autonomía en la toma de decisiones es clave para conseguir que Agile nos permita acelerar y mejorar los resultados de nuestro negocio.

Hacer lo contrario, es decir, meter todo lo que se puede a ver si sale algo. Además poner un carril de urgentes -normalmente llamado Scrumban– es una receta para el desastre. El que más comprometido está es el más débil de la relación.

Volviendo al ejemplo de María, sería como si esta hablara a su pareja de las bondades de la fidelidad mientras disfruta de tres amantes distintos. No sería lo mejor para nadie, ¿No?

Gestión del Cambio – Crear conversaciones significativas que lleven a los equipos a la acción en remoto: diseño de un taller

Autor: Jose Antonio Ortega

Últimamente algunos de los participantes a los talleres que hago de Lean Change Management me han estado preguntado sobre ¿Cómo puedo alinear equipos o directivos, y crear conversaciones significativas que los lleve a la acción y en remoto? ¿cómo logro poner de acuerdo o alinear equipos sobre un reto que tienen que enfrentar, por ejemplo, un cambio en su organización del trabajo o pivotar sobre el negocio, etc..?. En este artículo explico cómo lo he hecho, e incluyo la plantilla en PDF para que tú también puedas ejecutar el diseño de este taller. Click Aqui

Esta inquietud es genuina. Yo mismo pasé por las mismas dudas cuando nos vimos obligados a replantearnos cómo ejecutar talleres una vez obligados a confinarnos.

Tengo que reconocer que me encanta hacer talleres, mezclarme con la gente, lograr que se pongan de acuerdo sobre temas. Es fascinante que los equipos tengan momentos “aha” y por último llevarlos a la acción. Evidentemente hacerlo en presencial es increíble. Como facilitador puedes observar las actitudes no verbales. Igualmente permites que los participantes construyan sobre las perspectivas de los demás. Pero para hacerlo en remoto ¿tengo que renunciar a algo? ¿perderé eficacia en el resultado?

Herramientas virtuales

El advenimiento del estado de alarma nos obligó a reaccionar muy rápido. Teníamos que dar respuesta a muchos talleres que teníamos planificados, y los diseños que solíamos usar ya no encajaban del todo para un entorno virtual. Después de analizar varias herramientas y probarlas, nos decantamos por usar MIRO (igualmente probamos MURAL). Nos permitía emular un gran lienzo en donde los participantes podían usar el equivalente a notas adhesivas para generar ideas.

Estrategia de diseño de talleres

Pero nos faltaba una pieza. Todos los diseños de talleres que teníamos estaban pensados para hacerlos en presencial. Las dinámicas, las herramientas (me gusta usar Legos o fotos Sikkona) ya no servían. Los espacios de reflexión con las dinámicas etc.. tenían que ser replanteados. Teníamos muchos talleres prediseñados, incluso teníamos una gran biblioteca de dinámicas que nos servían para diseñar talleres muy rápidamente. Sin ir más allá, para talleres de alineamiento directivo teníamos varios modelos para dar respuesta a situaciones variadas, pero ninguno en remoto.

¡Con la nueva situación tuvimos que pivotar muy rápidamente!

Ha sido clave usar ciertos principios de diseño de talleres para garantizar el éxito, y más cuando se va a ejecutar en remoto

  • Juntos, pero no revueltos. Aunque todos los participantes estén juntos para tomar decisiones, el proceso tiene que permitir la opinión de todos, pero de una forma estructurada. Es clave reducir el peso de la discusión abierta y por ende de la convergencia. Es clave recoger realmente el espíritu del sistema y no solo del que más energía o más influencia tenga.
  • Escoger alternativas es un proceso anónimo. Lo que permite eliminar los sesgos y desde una perspectiva sistémica dar respuestas más innovadoras.
  • Quitarle peso a la creatividad. Aunque está implícito en los procesos de cocreación, no darle tanto espacio como en otros procesos tipo design thinking. De este modo no suelen generarse esos bloqueos típicos de aquellas personas que no se consideran tan creativas.

El primer taller que hicimos una vez declarado el confinamiento, usamos estos principios como guía para ejecutar el taller en remoto y facilitar a los participantes la participación de las dinámicas. Este aspecto fue crucial para garantizar el éxito del taller al no ser presencial.

Estos principios fueron elementos clave para un diseñar un taller que lograse alinear un equipo de trabajo o directivo en remoto.  Teníamos que lograr que cada uno desde su casa, y en tiempo limitado, los equipos llegasen a acuerdos importantes.

Diseño del taller para alinear un equipo de trabajo o directivo en remoto: Los 4 pasos

Cuando tengo que realizar un taller de este tipo, suelo usar una estructura de taller basada en 4 pasos. Aunque, posteriormente, en función del contexto del equipo, puedo darles más o menos profundidad. Este tipo de taller suele tener un patrón claro: eficiencia en tiempo y acciones concretas. Estos elementos son claves para poner de acuerdo equipos o directivos sobre temas como: realizar un cambio en la organización del trabajo, el diseño o lanzamiento de un producto, puesta en marcha de un nuevo sistema de información o incluso para la resolución creativa de problemas etc…

  1. Objetivos: dar el espacio para que el equipo pueda identificar qué objetivos se persiguen con el cambio que se quiere materializar
  2. Situación actual: qué cosas nos están impidiendo acercarnos al objetivo e igualmente qué aspectos son fortalezas en la organización y nos acercan a la meta
  3. Opciones: basado en los aspectos anteriores, qué alternativas tiene el equipo para lograr los objetivos que hay que lograr
  4. Plan de acción: el equipo elabora un backlog de acciones identificando aspectos temporales de los mismos, responsables etc..

Este esqueleto es muy básico, pero me resulta de gran utilidad para el diseño de talleres.

A continuación, voy a explicar un taller ejemplo con actividades de máximos, usando la plantilla en PDF que podéis descargar en el siguiente enlace Click Aqui .

De manera general, este esqueleto está alineando con el enfoque Lean Change Management. De hecho, en algunas situaciones utilizo los lienzos propuestos por LCM en el propio taller.

1.- Propósito:

Al pactar con el cliente el taller, intento averiguar si tienen claro el propósito del reto o del cambio. Si intuyo que no lo tienen claro, entonces incluyo esta etapa, para darle el espacio para poder reflexionar sobre el PARA QUÉ. En esta actividad es importante que el facilitador lleve a los participantes a pensar de una forma inspiradora. Esta actividad es clave para alinear un equipo de trabajo o directivos en remoto y llevarlos a pensar más allá.

Es normal, que muchas personas confundan propósito con objetivos, pero no importa, esta situación la tiene que manejar el facilitador. Para ello, se pueden usar dinámicas tipo «cinco porqués» para indagar sobre las propuestas de los participantes.

Es importante ver la diferencia entre un propósito y un objetivo. Una posible redacción de un propósito puede ser “quiero darle a mi cliente un entorno innovador para que resuelva sus problemas”.  Un potencial objetivo puede ser “queremos duplicar ingresos para este año”. El propósito tiene una connotación más inspiracional. (en este contexto utilizo esta nomenclatura de propósito/objetivo, pero se podría usar perfectamente el de Objetivo/Resultado clave)

Por otra parte, aplicamos el sistema de votación “dot voting”. Ayudando a los participantes en poner el foco en aquellos aspectos que generan más acuerdos entre los diferentes directivos.

En algunos casos, esta parte de propósito puede ser sustituida por un discurso del cambio que haga el líder. Es algo que siempre recomendamos realizar, hagamos o no esta actividad, siempre es positivo que haya una introducción inspiradora. Sobre los éxitos logrados por el equipo, el impacto que han tenido en el mercado, lo trascendente de la organización. Esto permite alinear un equipo de trabajo o directivos en remoto y establecer los principios clave para posteriores actividades.

2.- Objetivos:

Este apartado se divide en dos puntos importantes. (1) identificar Objetivos para lograr la meta identificada y (2) qué indicadores usaremos para medir si estamos logrando el objetivo.

Normalmente, lo que suelo hacer es que los participantes propongan de manera individual los objetivos que ellos identifican como clave. Votan los 3 más importantes (el resto se retiran del marco de trabajo).

Y sobre estos 3 objetivos, repiten el mismo proceso, pero con los indicadores que se van a medir. Una vez compartidos los indicadores, se votan los que se consideran más importantes.

Es clave valorar que no hay una respuesta óptima. Buscamos soluciones sistémicas. Esto es importante gestionarlo desde el punto de vista de los líderes que quieren tener la última palabra.

3.- Situación actual

En este apartado, los participantes tienen que identificar hallazgos basado en un modelo para agruparlos. Recomiendo generalmente usar el modelo de las 7S de McKinsey. En mi caso, suelo tener una versión reducida, de 4 agrupaciones, que me funciona muy bien: 1. perspectiva de los clientes, 2. Procesos, funciones y sistemas de la organización, 2. capacidad / recursos  y Skills y por último 4.Valores compartidos y Motivación de la organización. El facilitador podría pactar otros criterios con el equipo.

Los participantes tienen que identificar, individualmente, hallazgos agrupados según los siguientes criterios:

  • Aspectos que nos alejan de nuestra meta
  • Fortalezas que nos facilitan llegar a nuestra meta

Los participantes usarán el dot voting para votar aquellas 3 debilidades y 3 fortalezas que les parezcan más significativas para lograr los objetivos. Nunca deshecho el resto, lo suelo poner aparte, por si hay algún aspecto con bastantes votos que los participantes quieran rescatar.

Esta actividad es importante dentro de un taller con el objetivo de alinear un equipo de trabajo o directivo en remoto ya que se comparten las perspectivas de cada participante sobre lo que perciben que está sucediendo. Se suelen producir muchos momentos «aha».

Si detecto que el equipo está un poco bloqueado y si el tiempo me lo permite, puedo incluir una dinámica para reescribir los desafíos seleccionados. Para ello, les indico a los participantes que redacten los desafíos en modo de preguntas de oportunidad usando el enfoque de “¿Cómo podríamos ..?. Por ejemplo, si un desafío es “tenemos personas con mucha especialización y ello provoca cuellos de botella” se podría reescribir como “¿Cómo podríamos crear un entorno multifuncional para eliminar los silos?”. Esta dinámica es muy potente ya que las preguntas nos facilitan entrar en un estado de buscar soluciones alternativas.

4.- Opciones/Alternativas

Los participantes identifican qué opciones se pueden llevar a cabo para superar los desafíos identificados o potenciar fortalezas para poder alcanzar la meta. Se agruparán del mismo modo que en la dinámica anterior.

Las personas votan las actividades para identificar las que consideran que más aportan desde una perspectiva del equipo. Como facilitador, les suelo sugerir que, para votar, piensen en aquellas opciones que lleven el menor esfuerzo, pero con el mayor impacto.

5.- Plan de acción

Para mí es la actividad clave. Sin llamada a la acción los talleres tienen poca utilidad.

Por tanto, partiendo de las opciones más votadas, cada participante escribe sus ideas sobre cómo materializarlas. Es decir, qué experimentos o actividades de cambio se van a ejecutar.

Posteriormente se votan y se quedan aquellas con más aceptación. Con esta información, el equipo discute sobre quién debiera de ser el responsable. Cuando habría que realizarlas y qué recursos se requiere.

En esta actividad, el facilitador juega un papel clave para concentrar las opiniones de todos y facilitando que todos participen.

Normalmente antes de iniciar el plan de acción, suelo recordarles el propósito, las objetivos e indicadores para centrar bien el plan de acción. En el fondo, esta información representa el hilo conductor de un taller de alineamiento de un equipo de trabajo o directivos.

Otro aspecto importante, es que los participantes tienen que identificar cómo van a dar seguimiento al plan de acción. De manera general, para facilitar esta parte, suelo preguntarles si ya tienen eventos en la actualidad en el equipo de trabajo o directivo. Eventos de seguimiento o de otra naturaleza, en cuyo caso les propongo si es factible usar ese o eso(s) evento(s) para darle seguimiento. Por último, les pido si hay algún voluntario para hacerse responsable de que el seguimiento se lleve a cabo.

6.- Qué te llevas

Por último, cada participante reflexiona individualmente sobre qué se lleva de la sesión, lo ideal es que todos puedan dar su perspectiva. Este tipo de cierre suele ser muy significativo. Siempre que hay intercambio de perspectiva, siempre se producen momentos «aha».

Conclusiones

Si tuviera que indicar aquellos temas que más me han ayudado a la hora de hacer los talleres en remoto, tendría que mencionar los principios que he indicado anteriormente. A partir de aquí, lo que recomiendo es probar, en mi caso los resultados han sido muy buenos. Suelo realizar muchas actividades de este tipo, de revisión de estrategias y acompañamiento a equipos directivos. Incluso talleres de kickoff de proyectos y soluciones. Es clave para lograr alinearlos, tener un hilo conductor en el taller que les permita llegar a acciones concretas.

Normalmente suelo incluir una actividad inicial que llamamos WarmUp. Es donde explicamos como usar de la herramienta MIRO, al menos en los aspectos más básicos. Incluso hacemos alguna actividad sencilla para que los participantes aprendan a escribir en un postit, a usar los dot votings y mover elementos. Esta actividad la hacemos con propósito, por ejemplo, haciéndoles preguntas a modo de rompehielos.

Si estás participando en procesos de cambio, espero que este artículo sea de inspiración para logar alinear un equipo de trabajo o directivo en remoto. Ya no importa si cada uno está en un lugar o ciudad diferente. ¡Hay solución!

De estos temas suelo compartir en los talleres de Lean Change Management, por lo que si tienes interés te invito a que mires nuestros próximos eventos en Este Link

Autor: Jose Antonio Ortega

La increíble teoría de la latencia de las decisiones

Ahora que la parte dura de la pandemia del COVID-19 ha pasado y se han producido desconfinamientos, es probable que en algún momento desees volver a cenar a un restaurante con tu pareja, tu familia o un amigo.

Durante este tiempo en casa has tenido la oportunidad de revisar los mejores restaurantes de la ciudad y has hecho una lista ordenada por puntuación, reseñas y tipo de comida.

En el centro de la ciudad, Ángela está disponiendo todo para poder recibir a nuevos comensales cumpliendo con todas las medidas de seguridad.

Su equipo está muy contento de volver al trabajo y han preparado todo para hacer que todo esté perfecto.

Están muy emocionados. Las neveras están llenas. Todo está listo.

El día señalado nos dirigimos al restaurante. Tomamos asiento y revisamos la carta, que es un poco reducida. Elegimos nuestro plato y pedimos una botella de vino mientras esperamos.

En cocina, el equipo es uno de los mejores de la ciudad. Son capaces de preparar los 14 platos de la carta en tiempo record y han practicado durante la última semana para asegurar que todo está perfecto.

Sin embargo, para asegurar que el servicio cumple con todos los requerimientos sanitarios, cada comanda debe de ir primero a la mesa de Ángela, que se encarga de revisar las peticiones de los clientes una a una y decidir que platos se prepararan y quien se encargará de hacerlos.

Durante la primera hora las cosas funcionan. Un poco lentas, pero funcionan.

Sin embargo, cuando los clientes ya completan un tercio del aforo del local, las notas empiezan a acumularse en la mesa de Ángela mientras ésta tiene que acudir a cocina constantemente a revisar quien está disponible y cual es el siguiente plato que puede entrar en función de los requerimientos que hay que cumplir.

La primera noche es un desastre.

La segunda también.

Durante la tercera el equipo consigue mantener el servicio a duras penas. Los clientes dejan malas reseñas en Internet y empieza a correrse la voz.

Ángela toma una decisión.

A partir de la seiguiente semana contrata un equipos de compliance que se encargará de proporcionar capacidad a la toma de decisiones. Sin embargo, el resultado es incluso peor.

El nuevo equipo de compliance decide que el problema es la necesidad de tiempo para la toma de decisiones.

Así que a partir de ahora los clientes tendrán que avisar con al menos 24 horas de antelación de lo que desean comer para que el equipo tenga la oportunidad de organizar la comida.

Problema resuelto.

¿Problema resuelto?

Este problema es un problema clásico donde la toma de decisiones afecta a la agilidad de negocio, a pesar de tener una capacidad tecnológica y un equipo altamente preparado.

En el informe CHAOS de 2018, un referente en la estadística de gestión de proyectos, Standish Group introdujo la teoría de latencia de las decisiones para explicar por qué aparentemente organizaciones preparadas para enfrentar problemas de negocio de forma ágil tenían altos niveles de fracaso y de rotación de personal.

La latencia de las decisiones es un factor decisivo para valorar la agilidad de una organización”

La teoría propone que esos niveles de fracaso están más relacionados con la latencia -espera- que se produce entre las decisiones que con la capacidad de la organización de hacer frente a los problemas.

En una simulación avanzada, Patrick Steyart, creador de Okaloa FlowLab, explica como lidiar con este tipo de latencias usando Upstream Kanban y también en el libro Essential Upstream Kanban (Descarga gratuita tras introducir datos).

En 2017 también publiqué un artículo sobre el uso de Upstream Kanban para tratar este problema.

La latencia de las decisiones -también ironizada como parálisis por análisis- es un factor decisivo para valorar la agilidad de una organización.

En el caso de Scrum, se resuelve teniendo vectores de responsabilidad única, tales como el Product Owner para las decisiones de negocio, que sólamente por existir pueden agilizar un dominio de negocio o un producto, produciendo un retorno de inversión mucho mayor que su coste.

También el tener un equipo de desarollo que pueda tener una cierta independencia en la toma de decisiones técnicas o una librería de diseño para la creación de la experiencia de usuario son inversiones fundamentales para permitir que se pueda crear valor hacia el cliente.

Es precisamente cuando se trata de tomar acciones que cambian la latencia de las decisiones cuando las organizaciones presentan más resistencia a estos cambios. En general, reducir el número de decisiones puede llevar a que determinados roles y funciones queden totalmente obsoletos.

Por ejemplo, abordar decisiones en entornos de complejidad usando Cynefin puede destripar de autoridad a un manager cuya función es precisamente el controlar las decisiones que se toman.

Cuando un Scrum Master es empoderado para acceder a la organización y provocar cambios que afectan -y por tanto suboptimizan- al resto de la organización, pueden ser vistos como una amenaza. Sin embargo, reducir o incluso eliminar totalmente determinados estratos de decisión ayuda a reducir costes y mejorar la entrega.

Y esto no sólamente aplica a la creación y gestión de productos. Una organización que permite a sus empleados comprar cosas necesarias para su trabajo de un coste no superior a 150€ puede reducir eliminar la mayor parte de los sistemas de control y aprobación de gasto. Esto es lo que en Lean se conoce como waste.

Los estados por los que debe pasar una decisión pueden visualizarse y gestionarse utilizando Kanban.

Aquellos que somos fans de chefs Alberto Chicote o Gordon Ramsey podemos visualizar el impacto sistémico que tiene en un restaurante que el propietario decida meterse hasta la cocina a tomar decisiones que no le corresponden.

Esta analogía sería válida para comparar al equipo de compliance de Ángela con los gerentes intermedios de cualquier organización.

¿Significa eso que las personas deben operar con absoluta libertad y desprecio hacia las normas de la organización en un entorno de anarquía?
​
En absoluto.
​
Precisamente es en estos entornos donde tener una serie de reglas en torno a metas concretas de negocio las que nos permiten alcanzar nuevas cotas de competitividad y agilidad.
​
*Standish group ha creado un Free Membership donde se puede tener acceso gratuito a los reportes hasta 2015, aquí el link.

Cursos que te pueden interesar…

Professional Scrum Product Owner Advanced

Professional Agile Leadership

  • « Ir a la página anterior
  • Ir a la página 1
  • Ir a la página 2
  • Ir a la página 3
  • Ir a la página 4
  • Páginas intermedias omitidas …
  • Ir a la página 41
  • Ir a la página siguiente »

Barra lateral principal

Jeronimo Palacios & Associates

Somos una consultora boutique especializada en la creación y desarrollo de productos digitales con un enfasis en metodologías ágiles.

Búsqueda

Cursos oficiales certificados

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2022 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad