Buscar en Gazafatonario IT

lunes, junio 10, 2019

Las historias de usuario se cuentan con C de Contexto

El Lienzo para Conversar sobre Historias de Usuario

O de la cuarta C de las historias de usuario

Un equipo de producto actúa  o debe actuar como un fabricante, uno que trace la estructura del producto para lograr coherencia. La coherencia supone una interacción entre partes que genera resonancia. A estas partes las llamamos “cosas no ordinarias”. La resonancia, una cualidad de una cosa no ordinaria trazada de manera coherente, incita las reacciones de las personas. Y son esas reacciones las que hacen que las personas experimenten algo extraordinario como algo especial.
Para lograr esa resonancia, es necesario conocer el entorno o contexto donde se ubica cada una de  esas piezas que forman el producto. Las historias de usuario son precisamente cada una de esas partes que componen un producto (de software) y como equipo de producto nos apasiona elaborar productos extraordinarios. Pues bien, una de las secciones del lienzo para conversar sobre historias de usuario (User Story Conversation Canvas), es el Contexto. Quiero ampliar un poco su definición.
Recordemos que una de las formas que toman las historias de usuario documentadas es la muy conocida de las 3 C o CCC, siglas de la aliteración Carta Conversación Confirmación. ¿Qué sucede si a esta forma le agregamos una C? La C de Contexto. Veamos.
Del lienzo para Conversar sobre historias de usuario
Entender el entorno en el cual transita o existe una historia de usuario en particular y un producto o servicio en general es crucial a la hora de desarrollar esa historia o producto. ¿De dónde viene la historia? ¿La necesidad? ¿Cuál es el problema que intentamos resolver? O mejor aún, el problema detrás del problema, la causa raíz. Las decisiones que tomemos a partir de este entendimiento tendrán un impacto en el futuro de muchas personas, incluso modificarán su modus vivendi.
Algunos elementos a considerar en todo contexto de una buena historia de usuario son:
  • Necesidad origen
  • Escenarios de uso de la historia
  • Dominio del negocio, qué áreas del negocio usan o se impactan por la historia
  • Reglas del negocio que afectan la historia
  • Épica origen. No todas las historias provienen de una épica en particular, pero si es así, es bueno conocerla.
  • Alcance de la historia
  • Hipótesis, que queremos probar con la historia
  • Dependencias de la historia. Para aprender a independizar historias, pueden ver el capítulo dedicado al criterio Independiente de las historias de usuario, previamente en este libro.
  • Restricciones adicionales, de diseño, de instalación y puesta en marcha, de mantenimiento, de distribución, de empaquetamiento, entre otras.
Más sobre el Contexto de las historias de usuario
En la vida cotidiana, cualquier cosa existe en un contexto de relaciones con cosas fuera de sí misma. Eso aplica también a las historias de usuario. Una de esas “cosas” con las que interactúan las historias de usuario son sus consumidores. Y esta interacción ocurre vía interfaces, que a su vez operan en un entorno.
El usuario es quien valora el producto, es quien se beneficia del producto. Además, un consumidor puede ser una persona, otro producto u otro sistema que interactúa con nuestro producto. El lienzo para conversar sobre historias de usuario tiene toda una sección para hablar de personas, cuando estas son las consumidoras del producto. En esta sección de contexto bien podemos incluir a esos otros productos o sistemas que tengan interacción con el nuestro.
Así es que tenemos que pensar en las interfaces necesarias para que los usuarios interactúen con el producto, en la forma cómo el producto recibirá estímulos, por ejemplo datos, del exterior y cómo sus partes recibirán o enviarán estímulos entre ellas, las historias de usuario, y al exterior.
Una de las formas de conocer el contexto es realizar entrevistas con los usuarios o sus representantes, un Dueño de Producto, por ejemplo. Es la parte de Conversación de las historias de usuario, la cual, ya sabemos es la más importante: las historias de usuario son un instrumento para conversar, ojalá cara a cara. De esta manera entenderemos mejor los modelos de negocio, la industria, el ambiente sobre el que se “desplazará” nuestro producto durante su vida útil. Para efectuar estas entrevistas, seguimos un protocolo diseñado para comenzar a hablar de un tema en los propios términos de las personas a quienes entrevistamos, pero esto de las entrevistas será asunto de otro artículo.
Algo importante es pensar en la información compartida entre las partes del producto y de este con su entorno. También, en la trayectoria que tomarán esos datos, a dónde irán primero, y de allí hacía dónde y así, hasta finalizar su travesía. Eso nos da contexto. Al considerar este tipo de eventos, nos anticipamos a la dirección que tomará la historia de usuario y crearemos expectativas entre sus consumidores.
Las historias de usuario son (deben ser) independientes unas de otras, pero deben integrarse acorde en el producto final para que este tenga coherencia. Esta coherencia describe qué tan bien las historias de usuario de un producto encajan entre sí. Algunas herramientas visuales nos ayudan a entender mejor el contexto de las historias de usuario y del producto en general:
  • Un mapa de producto, como un mapa de historias de usuario (user story map)
  • Un lienzo de producto, como un product vision board o el mismo business model canvas
  • Una caja de producto (product box)
  • Un modelo de dominio (del negocio)
  • Una matriz de trazabilidad (la podemos seguir usando con pensamiento ágil)
  • El lienzo para conversar sobre historias de usuario (user story conversation canvas). De hecho, todas las secciones del lienzo nos permiten visualizar distintos aspectos del entorno en el que transita una historia de usuario y el producto del cual es componente.
Que quién es el responsable de trazar el contexto, entenderlo, asegurarse de que sea una parte de la conversación cuando de desarrollar historias de usuario se trata: ¡el equipo de producto en pleno! Eventualmente tendremos que recurrir a otras personas, conocedores del negocio, usuarios finales o consumidores, expertos del dominio, etcétera.
Así es que, equipo, al considerar tu próxima historia de usuario, preguntémonos cuál es su contexto.

Referencias
The User Story Conversation Canvas
En español:
En inglés:

El libro Historias de Usuario: una visión pragmática:

Apuntes sobre historias de usuario:

The Soul of Design
Austin, Robert. The Soul of Design: Harnessing the Power of Plot to Create Extraordinary Products. Stanford University Press. ©2012 by the Board of Trustees of the Leland Stanford Junior University.

miércoles, abril 10, 2019

La caducidad del Scrum Master… y por extrapolación del coach ágil



El 10 de abril de 2019 un grupo de contactos de la comunidad Ágiles Colombia revivió este debate en el que yo no participaba quizás en los últimos cinco años. Hablamos de la “fecha de vencimiento del Scrum Master”, de la madurez del equipo, de si el Scrum Master agrega valor o no. Varios y distintos puntos de vista, una discusión con respeto y apertura, tengo que decirlo, lo que muestra que, de alguna manera, hemos madurado y que estamos aprendiendo a soportarnos, que hay apertura, y que ya no somos tan políticamente correctos. ¡Eso es bueno, creo!

Esta es mi opinión, ni más faltaba, soportada en mi experiencia:

Quiero empezar por dejarlos con la siguiente reflexión: llegar a considerar esto (que en algún momento no se requiere el Scrum Master) quiere decir que el desarrollo del equipo tiene un “techo”, es decir, un nivel máximo (de madurez). Algunos dirán que el equipo (de producto) y el Dueño de Producto pueden seguir evolucionando por sí solos; quizás sea posible, ¿pero hasta qué nivel? El equipo tiene una tarea principal y es precisamente el producto, la entrega de valor.

Al considerar este escenario, estamos diciendo que el así llamado mejoramiento continuo tiene un límite. Que en algún momento del tiempo no necesitaremos mejorar más, que llegamos a un nivel de madurez “non plus ultra”, que somos los más más, los que todo lo pueden y no hay nada ni nadie más allá.

Yo estoy hablando del rol, pero no veo al equipo “distribuyéndose” este rol de Scrum Master, en principio “as per Scrum guide”, entre sus miembros. El equipo tiene sus propios retos, inherentes a su papel, hablo de todo eso en lo que confluye la excelencia técnica y, sobre todo, en la entrega continua de producto con valor.

Quizás son dos cosas muy distintas, pero no veo un equipo de fútbol, aun uno de Rugby, o a una orquesta sinfónica, todos conformados por grandes estrellas en sus respectivos campos, jugando o interpretando sin el entrenador adecuado.

Lo escuché por primera vez de Ángel Medinilla: el Scrum Master vive en el futuro del equipo. Le compré la idea. Bueno, ¡en realidad, la tomé prestada! La promuevo en mis equipos y en las organizaciones con la que colaboro habitualmente. Me ha dado buenos resultados. Vivir en el futuro quiere decir que está pensando en cómo llevar a su equipo al siguiente nivel y en cómo preparar a la organización para ese “nuevo” y mejorado equipo. Mejoramiento continuo.

También sabemos que cuando una persona entra o sale del equipo, el resultado no es el mismo equipo, se trata de un nuevo equipo. Aun para equipos de alto desempeño, equipos maduros, equipos en el nivel desempeño del modelo Tuckman, aun para esta clase de equipos, el esfuerzo de “volver” a integrarse los hará regresar de nuevo a la etapa de formación. Y este impulso seguramente seguirá requiriendo de un gran Scrum Master cuyo foco sea llevar nuevamente al equipo a su estado de madurez más alto conseguido.

Voy a ir más allá. Hemos establecido ampliamente que el Scrum Master, al menos uno extraordinario, juega en distintas posiciones:

1.    Coach
2.    Maestro
3.    Líder servicial
4.    Gestor
5.    Agente de cambio
6.    Mentor
7.    Facilitador

Entre otras no menos importantes. Distribuir cada una de estas funciones en el equipo no es algo de poca monta y puede llegar a ser algo perturbador para los miembros de ese equipo. ¿Una por cada miembro del equipo? ¿Y qué pasa si es un equipo de menos de siete personas?

¿Y las tareas mundanas?

Veamos otro contexto:

En algún momento, abstraerse de las complejidades propias de un producto y dedicarse a preparar una retrospectiva puede ser un aliciente, una “pausa activa” para uno o dos miembros del equipo de producto. Pero no veo a largo plazo los beneficios de implementar tal práctica. Necesitamos a los miembros del equipo concentrando todo su esfuerzo en la generación de valor de manera frecuente para la organización.

Sí, ya sé, algunos van a decir que estoy tratando a la retrospectiva como algo frívolo, “terrenal”. ¿Y no es de eso de lo que estamos hablando cuando hablamos de jubilar al Scrum Master? Mirémoslo desde otro ángulo: a la luz de un equipo maduro, que seguramente estará enfrentando problemas de alta complejidad y de mucha incertidumbre, preparar y realizar un evento de Planificación o una Retrospectiva parecerá algo profano y hasta superfluo.

Pero no se equivoquen: no, los eventos Scrum no son para nada momentos vanos, ni siquiera para un equipo realmente “avanzado”. Mucho menos lo son la gran cantidad de otros eventos, sesiones, ceremonias, reuniones, actividades y prácticas que emergen alrededor del desarrollo de productos con Scrum y, por extensión, con pensamiento ágil o lean.

Sobre VUCA y Cynefin

Ah, y ya que toco este no menos peliagudo asunto de la complejidad y la incertidumbre, ¿qué hay acerca del mundo VUCA que habitamos hoy? ¿Qué hay acerca del caos que nos consume? Es en estos ambientes de altísima volatilidad y ambigüedad en los que se necesitan soluciones expeditas, prácticas y categóricas. Un equipo, aun uno con un alto grado de madurez, quizás no sea capaz de reaccionar por sí solo a esos escenarios que emergen de repente y mucho menos en iteraciones cortas de una o dos semanas. Es allí donde un Scrum Master, de esos que he dado en llamar “Extraordinarios” es útil. Incluso si el Scrum Master está parcialmente en el equipo, como plantean algunos, sus respuestas pueden llegar tardías o simplemente no llegar.

Y el Coach Ágil

Un Scrum Master extraordinario sabe que necesita un mentor, alguien que lo acompañe en el camino mientras se forma, mientras madura. Tanto uno como el otro no deben entorpecer las labores del equipo, tampoco deben generar dependencia. En ese sentido deben ser “invisibles”, pero esto no quiere decir que no sean indispensables para ayudar en la mejora de las personas del equipo.

Mi Conclusión

En mi opinión, sí es necesario el Scrum Master. La persona. ¡Y el rol que juega! Quizás sea posible un modelo donde no esté. Ni el coach ágil. Pero en mi experiencia, la evolución de este equipo se va a detener o se va a hacer excesivamente lenta.

¿Qué piensas de todo esto? Déjamelo saber en el foro.

Sobre el Scrum Master Extraordinario

Los invito a leer algunas de mis contribuciones al respecto:


domingo, febrero 10, 2019

Algunos Elementos de Agilidad Empresarial




Una empresa Ágil es una organización de personas comprometidas y centradas incansablemente en proporcionar valor al cliente; que mejoran continuamente la forma en que operan; y que utilizan el empirismo para adaptarse rápidamente al cambio de una manera sostenible.
Todas las organizaciones se adaptan a los cambios… ¡o casi todas! Pero las organizaciones ágiles lo hacen más rápido, entrenan a su gente y mejoran continuamente la forma en que crean valor. Estas empresas involucran e inspiran a las personas en torno a causas audaces y nobles, no en torno a objetivos a corto plazo. Hacen que la información esté abierta para la autorregulación, la innovación, el aprendizaje y el control; no la restringen.
Estas empresas confían en las personas y les dan libertad para actuar; y no castigan a todos si alguien abusa de ello. Además, organizan los procesos de forma dinámica en torno a los ritmos y eventos empresariales, no alrededor del calendario laboral. Finalmente, pero quizás más importante, estas empresas ágiles conectan el trabajo de todos sus asociados (empleados, colaboradores, etcétera) con las necesidades del cliente; y evitan los conflictos de intereses.
Prácticas Técnicas
Cuando una organización funciona de manera ágil, las prácticas técnicas son los instrumentos utilizados por los equipos y los líderes para entregar valor al cliente de forma rápida e incremental. Permiten construir correctamente el producto correcto. Productos que los clientes amen y que impacten su estilo de vida.
De acuerdo con Jorgen Hesselberg, una lista mínima de estos instrumentos incluye:
·       El lienzo de modelo de negocio
·       Producto Mínimo Viable (MVP) y la experimentación/validación de Lean Startup.
·       El Costo de la Demora
·       Scrum
·       Kanban
·       Value Stream Mapping
·       eXtreme Programming (XP): desarrollo conducido por pruebas (TDD), Integración Continúa, Despliegue Continuo, Programación Par, Propiedad Colectiva del Código y Refactoring (¡mi favorita!).
Lo más importante es poner a trabajar todos estos utensilios al servicio de la organización ágil y de las personas. De esta forma es posible construir no solo correctamente el producto correcto, sino también, hacerlo a la velocidad requerida para sobrevivir en el mercado cambiante y altamente competitivo de hoy.
Sistemas Empresariales
En una organización ágil, los sistemas empresariales son el conjunto de procesos, herramientas, creencias y políticas en constante evolución que mejoran el negocio. Estos sistemas permiten a los líderes tomar decisiones rápidas y priorizar para entregar valor.
El liderazgo habilita a los sistemas empresariales y estos a su vez soportan las prácticas técnicas. En la práctica, estos sistemas o procesos de negocio posibilitan que los equipos, líderes corporativos, analistas y gerentes trabajen en grupos de una manera fluida y conectados para entregar valor al cliente.
Los procesos organizacionales deben reflejar los nuevos paradigmas, como la salida  continua de valor al mercado, el cliente en el centro de la esfera corporativa, es más, el cliente sentado en la mesa – no, las ideas no surgen del negocio, emergen de los clientes, para ello el negocio se vale de instrumentos como user persona, user journey, experimentos de productos (productos y prototipos mínimos viables o mínimos deseables), entrevistas con clientes y focus groups.
Sobre creencias hablaremos a continuación.
Cultura
La cultura es un conjunto de creencias y comportamientos organizacionales. Una organización ágil apoya la capacidad de adaptarse a los cambios a medida que se producen. Se otorga un gran valor a ser transparente y realista, incluso sobre las “malas noticias”.
Las organizaciones ágiles se están moviendo hacia una cultura de energía e innovación. Están creando una cultura basada en la confianza –que hace posible la delegación “pura” y el trabajo colaborativo -, ayudando a los equipos a tomar posesión no solo de su trabajo sino de la empresa misma y no quitarles nada, alineando sus metas (de los equipos) con las metas corporativas, las del negocio y abordando honestamente la ambigüedad y la incertidumbre.
No es posible mencionar cultura sin hablar de métricas. Las métricas son importantes para evaluar e impulsar el progreso, pero pueden ser una barrera si funcionan para la cultura antigua y no para el nuevo estado de las cosas. No, las métricas no son para controlar, son para mejorar. ¡Siempre!
El comportamiento de una organización se levanta sobre los valores y creencias de la empresa, lo que creemos que es correcto: hablamos de coraje, de adaptación rápida al cambio, relacionamiento entre personas, retroalimentación continua, transparencia, respeto, colaboración. Más arriba en la pirámide de sostenimiento cultural de la empresa están los modelos mentales, las estructuras cognitivas, la forma cómo racionalizamos: la satisfacción del cliente, valor, la conversación cara a cara, el compromiso, la calidad, la simplicidad en el sentido de eliminar desperdicios.
Pero la cultura de una organización se levanta sobre hombros de sus líderes. La cultura de una empresa no puede sobrepasar la confianza, la eficiencia y el alcance combinado de sus líderes. Precisamente, liderazgo es el tema del siguiente apartado.
Liderazgo
El trabajo de los líderes es doble: 1) proporcionan una visión y parámetros que guiarán a la organización. Confían en que los equipos son capaces de hacer su trabajo. 2) Eliminan obstáculos y suavizan caminos, lo que permite que los equipos se autoorganicen.
Hoy por hoy, un líder es una persona que puede transformar su entorno o generar nuevos y mejores espacios para él, las personas que trabajan con él y sus seguidores. Así las cosas, un líder es capaz de crear un ambiente donde todas las personas se sientan seguras para actuar y para cometer errores sin temor a represalias.
Ahora bien, lo que distingue a los grandes líderes de los demás no es su coeficiente intelectual o sus habilidades técnicas. De acuerdo con Daniel Coleman [2], se trata de un grupo de cinco habilidades que habilitan a los mejores líderes para maximizar su desempeño y el de sus seguidores.
·       Autoconciencia: para conocer sus propias fortalezas, debilidades, valores, lo que los guía y el impacto en los demás
·       Autorregulación: para controlar o redirigir los impulsos disruptivos y estados de ánimo
·       Motivación: para disfrutar sus logros por el bien propio
·       Empatía: para entender el estado emocional de las demás personas
·       Habilidades sociales: para construir una relación con los demás, para moverlos en la dirección deseada
Todos tenemos algo de esos atributos, nacemos con ellos y, quizás a medida que crecemos los vamos perdiendo, algunos de nosotros más que otros. Pero los podemos fortalecer a través de la práctica, la persistencia, a través de la retroalimentación de amigos y colegas o de coaches.
Los dejo con mi decálogo para ser un mejor líder:
1.     Lidera mediante el ejemplo
2.     Conoce bien tus limitaciones
3.     Aprende del pasado
4.     Nunca dejes de mejorar
5.     Practica la comunicación efectivamente
6.     Algo de humildad siempre cae bien
7.     Promulga y cerciórate de que las reuniones sean efectivas
8.     Cultiva el sentido de pertenencia
9.     Retroalimenta y permite que te retroalimenten
10.  Encuentra un mentor, siempre hay alguien que puede enseñarte algo

Referencias y otras lecturas:
·       Unlocking Agility: An Insider's Guide to Agile Enterprise Transformation, by Jorgen Hesselberg
·       What Makes a Leader? By Daniel Goleman. Harvard Business Review.
·       Más sobre cultura en mi artículo: cultura ágil, ese oscuro objeto del deseo. Lo pueden encontrar haciendo clic en mi Gazafatonario.
·       La idea original vino del artículo: https://searchcio.techtarget.com/tip/Four-ways-to-attain-business-agility

El Póster
Puedes descargar el póster de la portada para imprimir en alta resolución:


domingo, enero 20, 2019

Scrumdamentalismo: o de la dogmática ágil




Tengo que confesar que no voy a satanizar a Scrum ni mucho menos a quienes lo practicamos, ¡yo soy uno de ellos! Lo practico no solo en las organizaciones que acompaño, con ímpetu, con altivez cuando es necesario, lo enseño, acompaño a otros a enseñarlo, a practicarlo y he aprendido mucho en el camino. Lo practico con la suficiente apertura como para saber que nunca es suficiente y que debo seguir inspeccionando la realidad para hacer adaptaciones razonables y lograr un cambio sostenible. También lo práctico en mi vida personal, con la pasión y el coraje que se necesita para recargarme cada día y sentir el poder de enfocarme en lo que me emociona y me hace feliz al lado de mi familia.
No, no me malentiendas. Con Scrum en particular y con el pensamiento ágil en general he aprendido que el liderazgo no se trata de una credencial o una designación. Se trata de impacto, influencia e inspiración. Y también he experimentado que a donde sea que vayas, tienes que ir para ser el mejor sin tener que serlo, que no hay fórmulas con la solución para cualquier cosa que ocurra, y que se trata de entusiasmo, honor y trabajo duro. Pero ojo, no nos equivoquemos, es muy fácil confundir pasión, esa determinación con la que hacemos las cosas, sobre todo para promover el cambio, con este scrumdamentalismo que casi siempre, por no ser totalitario, es un sinsentido.
Lo que ocurre es que muchas personas, agilistas o no, siguen buscando la respuesta a todo en las prácticas ágiles, aun en los valores y principios ágiles; lo hacen de manera literal, cuando muchas veces la pregunta correcta es “¿qué te dice el sentido común?”. He trabajado en procesos de mejoramiento (de software) durante las últimas dos décadas y desde siempre he usado este lema: cuando se trata de procesos, marcos de trabajo o prácticas, no subestimes tu poder de pensar. ¡Funciona para mí!
La causa de este fenómeno es que entendimos mal Scrum, sus valores principales o la teoría que lo soporta y tratamos al marco de trabajo como una religión o un dogma, donde todas las respuestas a cada uno de los problemas y escenarios que enfrentamos diariamente vienen de Scrum (esto es precisamente scrumdamentalismo en toda la extensión del término). O bien, hemos entendido Scrum y, sin embargo, le seguimos dando tratamiento de doctrina porque nos gusta su estructura, ese conjunto riguroso y limitado de parámetros que nos hace fácil y llevadera la vida en este universo VUCA que muchas veces nos da temor enfrentar. Es el anhelado “paso a paso seguro” que nos lleva del punto A al punto B sin miedo a equivocarnos.
Es fácil convertirse en scrumdamentalista. Parece un estado inevitable por el que todos hemos pasado. De eso se trata el Shu de Shu-Ha-Ri en donde, si eres Scrum Master sigues con precisión la guía de Scrum, te concentras en cómo hacer las ceremonias con el equipo, que se tengan los artefactos y que cada miembro del equipo se desempeñe como lo plantea la guía o como te dijo el instructor en el curso que tomaste, sin preocuparte demasiado por la teoría subyacente, como por ejemplo: cómo planificar en un entorno empírico.
Lo que convierte a este síntoma en un estigma es querer quedarse allí para siempre. Algunas manifestaciones de los scrumdamentalistas incluyen:
1.     En la Reunión Diaria siempre se responden “las tres preguntas”.
2.     El sprint debe tardar 2 semanas, siempre.
3.     La planificación de un sprint de dos semanas debe tardar máximo cuatro horas.
4.     Solo podemos usar historias de usuario para representar lo que el usuario quiere.
5.     El Scrum Master es el único que puede conducir la retrospectiva.
6.     El Dueño de Producto es el único responsable de definir el incremento de producto para el sprint.
7.     Pensar que cualquier “otro” scrumdamentalista tiene que o debe cambiar, sobre todo después de leer este artículo.
8.     Las herramientas son las armas del demonio de la agilidad.
9.     La documentación tiene que reducirse, ojalá hasta llegar a nada, a cualquier costo.
10.  Tenemos que evitar, incluso alejarnos de, cualquier persona cuyo pensamiento no esté cubierto por el mantra ágil.
Los scrumdamentalistas ven a las organizaciones, comunidades ágiles y consultoras como alquimistas que se presentan ante ellos con sonrisas congruentes y manos extendidas para ofrecer soluciones, transformación cultural, reducción de desperdicios y aumento de felicidad, compitiendo como si se tratara de un mercado persa. Pero solo es porque tienen el recuerdo aciago de un pasado en el que otras organizaciones, comunidades y consultoras se comportaron de manera bárbara cuando eran fuertes y hacían ofertas que no podían rechazar.
Hoy tenemos que partir del precepto de que todos queremos, en efecto, soluciones, cambiar la cultura organizacional, reducir desperdicios, mejorar continuamente y ser más felices. Y que lo hacemos partiendo de la base de que tenemos buenas intenciones, con la información, las habilidades y los recursos que tenemos disponibles. Y reconociendo que la trayectoria pasada no es garantía del desempeño actual y mucho menos del futuro, porque los escenarios cambian.
El mismo Scrum nos muestra la solución a esta disfunción dogmática con sus valores: el empirismo en el que se basa la teoría de Scrum requiere de transparencia, de franqueza (léase apertura). Esto nos enseña a tener la disposición suficiente y necesaria para aceptar las ideas y propuestas de las personas en el equipo y en la organización, aun en procesos complejos de transformación cultural. Precisamos de una apertura tal que nos permita desaprender y aprender en todo momento; y también necesitamos un entorno donde experimentar, fallar y volver a intentarlo.
También debemos tener el coraje para admitir que no somos perfectos y que siempre podemos mejorar y cambiar el rumbo de nuestro pensamiento; coraje para dejar de lado las convicciones del pasado. En resumen, la guía de Scrum, breve y liviana como la han mantenido sus autores, es un compendio pletórico de riquezas, una serie efectiva de propuestas para ayudarnos a hacer las cosas bajo el manto de la mentalidad ágil, pero sin que hagamos a un lado nuestra habilidad, humana y humanizante, de sentir y de pensar.
Incluso yo puedo parecer un scrumdamentalista al escribir este artículo, ¿quién sabe? Quizás sea el más scrumdamentalista de todos, pero estoy trabajando en ello. Solo dame tiempo y ayúdame a sanar.
Lucho Salazar. Lima, 20 de enero de 2019.

domingo, enero 06, 2019

Algunos errores comunes que están haciendo tu transformación ágil más difícil y frustrante

http://www.freepik.com Designed by macrovector / Freepik


Iba a escribir algo sobre las fallas con las que me he encontrado estos años en mi viaje, acompañando y liderando cambios culturales ágiles, entrenando y sirviendo a personas y equipos con algunos de mis colegas y mejores amigos en el terreno.

Como siempre, respiré hondo mientras volvía a leer (¡otra vez!) el tan ampliamente aclamado pero en su mayoría malentendido manifiesto ágil para el desarrollo de software y de repente me llegó esta destornillada idea de escribirlo al “estilo del manifiesto ágil”.

Y así es como surgió este nuevo Manifiesto por la Transformación de Mentalidad FrÁgil, de ahora en adelante llamado aquí “Manifiesto por la Transformación Frágil”.

Esta es solo una forma de expresarme sobre las faltas en las cuales están cayendo los coaches ágiles, líderes ágiles y gerentes de todos los niveles, haciéndole más difícil a las personas entender, aceptar y participar más activa y apasionadamente en las transformaciones ágiles de las organizaciones en este mundo VUCA.

Manifiesto por la Transformación FrÁgile

Estamos descubriendo formas peores de realizar transformaciones ágiles tanto por nuestra cuenta como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Marcos de trabajo, prácticas y herramientas sobre Mejoramiento Continuo

Muchos equipos Scrum sobre Entregar Valor

Silos basados en habilidades y personal en proyectos múltiples sobre Verdadera Colaboración

Medir lo que satisfaga a los gerentes sobre Inspeccionar y adaptar

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Principios detrás del Manifiesto de Transformación FrÁgil

Seguimos estos principios a cualquier costo:

Nuestra mayor prioridad es satisfacer la gerencia tradicional a través de la creación temprana y continua de equipos Scrum

Aceptamos más prácticas, marcos de trabajo y herramientas ágiles, incluso en etapas tempranas de la transformación. Las transformaciones ágiles complacen el ego de los patrocinadores y de su personal.

Creamos escuadrones, tribus y células frecuentemente, desde un par de equipos por semana hasta docenas de ellos por mes, con preferencia a la meta más alta posible.

Los responsables del negocio y los desarrolladores no deben infundir la experimentación y la iteración en el ADN de la organización.

Pensamos que todos los individuos en la organización tienen la misma alta motivación acerca del proceso de transformación. Los tratamos como si todos tuvieran la misma energía, confianza y visión en el cambio.

El método más eficiente y efectivo de informar sobre la transformación en curso es la falta de comunicación a través de toda la organización.

Las herramientas, marcos de trabajo, prácticas instaladas y el número de escuadrones son la medida principal del progreso.

Muchas palabras diferentes flotando sobre la esfera ágil promueven la transformación sostenible. Los patrocinadores, gerentes y responsables de la transformación deben poder pronunciarlas bien, aun si no las entienden en absoluto.

La atención continua a hacer reuniones diarias y retrospectivas sin sentido desmejora la agilidad.

La complexidad, o el arte de usar marcos de escalamiento y contratar expertos en Cynefin, es esencial para presumir.

Los mejores cambios culturales, prácticas ágiles y retroalimentación emergen de equipos internos, sin un acompañamiento y entrenamiento sólidos.

Muy temprano en el proceso, la organización reflexiona sobre cómo ser más ágil para a continuación implantar marcos de escalamiento en consecuencia.

La lista de errores puede ser bastante extensa, así que incluye los tuyos apropiadamente. ¿Y estás preparado para no ser un signatario de este manifiesto? Déjamelo saber en el foro.

Nota:
Publiqué originalmente este artículo en inglés en Pulse de LinkedIn (I originally published this article in English on Pulse from LinkedIn):