Buscar en Gazafatonario IT

lunes, junio 08, 2020

El lenguaje y la transformación organizacional


Escucha el audio de este artículo aquí:

Muchas personas no creen que la terminología o el vocabulario usado importe. Pero el lenguaje se refleja directamente en los modelos mentales que hacemos de las cosas. Y los modelos son una representación de la realidad que nos rodea. Así que los modelos ayudan o soportan la construcción o elaboración de esas realidades a nuestro alrededor y de los escenarios en los que vivimos.

En los procesos de cambio o de transformación, es importante modificar no solo nuestros comportamientos sino también el vocabulario que usemos. Así la alta dirección y todos en la organización no se sentirán ansiosos pensando que nada está cambiando. Veamos un ejemplo:

De pensar en proyectos a pensar en productos

Imagen de Nattanan Kanchanaprat en Pixabay

No se trata solo de un cambio en la terminología, sino también en la forma cómo vemos e interpretamos el mundo. Se trata de la forma en que percibimos y pensamos sobre las cosas: los proyectos inician con buenas ideas, de esas que dan ganas de volver una realidad. Pero las formas de gestión tradicional de proyectos los han catapultado como “exitosos” si el plan inicial de alcance, tiempo y costo del proyecto estuvo cerca o muy cerca de los números al final del mismo: se trata del así llamado Triángulo de Hierro del management vetusto.

En principio, esto no tiene nada de malo. Son las prácticas de gestión que han predominado durante décadas en las organizaciones, aunque a muchas de estas les ha costado más de un dolor de cabeza. Pensemos en que el 88% de las compañías que el siglo pasado estaban en la lista de las 500 más grandes de Estados Unidos (Fortune 500), en 2017 habían desaparecido de la lista o de la faz de la tierra para siempre o simplemente se habían convertido en un pequeño departamento dentro de una corporación mucho más grande que las absorbió. Más sobre esto en:

http://www.aei.org/publication/fortune-500-firms-1955-v-2017-only-12-remain-thanks-to-the-creative-destruction-that-fuels-economic-prosperity/

O si no pregúntale a Nokia. Cien mil empleados, una infraestructura considerable y millones en activos y por la que Microsoft pagó incluso menos que por Skype, otra compañía muchísimo más pequeña, con apenas algunos cientos de empleados. ¿Cómo es posible que la empresa cuyas ventas de celulares se encuentran en la cima de todos los listados de ventas y que se cuentan por cientos de millones de unidades, se haya convertido en unos pocos escritorios dentro del gigante del software y luego desaparecido para siempre?

Bueno, si tú o tu empresa siguen pensando en términos de proyectos y menos en términos de productos y valor, tu destino puede cambiar rápidamente. Y más en los actuales escenarios de altísima incertidumbre y volatilidad e igualmente o más complejos y ambiguos que los de hace apenas algunos años. Es por ello que queremos reemplazar conceptos (vocabulario) como el “triángulo de hierro” de los proyectos por el triángulo ágil o por mi versión extendida que puedes encontrar en:

http://www.gazafatonarioit.com/2016/04/del-triangulo-de-hierro-al-triangulo.html

O por los conceptos mencionados de producto y de valor. El objetivo de toda organización, y el paradigma al cual se enfrentan hoy por hoy, es entregar productos o servicios de valor para sus consumidores. Productos que generen retorno de la inversión, disminuyan los costos, ganar más clientes, eliminen desperdicios en los procesos y, en fin, todo lo que signifique generar valor para la empresa.

Hoy es preferible pensar en términos del mínimo producto viable (MVP), incluso es mejor pensar en términos de experimentos y de sus conceptos subyacentes. Es lo que te permitirá cambiar la forma de hacer las cosas porque tus modelos mentales serán diferentes y, por ende, la realidad que te rodea, la realidad que construyes basado en esos modelos. Esta forma de pensar, ágil por demás, conduce a generar menos desperdicio, a mayor creatividad y a más entregas y de mejor calidad.

Sobre técnicas para encontrar el MVP y, en general, sobre la creación de productos, puedes consultar en:

http://www.gazafatonarioit.com/2016/08/inceptions-con-jorge-abad.html

Y sobre productos y su contexto, puedes leer en:

http://www.gazafatonarioit.com/2019/12/el-contexto-de-tu-producto-importa-aqui.html

De pensar en trabajo en equipo a trabajo colaborativo

Imagen de Gerd Altmann en Pixabay

Ya desde los mismos conceptos, el primero de ellos no da señales de que ese trabajo se haga efectivamente de manera colaborativa. Es posible tener un “equipo” de especialistas, como ha ocurrido históricamente, donde cada miembro elige o se le asignan tareas por hacer de acuerdo con sus habilidades específicas. Pero eso no tiene nada de colaborativo, no exige mucha comunicación entre uno y otro integrante del equipo y quizás requiera de poca o ninguna interacción entre unos y otros.

El verdadero trabajo colaborativo va más allá. Implica interacción constante, poner de manifiesto la inteligencia y las habilidades de cada persona para un bien mayor, el del equipo y el de la organización. Requiere de confianza entre las personas, de mucha comunicación, ojalá cara a cara, del establecimiento y práctica de valores como la apertura y el respeto, incluso el coraje. Requiere de mucha proactividad y de sentido de pertenencia y de familia. Bajo este paradigma no hay espacio para individualidades, el responsable de una tarea y de todas las tareas es el equipo en pleno, ningún miembro del mismo es dueño del resultado, solo el equipo.

Esta forma colaborativa de hacer las cosas hace posible la experimentación y la falla, requiere del liderazgo de todos los participantes en el equipo, rompe barreras, elimina silos, promueve recompensas a todo el grupo, no solo a unos pocos individuos, maximiza las habilidades de escucha y, en general, de comunicación, comportamientos que, a la postre, traerán como consecuencia un cambio en la cultura de la empresa, una transformación organizacional.

Estos cambios se van generando de manera natural, orgánicamente. Primero como un reflejo en nuestras mentes y en las mentes de los comprometidos con el cambio, más adelante, si lo sabemos promover, el cambio empieza a ocurrir en los demás interesados y, a partir de allí, en el resto de la organización. Finalmente esos cambios son el reflejo de nuestra forma de pensar, la que conseguimos encontrando nuevos conceptos y formas de ver e interpretar el mundo, un nuevo lenguaje que impacte positivamente nuestro modo de pensar.

Otros cambios necesarios en tu vocabulario

Estos apenas fueron un par de ejemplos sobre cómo el lenguaje impacta nuestro pensamiento y nuestra forma de actuar. Pero, en la práctica, quizás nos topemos con aspectos de la cultura organizacional, de la forma de trabajar de las personas y los equipos y de los paradigmas de gestión y de ejecución de tareas para los que no tengamos un vocabulario común o simplemente no hallemos una forma de verbalizarlo. Es allí donde es importante lo acentuado que tengamos una u otra forma de interpretación de los escenarios que enfrentemos y del contexto que tengamos de las cosas.

Con todo esto en mente, te invito a cambiar tu léxico:

·       De trabajo por habilidades o especialidades, aislado, a trabajo colaborativo, en red.

·       De una entrega final de producto a entregas tempranas y frecuentes de valor.

·       De analizar los resultados al final de un gran ciclo de trabajo (proyecto), a reflexionar sobre el estado de las cosas repetidamente: inspección y adaptación.

·       De tratar de mejorar todo y de una sola vez, a realizar mejoras graduales y pequeñas pero continuas.

·       De planificar una sola vez y ejecutar el plan, a realizar planes periódicos, quizás tanto como todos los días.

·       De pensar solo en tener éxito, a pensar en experimentar y fallar para aprender

·       De fomentar el trabajo de expertos en distintas áreas a promover el aprendizaje continuo de las personas para que adquieran habilidades T o Pi (especialistas generalistas)

·       De gastar tiempo estimando las actividades del equipo a ordenar los elementos del producto y empezar a crearlo de inmediato

·       De hacer multitarea a tener foco en una sola tarea a la vez, tanto individualmente como en equipo

Y de pensar que hay una palabra, una expresión verbal o escrita para todo, a tener presente que hay aspectos del universo que no somos capaces de modelar porque no hay forma de representarlos y allí es donde nuestras emociones y nuestro sentido común juegan un papel importante: es el fundamento o la esencia por el cual estamos aquí y la razón por la cual queremos cambiar para mejorar.

Al hacerlo, seguramente notarás un cambio en la realidad circundante. Por ahora, cuéntame en el foro qué otros cambios estás promoviendo en tu equipo y en tu organización.

Puedes ver y descargar la presentación aquí:



miércoles, junio 03, 2020

Conociendo OKR

Imagen de 3D Animation Production Company en Pixabay
Imagen de 3D Animation Production Company en Pixabay

Los OKR son un protocolo de colaboración para establecer objetivos en empresas, equipos y personas.

OKR son las siglas de Objective and Key Results, u Objetivo y Resultados Clave.

Un Objetivo responde a Qué hay que lograr. Es concreto, trascendente, realiza un llamado a la acción e inspira.

Entre tanto, los Resultados Clave son un marcador de referencia y monitorizan cómo llegamos a ese objetivo. Son específicos y se establecen en un marco temporal. Los Resultados Clave son agresivos pero realistas. Por sobre todas las cosas, deben ser medibles y verificables.

Esta es una sesión introductoria a los OKR, explico de manera sencilla de qué se tratan los OKR, cómo lucen, con algunos ejemplos y qué hacer con ellos una vez se establecen. En este apartado, hago una propuesta simple pero adaptativa para el ciclo de vida de los OKR, desde su definición hasta el cierre del ciclo temporal para el cual fueron definidos.

Al final, enumero ocho aspectos importantes a tener en cuenta cuando quieres utilizar OKR.

Puedes ver y descargar la presentación aquí:



domingo, mayo 24, 2020

Delegación en tiempos del covid-19

Son tiempos difíciles. Estamos atravesando una crisis sin precedentes en la humanidad. Con asombrosa rapidez, hemos tenido que adaptarnos a un entorno que no imaginábamos posible hace apenas algunas semanas.

Afortunadamente, para quienes hemos navegado en la incertidumbre y la volatilidad, estos escenarios no son del todo novedosos. Hemos insistido hasta la saciedad en la última década que debemos practicar y promover la adaptación a los cambios. Sabemos que la vida, como la conocemos, es capaz de transformar hábitats de una perfección inescrutable, en ambientes aún más complejos y virtuosos.

Los cambios están ocurriendo por doquier, sin parar y sin que haya un comando y control superior para dar órdenes y, para ello, en las organizaciones hemos puesto de manifiesto la necesidad de delegar. Y los tiempos actuales requieren de medidas actuales. El trabajo remoto, cuya necesidad es a todas luces evidente, demanda un alto nivel de confianza y de empoderamiento en las personas.

El objetivo es lograr que nos ocupemos de todas las tareas habituales sin supervisión, que se establezca una meta, una dirección y se fijen prioridades, se analicen los problemas, se hagan planes, se ejecuten y se tomen decisiones difíciles. Todo sin la mirada del Gran Hermano sobre nosotros. Se trata de que las personas y los equipos sean efectivamente autónomos y autoorganizados.

De eso se trata la delegación y el empoderamiento. Es sobre cómo no controlar mientras nos cuidamos de una pandemia para sobrevivir en este universo pletórico de ambigüedades y complejidades. Se trata de cómo hacerlo gradualmente aunque hoy no tenemos mucho tiempo, pero es posible pensar en delegar una gran tarea mientras nos tomamos treinta segundos para lavar bien nuestras manos y cuidarnos de la enfermedad.

Donde estamos

El empoderamiento es tan antiguo como los primeros gurús de la gestión. Con el tiempo ha sido relegado a libros de biblioteca y carteles ocasionales en compañías que han desaparecido hoy.

Durante esta crisis mundial (abril de 2020), se descubrieron las máscaras de delegación y empoderamiento. La autoridad de los colaboradores de la empresa no era más que una mascarada. Las cosas así, confirmamos que hoy, el culto a "estar presente" es altísimo. Esa cultura de estar en la oficina de 8 a 5 o algo similar no ha terminado. En Colombia lo llamamos "horas nalga". No eres un buen empleado, un buen colaborador si no estás en la oficina de trabajo al menos dos o tres horas más que eso. Tienes que irte después de tu jefe.

Es una realidad: el teletrabajo le da mucho vértigo a los jefes. Tal cómo aprendimos rápidamente de las técnicas de Management 3.0, los gerentes creen que están delegando cuando asignan actividades a sus colaboradores. Muchas veces esto es simplemente descargar tareas en las personas. Y no en el buen sentido.

¿Qué salió mal?

Las organizaciones no lograron garantizar que los supervisores y gerentes supieran delegar de manera efectiva. Y eso sucedió porque muchos gerentes nunca han recibido capacitación sobre delegación o asuntos similares. Pero no lo dudes, ¡muchos de nosotros tampoco!

Razones para no delegar

He observado varios comportamientos que los gerentes o miembros del equipo tienen cuando consideran delegar y finalmente no lo hacen:

·       Empleados incapaces: la creencia de que los empleados no pueden hacer el trabajo tan bien como el gerente

·       Falta de tiempo: la creencia de que lleva menos tiempo hacer el trabajo que delegar la responsabilidad.

·       Falta de confianza: falta de confianza en la motivación y el compromiso de los empleados con la calidad.

·       El “Solo yo puedo”: la necesidad de hacerse indispensable.

·       “Orgasmo laboral”: el placer de hacer el trabajo uno mismo.

·       Sentimiento de culpa: la culpa asociada con dar más trabajo a un personal con exceso de trabajo.

Lo que los gerentes aún no entienden es que tienen un objetivo claro que no están logrando: tienen algunas tareas que deben hacer, pero su trabajo principal es asegurarse de que otros estén haciendo lo que se les ha asignado para cumplir la misión y los objetivos de la organización.

Los gerentes efectivos saben qué responsabilidades delegar para darse tiempo para planificar, colaborar con otros en la organización y monitorear el desempeño de sus colaboradores, asegurándose de brindarles retroalimentación adecuada y oportunidades de desarrollo.

Hemos aprendido que La delegación real es asignar la responsabilidad de los resultados junto con la autoridad para hacer lo que sea necesario para producir los resultados deseados.

También hemos observado que el empoderamiento psicológico es esencial para la efectividad organizacional. Cuando esto es una realidad en varios niveles de la organización, la madurez del equipo es mayor y comenzamos a encontrar comportamientos como:

·       Relación: el empoderamiento puede ser una indicación de una relación relativamente fuerte entre el jefe y los subordinados.

·       Ausencia de miedo: los empleados empoderados tienen menos miedo de recibir retroalimentación negativa.

·       Confiabilidad: cuando se delega autoridad y responsabilidad, las personas sienten que son confiables e importantes para la organización

·       Motivación: los empleados empoderados están motivados y orientados activamente a su rol laboral.

Cuando se trata de retroalimentación, Si los empleados no se sienten empoderados, la delegación en sí misma puede no conducir a un comportamiento de búsqueda de retroalimentación. Mientras tanto, si hablamos de identidad, Cuando se delegan tareas o autoridad, los empleados experimentarán más autonomía e identidad de tarea, lo que los hace sentir más responsables de los resultados y más sensibles a la retroalimentación negativa.

Entonces, ¿qué puedes hacer para mejorar las cosas en esta materia?

No hay empoderamiento sin un proceso de enseñanza-aprendizaje o sin acompañamiento continuo. Los gerentes efectivos deben convertirse en coaches o entrenadores. Extrapolando, todas las personas en la organización deben convertirse en coaches, en líderes. Sabemos que convertir a los miembros del equipo en entrenadores ahorra costos y aumenta la moral al darles la oportunidad de brillar y ser reconocidos por su experiencia.

Sí, puedes usar los siete niveles de delegación:

Y podemos usar El Tablero de Delegación para tener las cosas en su lugar y fomentar la transparencia. De hecho, a medida que esta crisis continúa, en casa tuvimos que pasar de esto:

A esto:

... Cuando se trata de responder rápidamente y, en consecuencia, a la emergencia actual. Gracias por preguntar, ¡estamos bien ahora!

Pero las cosas no son solo blancas o negras cuando delegas en tu empresa. Tienes que tener en cuenta el nivel de madurez del equipo. Si consideramos, por ejemplo, el así llamado modelo de Tuckman:

No es lo mismo delegar a los miembros de un equipo en Formación que empoderar a las personas de un equipo en la fase de alto Desempeño. Hemos realizado experimentos con éxito: no ir más allá del nivel 2 en equipos que están en la fase de formación, por ejemplo. Además de no bajar el nivel 5 en equipos que ya tienen un alto rendimiento. En cualquier caso, la madurez del equipo no es lo único a tener en cuenta, pero es una variable que muchas veces los gerentes actuales no están considerando, y mucho menos durante esta crisis. Es un hecho: no hay confianza.

Lista de chequeo de delegación y empoderamiento

Finalmente, una pregunta que escucho mucho de los equipos que acompaño es: ¿cómo puedo conocer el nivel de empoderamiento de mi gerente o de mis compañeros de equipo? En la práctica, hay muchas maneras, las mejores son por observación, a través de una “caminata Gemba”, pero nunca está de más tener un instrumento a mano con preguntas simples que nos permitan verificar los hechos. Puedes comenzar con estos:

  • Te dieron un teléfono celular y una computadora portátil para que puedas responder cada vez que el jefe te necesite, sin importar la hora y el lugar donde te encuentres.
  • Por tu propia cuenta, no pides hacer una tarea por temor a represalias.
  • Puedes pedir tu almuerzo en la oficina sin problemas, pero no puedes comprar un bolígrafo sin la aprobación de tu jefe inmediato.
  • La última persona que se atrevió a ser proactivo y falló al proponer algo fue despedida de la compañía.
  • No estás entrenado para adquirir habilidades T y ni siquiera sabes qué es eso.

Si la respuesta a alguna de esas preguntas es "Sí", aún puede hacerlo con capacitación y entrenamiento. Si la respuesta a todas ellas es "Sí", tiene un largo camino por recorrer. Pero puedes intentarlo; Lo peor que te puede pasar es que mañana encuentres una mejor organización en la cual colaborar.

Eso es todo. Puedes encontrar más información sobre delegación en el sitio de Management 3.0. En particular, puede encontrar más información sobre Delegation Poker haciendo clic aquí.

https://management30.com/practice/delegation-poker/.

Déjame saber cuáles son tus experiencias al delegar cosas. Me encantaría conocerlas.

***

Escribí la versión original de este artículo en inglés. La encuentran en:

https://www.linkedin.com/pulse/delegation-time-covid-19-luis-antonio-salazar-caraballo/

La presentación que inspiró este artículo:



lunes, abril 27, 2020

Ritmo sostenido, cadencia y el ciclo lunar

Imagen de Gerd Altmann en Pixabay

Hablaba con mi amiga Claudia Toscano sobre el por qué la duración de los Sprints debería ser siempre lo mismo, el por qué no era buena idea estar cambiando de duración a las iteraciones en Scrum y lo primero que se me ocurrió es que una de las razones principales es el ritmo, precisamente ese ritmo sostenido del que hablamos ya desde el manifiesto ágil, que nos permite conocer con más precisión (o menos imprecisión) la capacidad real del equipo.

Me refería a ese principio del Manifiesto que dice:
“Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida”.
Decíamos que ese ritmo constante tiene otros beneficios también, entre ellos mayor productividad, elimina el estar pensando precisamente eso de "este sprint de cuánto tiempo será". Esas conversaciones que son desperdicio y restan productividad desde el sprint anterior en donde las personas están sugiriendo que "el próximo sprint sea de 10 días o de 5", "qué tal si lo hacemos de 15", evita esos diálogos que generan estrés, agregan confusión a un contexto que quizás ya tiene mucha incertidumbre. En general, se reduce la complejidad, esa complejidad inherente a tener que tomar ese tipo de decisiones cada vez que va a empezar un nuevo sprint, aun desde el anterior.

Hay menos inseguridad. Hay menos gasto de energía y se genera menos estrés. Además, con el tiempo, los eventos internos del Sprint son más efectivos porque la gente ya conoce su  ritmo y eso es muy importante en la Planificación, porque el equipo ya tiene una proyección de lo que puede hacer en un Sprint. Hemos notado que al mantener un ritmo y vigilarlo continuamente ayuda a mejorar la eficiencia de las personas en el trabajo, reduce los riesgos inherentes al trabajo del conocimiento y al producto o servicio, disminuye el desperdicio que se pueda generar, sobre todo si mantenemos los elementos del backlog (historias de usuario) pequeños, y contribuye significativamente a la mejora continua.

Algo que nos pasaba con nuestra forma de trabajar anterior, en Cascada, era que lenta y casi imperceptiblemente empezábamos a caer en lo que podríamos llamar "vórtice de procrastinación". Uno en el que rápidamente estábamos perdiendo contacto con los clientes o consumidores, con los interesados, pero incluso más grave aún, con los propios compañeros del equipo. No sabíamos cuando íbamos a terminar algo, a pesar de los planes “detallados” a que éramos sometidos de manera dictatorial y el fin de una actividad pasaba de horas o días a semanas y rápidamente a meses… ¡un día a la vez!

¡Eso definitivamente no tenía nada de divertido!

¿Por qué? Porque somos seres rítmicos por naturaleza. Seguimos ciclos de manera casi ritual, por ejemplo, estamos despiertos y dormimos más o menos a las mismas horas, siempre. El ritmo nos ayuda a relajarnos, a calmar el estrés, nos permite determinar bloques de tiempos para actividades específicas y todo ello nos posibilita adaptarnos mejor a las circunstancias, porque podemos predecir o proyectar lo que podemos hacer y cómo hacerlo sin estrés, de manera más o menos divertida.

El Sprint en Scrum y el ciclo lunar

Imagen de Syaibatul Hamdi en Pixabay
El Sprint es el corazón de Scrum y en Scrum todo ocurre en el marco de un Sprint. El objetivo en el Sprint es crear un incremento de producto “Terminado”, utilizable y potencialmente desplegable en un ambiente donde al menos un grupo de usuarios o consumidores pueda “jugar” con él. De la guía también aprendimos que “es más conveniente si la duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo”. Ya hemos establecido ampliamente el porqué es necesaria es invariabilidad.

Una de las duraciones más ampliamente usadas por los equipos en todo el mundo es 2 semanas para sus Sprints, según indica The 2015 State of Scrum Report de la Scrum Alliance. Más sobre este reporte en:


Pero también es importante definir Sprints cuyo inicio y fin concuerden con los ciclos lunares. Esto se les hace más natural a las personas porque nos adaptamos mejor a esas cadencias que son habituales para nosotros. Por eso siempre estamos buscando iniciar Sprints un lunes y terminarlos un viernes. Sin embargo, en países como Colombia donde las festividades fueron modificadas de manera artificiosa hace ya varias décadas, hay que adaptar esos ciclos para acomodar tales eventos y otras pausas habituales en las culturas locales. Por ejemplo, dado que en Colombia hay muchos lunes festivos, podría ser interesante experimentar iniciando los Sprints un martes y hacerlos de nueve días en vez de diez. En el caso de que durante ese ciclo de dos semanas no haya días festivos, el décimo día se puede usar para trabajar en la mejora del equipo o en apoyo a otros equipos y áreas de la organización, o simplemente en socialización al interior de la empresa. También son útiles estos días para realizar hackatones u otras actividades que fomenten la innovación.

De esta manera, los equipos establecen una cadencia acostumbrada y fijan expectativas con base en las fechas de finalización de los Sprints. El equipo puede sincronizarse con otros equipos para entregar incrementos de producto en el que estén trabajando en conjunto o para tener un mejor manejo de las dependencias entre ellos. Esto reduce los conflictos entre esos equipos y las personas nos sentimos más a gusto y cómodas trabajando con el horizonte de los ciclos naturales a los nos que hemos habituado desde niños. Esto mejora la motivación del equipo y afianza los valores y la visión establecidos.

Conclusión

Tener este tipo de hábitos, como Sprints de duración fija, reuniones diarias a la misma hora y en el mismo lugar, y conocer con anticipación las fechas de otros eventos como la Planificación, la Revisión o la Retrospectiva, permite que los miembros del equipo se enfoquen en sus tareas principales y hagan lo que mejor saben hacer, que es manejar la incertidumbre, los cambios y la ambigüedad inherente al tipo de tareas que hacemos diariamente, es decir, esa otra cara variable del trabajo.

Referencias

Para saber más sobre patrones Scrum puedes consultar el libro:

A Scrum Book: The Spirit of the Game, de Sutherland , Coplien , den Hollander y otros.

miércoles, abril 22, 2020

La historia de las historias de usuario


Ejemplo de una historia de usuario de Kent Beck. Fuente: Extreme Programming Explained, de Kent Beck
Brevísima historia detrás de la historia de las historias de usuario

Durante un entrenamiento a entrenadores de historias de usuario, hace poco nos preguntaban a Jorge y a mí sobre el origen de las historias de usuario. Por alguna razón olvidada para mí, en el libro omitimos ese pequeño detalle, aunque mencionamos a Connextra cuando hablamos de la forma más usual que suelen tomar las historias de usuario:

Como rol deseo característica Para beneficio

Bueno, aquí les escribo lo que les contamos a los entrenadores:

La historia de las historias de usuario

No es la primera vez que nos preguntan y durante todos estos años, he visto a mucha gente en las redes sociales hacer lo mismo. Por ejemplo, me encontré con este tuit de Seb Rose en octubre de 2019:


Hola, historiadores de Scrum, tengo algunas preguntas:
- Las historias de usuarios comenzaron con XP, documentadas por primera vez en el '98. ¿Es eso cierto?
- Sutherland ejecutó el primer proyecto Scrum en el '93. ¿Usaron historias (o similares)?
- Las historias de usuario ahora están integradas en la práctica de Scrum. ¿Cuándo sucedió eso?
Hay todo un hilo de respuestas. Entre estas, una de Mike Cohn, quien fue convocado por algunos otros tuiteros:

Rachel Davies escribió sobre esto en un artículo. Luego escribí sobre eso en mi libro.
Se refería a ese formato que él mismo popularizó en su libro sobre historias de usuario.
Por supuesto, la intervención de la misma Rachel Davies no se hizo esperar:

Tuve conversaciones con @mikewcohn en la XP2001 donde presenté un póster que incluía la plantilla de la historia de Connextra y fui revisora de su libro sobre Historias de usuario. Él fue influenciado por XP en ese momento ya que el libro de Scrum acababa de salir.
Ya en 2014 había tenido la oportunidad de conocer sobre Rachel Davies vía una versión cruda y sin editar del libro User Story Mapping de Jeff Patton.

En el libro, Patton muestra una fotografía de su amiga:

Rachel Davies mostrando una tarjeta de historia.
Fuente: User Story Mapping by Jeff Patton, Peter Economy

Sobre el origen de las historias de usuario y de sus formas

Es bien conocido que las Historias de usuarios se originaron con eXtreme Programming (XP). Lo que es poco conocido es que su primera descripción escrita en 1998 solo afirma que los clientes definen el alcance del proyecto "con historias de usuarios, que son como casos de uso".

En lugar de ofrecerse como una práctica distinta a XP, se describen como una de las "piezas del juego" utilizadas en el "Juego de Planificación” (Planning Game) del mismo XP.

Recordemos que eXtreme Programming (XP) fue desarrollada por Kent Beck en 1996 y a partir de allí la refinó hasta publicarla en su libro Extreme Programming Explained en 1999.

De hecho, Jeff Patton indagó con el mismísimo Kent sobre el origen específico de las historias de usuario:
Lo que estaba pensando era en la forma en que los usuarios a veces cuentan historias sobre las cosas nuevas y geniales que hace el software que usan. [Por ejemplo,] Si escribo el código postal y se completa automáticamente la ciudad y el estado sin tener que tocar un botón.
Creo que ese fue el ejemplo que desencadenó la idea. Si puedes contar historias sobre lo que hace el software y generar interés y visión en la mente del oyente, ¿por qué no contar historias antes de que lo haga el software?
- Kent Beck a Jeff Patton, por correo electrónico personal, agosto de 2010

Figura 7. Ejemplo de Tarjeta de Historia

Fuente: Extreme Programming Explained, by Kent Beck

En el libro, Beck no dice mucho sobre las historias, hacen parte de las prácticas primarias, junto con otras que conocemos ampliamente como Pair Programming, Continuous Integration y Test-First Programming, sí, esa que a la postre se convertiría en la Test-Driven Development de hoy, entre algunas otras. Sobre las historias (que aún no eran “de usuario”), Kent enfatiza:
“Escribe las historias en fichas y colócalas en una pared por la que pases con frecuencia. La Figura 7 es una tarjeta de muestra de una historia que deseo que implemente mi programa de escáner. Cada intento que he visto de informatizar historias ha fallado en proporcionar una fracción del valor de tener cartas reales en una pared real. Si necesitas informar el progreso a otras partes de la organización en un formato familiar, traduce las tarjetas a ese formato periódicamente”.
Fuente: Extreme Programming Explained, by Kent Beck
La advertencia de registrar las historias en herramientas ya venía desde entonces. Recordemos que XP, junto a Scrum, eran los dos marcos de trabajo dominantes cuyos autores estuvieron presentes en la declaración del Manifiesto Ágil.

Más adelante, en 2001, Ron Jeffries propone el modelo de Tarjeta, Conversación, Confirmación, para distinguir historias de usuarios "sociales" de prácticas de requisitos "documentales", como los casos de uso. Pueden leer su artículo en:


Como nota tangencial, este modelo lo llamamos aliteración Carta, Conversación, Confirmación en nuestro libro de historias de usuario.

Ese mismo año, 2001, Rachel Davies presentó su charla "Tuning XP" en el XPDay con Tim Mackinnon, donde presentaron el formato de historia que usaban en Connextra:

"As a role I want feature so that benefit"


Años más tarde, en 2006, Davies reflexionaba sobre esta “plantilla” antes de dar a conocer sobre un ejercicio que usó en uno de sus entrenamientos. Ella decía que:
“Este formato puede llevar a las personas a centrarse más en los intereses de los usuarios finales que en la perspectiva de la persona que presenta el caso de negocio. Además, cuando se les da una plantilla, las personas pueden comenzar a tratar las tarjetas de historias escritas de esta manera como especificaciones de requisitos mínimos que se centran en las palabras escritas en lugar de usar historias como herramientas para conducir una conversación. Peor aún, las historias que no se ajustan a esta forma serán maltratadas hasta que lo hagan”.

Rachel tiene razón. Esta es una de las grandes anomalías o antipatrones que hoy por hoy siguen presentándose con el uso de las historias de usuario y por ello insistimos tanto a lo largo y ancho de nuestro libro que las historias de usuario son un instrumento de conversación y de colaboración.
Pero no nos desviemos de nuestra historia.

En 2003, Bill Wake creó el mnemotécnico INVEST para iniciativas ágiles de desarrollo de software, como un recordatorio de las características de un elemento de Product Backlog de buena calidad.

Según el mismo Wake este elemento, PBI para abreviar,  puede escribirse comúnmente en forma de historia de usuario, pero no es obligatorio. Como sabemos estos PBI se pueden usar en un Product Backlog tipo Scrum, en un tablero Kanban o un proyecto XP.

En 2004, Mike Cohn publica su libro: User Stories Applied: For Agile Software Development, donde ayuda a popularizar el formato de Davies y su equipo en Connextra. En el hilo de Seb Rose alguien le dice a Mike que fue él (Cohn) quien popularizó el formato, además de los puntos de historia y de la velocidad, ampliamente usados con Scrum. Mike lo corrige:

He contribuido a la popularidad de ellos pero no originé ninguno.
Y todo ello nos trajo hasta aquí.

Epílogo

En lo personal, me parece una historia fantástica. Una a la que hemos asistido en nuestro tiempo. Tardé en empezar a usar historias de usuario pero cuando llegué a ellas hará unos ocho o nueve años, me ayudaron a derrumbar los antiguos paradigmas con los que venía trabajando hasta entonces.

Y en el futuro me gustaría que alguien hablara de mi Lienzo para Conversar sobre Historias de Usuario como parte de la historia de las historias de usuario. Por eso quise terminar la historia a nuestros entrenadores con esta parte:

En 2018, Jorge Abad y Lucho Salazar publican finalmente su libro: Historias de usuario: una visión pragmática, que incluye el User StoriesConversation Canvas, un lienzo para que los usuarios, Dueños de Producto, Gerentes de producto y otros interesados mantengan conversaciones efectivas con los miembros de los equipos de desarrollo de productos y se construyan productos o servicios extraordinarios.
Fuente: ¡conversaciones con Jorge y Lucho!

Fin de la Historia de las Historias de Usuario

Referencias

Además de las fuentes explícitas, pueden consultar algunas otras para saber más sobre esta genial historia: