Gestión Lean del Cambio

O de cómo puedes empezar a convertirte en un Agente de Cambio extraordinario

“Si realmente quieres entender algo, trata de cambiarlo” - Kurt Lewin -

Hace poco tuve el privilegio de asistir al curso de Lean Change Management con mi buen amigo Luis Mulato de AgileSpin, con quien además he tenido la grandiosa oportunidad de liderar varias de las iniciativas más importantes que hemos emprendido en la Comunidad Ágiles Colombia, a manera de experimentos de los que precisamente hemos obtenido un aprendizaje fantástico.

Si estás involucrado en procesos de transformación quiero invitarte a tomar el curso con Lucho, con quien espero facilitarlo algún día. Además de tener un excelente sentido del manejo del tiempo y foco en los temas principales de la materia, Lucho es poseedor de un sentido de recursividad y creatividad y de una perspectiva abierta que, combinados con su amplia experiencia – conocedor  de una extensa gama de prácticas, marcos de trabajo y herramientas ágiles – logra despertar en los participantes, nuevos Agentes de Cambio, un interés inusitado durante los dos días del taller.

Pues bien, Lucho abre la discusión diciéndonos que los modelos de gestión y de cambio actuales no son suficientes para lograr una transformación exitosa en las organizaciones del siglo XXI o de los tiempos del VUCA* como él las llama. Lean Change Management o LCM nos muestra cómo descubrir una cultura y cómo alterar la dinámica del trabajo por objetivos. En la práctica, LCM se basa en la retroalimentación y nos provee de herramientas para validar el aprendizaje. ¿Cómo hacerlo? ¡Si hubo un cambio de comportamiento, el experimento tuvo éxito!

Acto seguido, Lucho nos presenta una suerte de Manifiesto por el Cambio – o Manifiesto Ágil para la gestión del cambio – a la usanza Lean, donde valoramos:

Halar sobre empujar

Contacto sobre tecnología

Orgánico sobre prescriptivo

Crecimiento sobre perfección

En este enfoque propuesto por Jason Little, las personas involucradas en el cambio participan sí o sí en el experimento, en su cocreación; además, intervienen en la toma de decisiones y son parte integral del equipo de cambio. En los términos que lo caracterizan, Lucho nos dice que Lean Change Managment  es People-Driven.

Como con otros elementos de la mentalidad Ágil, LCM promulga por la generación de una cultura de mejora continua para el cambio. Bien sabemos que entre más individuos haya, más caótico es el cambio. En la práctica, no podemos hacer que una persona cambie; pero podemos generar las condiciones necesarias para que cambie. Para mí, esta fue una de las grandes conclusiones del curso.

Es un hecho: el cambio comienza con uno mismo. Primero el mindset, tu mentalidad, y entonces empiezas a cambiar como individuo. Si no triunfas en este apartado, no sigas adelante. Si lo logras, a tu ritmo, con disciplina, entonces estás preparado para hacer parte del cambio de tu grupo o equipo interno: tu grupo familiar, tu equipo de trabajo. A partir de allí, las posibilidades son infinitas: puedes cooperar en o, mejor aún, liderar el cambio de la organización para la que trabajas y hacer parte del cambio del ecosistema, es decir, de la comunidad que habitas, de un pueblo o de toda una sociedad.

Ya he dicho insistentemente en los últimos años que la agilidad no es un estado final. Y también que la Agilidad no es sobre Ágil, es sobre Cambio. Y LCM nos señala el camino a seguir en ese sentido. El cambio no se hace y no ocurre a puerta cerrada y no lo logra un grupo de individuos cual conciliábulo, sin involucrar al resto de la organización.

Ahora bien, no todos los cambios son iguales. El cambio en las grandes organizaciones causa más disrupción y esto aumenta la incertidumbre y la complejidad. Cuando se implementan múltiples cambios, hacemos un trazado de la incertidumbre y complejidad relativas entre cambios.

Finalmente hemos entendido que la “mejor práctica” es la que tú mismo creas basado en los experimentos que realizas en tu organización. Y con el tiempo, tú mismo aprenderás lo que funciona y lo que no, dados los atributos específicos de tu organización. ¡Eso es lo hermosamente simple de la Agilidad!

Sobre el Ciclo de Gestión Lean del Cambio

Un modelo no lineal, basado en la retroalimentación, para gestionar el cambio

No puedo finalizar esta primera crónica sobre LCM, de la que espero sea una jugosa serie de historias, sin explicar brevemente de qué se trata lo que su autor denomina el Ciclo de Gestión Lean del Cambio.

El mismo Jason Little se pregunta en este apartado si debería llamar a esto un modelo, un marco de trabajo, un método o un proceso, entre otros. Al final decide que no le preocupa la etiqueta, a mí tampoco, así que te dejo en libertad de formar tu propia opinión.

• Hallazgos: antes de planear cualquier cambio, necesitas entender el estado actual de la organización. Para hacerlo hay muchas herramientas, evaluaciones y modelos que puedes aplicar para obtener esos Hallazgos. Por ejemplo, la evaluación ADKAR® o reuniones informales tipo Café Lean.
• Opciones: una vez que consigas suficientes Hallazgos para comenzar a planear, vas a necesitar Opciones. Estas tienen un costo, un valor y un impacto y usualmente incluyen una o más hipótesis y beneficios esperados. Más adelante, cuando estés listo para introducir un cambio, convertirás estas Opciones en Experimentos.
• Experimentos: en este punto ya has aprendido bastante del estado actual de las cosas y has considerado diversas Opciones. Ahora es tiempo de introducir un cambio y ver si funciona como pensaste que lo haría.

Los Experimentos, a su vez, tienen un su propio ciclo:

• Preparar: es la etapa de planificación del Experimento. La clave acerca de esta etapa es que en ella solo tienes supuestos sobre el cambio, tus supuestos. Aquí es donde validarás tu enfoque con las personas que se verán impactadas por el cambio antes de implementarlo.
• Introducir: aquí comienzas a trabajar con las personas afectadas  por el cambio. Si llegaste a este punto, el cambio está en proceso. Como con todo trabajo en progreso, debes buscar el límite apropiado de cambios que quieras introducir en simultáneo.
• Revisar: compruebas los resultados del Experimento. En este punto ya habrá pasado el tiempo que proyectaste como necesario para que el cambio se consolide.

Como siempre, si el experimento no arrojó el resultado que querías o si lo produjo a medias, no desfallezcas. ¡Estas cosas suelen suceder! Simplemente te levantas al día siguiente y comienza el ciclo nuevamente. Las posibilidades son infinitas.

¿Quieres saber más?

Para saber más sobre Lean Change Management, leer el libro de Jason Little y descargar material valioso para iniciar tus experimentos de cambio, ve a leanchange.org. Pero mi humilde recomendación es que tomes el curso con Luis Mulato. ¡Es el primer gran paso que puedes dar para convertirte en un Agente de Cambio extraordinario! Además puedes conseguir un gran grupo de amigos y colegas que te ayudarán en la travesía.

Y este es mi llamado a la acción muy especial. Piensa en tu Mínimo Cambio Viable o Mínimo Cambio Deseable. ¿Qué vas a hacer para conseguirlo? Déjamelo saber en el foro.

*VUCA, por las siglas en inglés de Volátil, Incierto, Complejo, Ambiguo

Escalar Para Qué

La pregunta no es o no debería ser ¿cómo escalar Ágil? Más bien es un asunto de ¿por qué escalar Ágil? Pero antes de entrar en materia, quiero recordarles algo que he mencionado en varios escenarios: antes de escalar Ágil como solución, pensemos en ‘desescalar’ el problema.

El asunto con el escalamiento es que se nos está convirtiendo en una cuestión de cuál método usar y no en lo que verdaderamente importa a las Organizaciones: ¿por qué escalar? Debemos ir a la causa raíz, el problema detrás del problema, es quizás una de las pocas vías razonables que tenemos para encontrar una razón de peso para escalar Ágil y tal vez un buen camino a seguir.

Los marcos de trabajo o los métodos de escalamiento proporcionan herramientas que ayudan en el proceso, pero me parece que apenas si nos permiten lograr que los equipos realicen correctamente el trabajo y que lo hagan de manera integrada. Pero hacer correctamente el trabajo correcto es otra cosa.

Cuando empezamos la transformación a o la adopción de Ágil, lo hacemos provistos con el Manifiesto Ágil y quizás Scrum o Kanban, acompañados de algunas otras prácticas y el pensamiento Lean. Tenemos la férrea esperanza de que el área de TI no necesite nada más allá de algunas otras herramientas Ágiles que hoy ya podemos brindar como “paquetes” (BDD, Refactoring, User Story Map, entre otras).

Luego nos damos cuenta que, contrario a lo que sucedía con el enfoque tradicional, el Ágil es un pensamiento que debe tener un lugar en cada uno de los asientos de la empresa y en cada lugar que habitan sus miembros. Entonces, cuando queremos salir fuera de la oficina de TI, hacia el resto de la Organización, nos olvidamos del Manifiesto y nos aprovisionamos con todo tipo de artilugios ‘agilísticos’ como si se tratara de la cruzada definitiva, la última cruzada de los agilistas o algo similar.

Pensamos más en el número de equipos y de personas a escalar que en el Valor y en el número de productos o servicios que debemos desarrollar.

No todas las corporaciones necesitan escalar Ágil. Algunas solo necesitan Ágil para entregar software con Valor de manera temprana y frecuente. No se trata de que tan Ágil soy comparado con mis vecinos, más bien de lo que se trata es de si voy correctamente en el camino Ágil correcto y de lo que debo hacer para mantenerme allí.

En definitiva, lo que tenemos que responder, mientras seguimos encontrando formas mejores de hacer las cosas, tanto por nuestra cuenta como ayudando a otros, es si nuestra Organización o la que estamos acompañando en su camino Ágil ve el tiempo de respuesta como un diferenciador crítico para sus consumidores finales o ante sus competidores.

Pero aun más importante es si queremos escalar la forma cómo pensamos acerca de las personas y sus interacciones o solo la forma de desarrollo de nuevos productos y servicios. ¿Queremos escalar el nivel de motivación y felicidad de nuestros compañeros de trabajo y colegas o solo su productividad y eficiencia? Y si se trata de ambas cosas, ¿lo estamos haciendo? Más aun, ¿lo estamos haciendo de una manera correcta?

Otros porqués incluyen:

• ¿Qué tan innovador queremos que sea el portafolio de la Organización?
• ¿Qué tanta incertidumbre hay en nuestros esfuerzos de desarrollo y, por extensión, en nuestro futuro?
• ¿Queremos innovar o simplemente realizar el mejor mantenimiento posible a lo que hacemos y proporcionamos?
• La estocástica también juega un papel importante. ¿Qué tan aleatoria es la demanda de nuestra Organización?

Finalmente, ¿estamos planeando o ejecutando ya una metempsicosis organizacional, en el sentido de transformación, a la que podamos sumar la adopción de Ágil a gran escala? ¿O simplemente queremos vender o implantar una marca más por asuntos de moda que por aspectos fundamentados en la ingeniería y en las prácticas de la industria?

¿No será que estamos cayendo una vez más en el uso de un gran número de métodos o marcos de trabajo y sus variantes, con diferencias poco entendidas e incrementados artificialmente y que además carecen de evaluación y validación experimental creíble? Eso ya nos sucedió, de allá venimos, de metodologías y prácticas inmaduras que obstaculizaban gravemente la ingeniería de software, en particular, y el desarrollo y entrega de productos y servicios con Valor, en general.

Otro asunto, riesgoso y de mayor impacto para la Organización, es tratar de escalar sin haber terminado de construir los cimientos o cuando todavía hay disfunciones Ágiles en el nivel más básico. En ese caso, lo único que lograremos escalar serán precisamente los problemas, no las soluciones. Pero este será tema de otro artículo.

Escalemos la entrega de Valor, no solo el método o marco de trabajo que queremos usar.

Ecce homo o el Ágil es algo que eres

Ecce Homo restaurado de Cecilia Giménez

En el mundo moderno, las personas profesionales tienen una preocupación, con visos de ansiedad, vinculada a su ADN, sobre todo quienes trabajan en o alrededor de compañías de TI: ser competitivas, exhibir un alto desempeño y lograr metas en plazos cortos. Las actividades que realizan y los resultados, productos o servicios generados, deben ostentar estándares elevados de calidad. Este escenario sube el nivel de estrés de quienes lo intentan día a día, aunque también acentúa el grado de satisfacción cuando se alcanzan esos objetivos.

Es precisamente bajo esta atmósfera donde el enfoque ágil presume de sus incontables beneficios. El movimiento Ágil, que no es una metodología, nos permite encontrar y poner en práctica alternativas a la gestión tradicional de personas, proyectos y organizaciones. Esta perspectiva Ágil ayuda a los equipos a responder de manera oportuna a la poca o incierta predictibilidad a través de cadencias de trabajo incremental e iterativo y de la retroalimentación empírica.

Este modelo de desarrollo repetitivo o de ciclos de trabajo abreviados, también nos habilita a las personas y a los equipos para ser cada vez más expertos en cada uno de los aspectos de la construcción de productos. En el caso de la Ingeniería de  Software, hablamos de los requisitos, diseño, programación, pruebas, integración, etcétera. Pero este enfoque puede aplicarse en muchos otros entornos de producción y operación, una oportunidad que no teníamos con el modelo tradicionalista en Cascada, donde solo había una única  ocurrencia para hacer las cosas.

Esta evolución de la eficacia en el trabajo relacionada con proyectos de desarrollo sistémico es notoria y nos permite, a su vez, ofrecer una mayor garantía de calidad y de cumplimiento con las fechas límite, aunque surgen algunos efectos colaterales de la aplicación del modelo: nos volvemos menos predictivos (¡bueno, tampoco es que antes fuéramos altamente predictivos!), se acaba eso de culpar a alguien más si las cosas no salen bien y el hecho de que Ágil requiere mucho más compromiso y esfuerzo (¡aun a ritmo sostenido!) de todos los involucrados.

Ágil es algo que eres, las prácticas y los frameworks son algo que usas

Dentro de esos innumerables beneficios de la estrategia Ágil encontramos que las características más importantes del producto reciben la más alta prioridad y que incrementos funcionales del producto se entregan desde temprano y frecuentemente; además, las prácticas y marcos de trabajo livianos que acompañan el enfoque simplifican en grande el flujo de trabajo a la vez que solo se produce la documentación necesaria y suficiente para facilitar el control del producto por parte del usuario o cliente; por último, mi beneficio favorito de este conjunto, todo esto conduce a esa eficiencia y eficacia que mencionaba al principio, lo que a su vez confluye en equipos con personas altamente motivadas y felices que exhiben un alto desempeño, sin la carga de estrés impuesta por los métodos antiguos.

Cómo se logra esto es otro asunto pero son esenciales para ello la comunicación y la colaboración no solo entre los miembros del equipo sino con las personas del entorno, los interesados. También es importante que apliquemos la filosofía Ágil donde y cuando genere valor, aunque no se me ocurre en este momento un escenario donde esto no sea posible. No se trata solo de usar Scrum, Kanban o Lean, SAFe o Nexus, o de hacer retrospectivas por hacerlas, que apenas son artefactos y comportamientos visibles, esa porción de la cultura que nos permite hacer Ágil.

Se trata es de entender y practicar las formas de racionalizar y las estructuras cognitivas de elementos como la comunicación cara a cara, la simplicidad, el compromiso, las entregas incrementales de producto funcionando con valor, la calidad y la satisfacción del cliente, entre muchos otros; pero más en el fondo o en la base, este enfoque es acerca de cultivar y experimentar continuamente valores y creencias relacionados con las personas y sus interacciones, el coraje, el respeto, la inspección y la adaptación  permanentes, la transparencia, la respuesta a los cambios constantes y tantos otros elementos que constituyen eso que conocemos como Manifiesto Ágil, es esa otra porción de fondo de la cultura que nos permite Ser Ágil.

Ágil significa reemplazar la predictibilidad falsa por la eficiencia

Las organizaciones que han incorporado estos paradigmas ágiles, por su parte, entienden que las personas experimentadas, con amplias habilidades en la resolución de problemas y en el mejoramiento de procesos, son extremadamente valiosas para hacer realidad la visión organizacional. Estas compañías reconocen que el costo de desarrollar personas con estas habilidades es grande, especialmente si quieren involucrarlas y comprometerlas en la mejora continua de procesos. Por eso no solo les proporcionan las herramientas y los recursos necesarios para entrenarse continuamente sino que también disponen de agentes de cambio que los ayudan a potenciar sus destrezas.

De esta manera es que hemos abierto nuestras mentes para enfocarnos en las personas y nuestras interacciones con ellas y cómo colaboramos con nuestros clientes y en cómo pensamos acerca de nuestro trabajo y en tácticas que nos descubran el camino hacia la superación perpetua. Nos concierne y nos motiva enfrentar los cambios, nos interesa ser la estrategia, no simplemente apoyarla, somos líderes por naturaleza, pero líderes con el poder de influenciar a otros, no de gobernarlos, nos gusta animar a los demás a que compartan nuestra visión y compartimos la de ellos, no miramos al pasado sino para aprender  y nos hacemos cargo del futuro.

Las reglas del juego cambiaron, ¿te diste cuenta? Déjamelo saber en el foro.

---

Más sobre Filosofía Ágil en:

Cultura Ágil: ese oscuro objeto del deseo

“No puedes guiar el viento, pero puedes cambiar la dirección de tus velas”

De historias de usuario, culturas y del arte de narrar historias

Sobre medir y controlar o de cómo Tom DeMarco admitió su equivocación

Ágil es algo que eres

Agilidad: algunas características intrínsecas

Del triángulo de hierro al triángulo ágil (modificado)

Dueño de Producto, usted ha sido invitado a la Retrospectiva

El Dueño de Producto, ¡ese ilustre olvidado!

Me preguntan por interno si este personaje debe asistir a la ceremonia de inspección y adaptación. Es una buena pregunta, teniendo en cuenta que hay quienes recomiendan que no sea así o que la participación del Dueño de Producto es opcional en la Retrospectiva.

No hay ninguna buena razón por la cual el Dueño de Producto no deba estar en la retrospectiva. Desde la misma guía de Scrum ya sus autores sugieren que debería participar:

"La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint".

Y ya sabemos que el Equipo Scrum se compone de Scrum Master + Desarrolladores + Dueño de Producto.

Pero más allá de esto, no concibo cómo, sin la participación del Dueño de Producto en esta reunión, sea posible que el equipo en pleno se inspeccione a sí mismo para luego crear un plan de mejoras que nunca estará completo sin la intervención de este actor. Por ejemplo, ¿cómo mejorar la comunicación con el entorno del negocio? El resto del equipo no podría definir la mejor estrategia para lograrlo en ausencia del Dueño de Producto.

Algunos dirán que se define la estrategia en la reunión y luego se la comunican al Dueño de Producto, eso simplemente extendería la retrospectiva, con el riesgo de que él "tumbe" las acciones a realizar por cualquier motivo válido.

• ¿Y qué pasa si hay problemas con la salud del backlog? 
• Problemas con la definición de los criterios de aceptación de las historias de usuario.
• ¿El equipo conoce cómo los usuarios realmente usan el producto?
• Problemas con la aceptación del incremento sprint tras sprint.
• ¿El equipo conoce la visión completa del producto, la estrategia de implementación y cómo lo quieren los usuarios?
• ¿Y qué ocurre si el Dueño de Producto no está el tiempo suficiente con el equipo para responder sus preguntas y clarificar las características del producto? O para proporcionar retroalimentación efectiva.

En fin, muchas son las razones para que el Dueño de Producto sí esté en la reunión. Estas que mencioné son solo algunas. En breve, el Dueño de Producto es protagonista principal en esta ceremonia.

Ahora bien, se me ocurren algunas malas razones por las cuales no debería asistir. Las mencionaré brevemente y estableceré alguna razón sólida para no tenerlas en cuenta:

Lo aburrimos con minucias técnicas. Una retrospectiva no es para profundizar en los detalles de lo puramente técnico.

El equipo de desarrollo y el Scrum Master son de un proveedor y el Dueño de Producto es del Cliente. Entonces dónde queda la confianza y, por consiguiente, la transparencia. Si estamos pensando así, todavía nos hace falta mucho de la Cultura Ágil y de liderazgo. En cualquier caso, esta práctica reduciría mucho la transparencia, necesaria a todas luces en un entorno ágil.

No tiene tiempo. ¡Este es, precisamente, un tema a abordar con él en la retrospectiva!

Así lo hemos hecho aquí y nos funciona. Esta es interesante. ¿Y qué tal si lo hacemos de la otra forma (que si asista) y vemos la diferencia? ¿Mejoramos o empeoramos? Seguramente será lo primero.

Esta última es la típica cuestión que se enmarca en el empirismo, es decir, aprendemos de la experiencia, como todo en Scrum. Algo que se resume también en eso de "usar o hacer lo que te funciona". Sin embargo, las razones que expuse al principio y muchas otras precisamente nos han enseñado los beneficios de la presencia del Dueño de Producto en la ceremonia.

Entre otras, pero todas absolutamente son "malas" razones.

En definitiva, el Dueño de Producto sí debería (sí debe) asistir a las retrospectivas, así que adelante. Si como Scrum Master te sugieren que el Dueño de Producto no debe estar en la reunión, te enfrentas a una sintomatología que te indica que falta algo de la base, los valores y principios ágiles, la forma cómo racionalizamos, el fondo de la cultura ágil, más que del mismo Scrum y otras prácticas.

---

¿Y tú, invitas al Dueño de Producto a tus retrospectivas? Déjamelo saber en la sección de comentarios más abajo.