El desarrollo de software son conversaciones (y VII)

Tiempo aproximado: 21 min.

Por fin en esta entrada concluyo la serie “El desarrollo de software son conversaciones”. Se trata de cerrar el círculo y ver qué sucede cuando nuestro software (completo, o apenas un incremento) llega hasta los usuarios: lo que llamamos feedback.


Feedback

El feedback o retroalimentación es una palabra que me trae un curioso recuerdo de mi adolescencia, cuando por pura casualidad leí acerca de Norbert Wiener, el “padre” de la cibernética. Quién sabe, quizás éso fue la semilla para que luego yo terminara aprendiendo a programar ordenadores. Pero bueno, volvamos al término feedback y a su relación con las conversaciones en el proceso de desarrollo de software.

En general, yo entiendo por feedback todo aquello que aprendemos durante un proceso y que usamos para mejorar el resultado del mismo, o incluso para mejorar el propio proceso.

Ciclo (o bucle) de retroalimentación

Ciclo (o bucle) de retroalimentación

De esta manera, podríamos hablar de un feedback centrado en los resultados y otro centrado en los procesos con los que obtenemos y medimos esos resultados.

Feedback sobre los resultados

Si recuerdas, en las primeras conversaciones que tenemos al comenzar a trabajar sobre una idea (que eventualmente llegará a convertirse en una nueva funcionalidad para los usuarios) tratamos de definir el resultado esperado. Así, hablamos de dos tipos de resultados esperados: los que tienen que ver con el impacto en el negocio y los que tienen que ver con cómo cambia el producto y su relación con los usuarios.

Los resultados de negocio

Para los primeros podemos definir key performance indicators (las conocidas KPIs). Por ejemplo, el número de nuevos usuarios registrados, o de descargas de un cierto producto, o aquello que sea relevante desde el punto de vista del negocio.

Para mí es clave que todos los involucrados en la cadena de valor conozcan cuál es el impacto de su trabajo en los resultados de negocio. Por un lado conseguimos empatía e identificación con una causa común, lo cuál es importantísimo en términos tribales. Pero es que además, el aprendizaje que se produce provoca que las decisiones que se toman (individual o colectivamente) estén cada vez más alineadas, permitan reducir el coste de control y gestión, y favorezcan la innovación, pues es más fácil aportar una nueva idea si conoces mejor por qué se toman las decisiones y de qué manera éstas afectan a los resultados.

Estas conversaciones se pueden tener con la cadencia que más convenga y es fácil tenerlas en formato presentación y debate de los resultados. Cuanta mayor sea la frecuencia, más fácil será para todos conectar el impacto del trabajo con la observación de las métricas, pero no siempre es fácil recolectar la información. Siempre será una buena inversión tener un cuadro de mandos lo más actualizado posible, que lo haga con la mínima intervención humana, que esté a disposición de todos los involucrados y que muestre una perspectiva temporal, para entender tendencias pasadas e imaginar tendencias futuras. Las conversaciones alrededor de este tipo de cuadros pueden estar orientadas primero a entender y luego a decidir, para conseguir la participación de todos, pues normalmente no participamos en algo que no entendemos. Bueno, algunos “cuñados” sí, pero no es lo que queremos. 🙂

Experimentos

Es muy importante para los equipos ágiles que el resto del negocio lo sea. Si se convierten en meros ejecutadores de los planes de otros, nos quedamos con muy poco de la mejora que el agilismo puede traer a un compañía. Especialmente en términos de supervivencia, pues la innovación viene directamente de una mentalidad orientada a experimentar, y las empresas que no innovan están condenadas a desaparecer.

Y no es tan difícil. Basta con ser conscientes de que todo lo que se hace en la organización son experimentos y que, según el método científico, para cada uno de ellos establecemos antes una hipótesis que debe ser refutada (o no) al final del mismo. Toda vez que es aceptado que se puede haber construido algo, puesto en producción y no haber obtenido los resultados esperados, todo estará bien, porque al menos se habrá aprendido que estabamos equivocados en nuestra suposición. Por tanto, las conversaciones que nos llevan a aprender de nuestros experimentos son cruciales para el éxito del negocio.

Una posible herramienta para recopilar el aprendizaje tras el experimento de poner en producción una funcionalidad nueva (o un cambio en una ya existente) sería la Learning Card (íntimamente relacionada con la Test Card, de la que ya hablé en el capítulo I). Debo confesar que aún no he podido usar la Learning Card. Si tú tienes alguna experiencia, por favor, compártela aquí.

Portfolio, presupuestos y estrategia

En cualquier caso, la inspeccion y adaptación que hacemos en cada uno de estos ciclos de retroalimentación nos puede llevar, en el caso más extremo, a tener que pivotar y cambiar de modelo de negocio. Para tomar esta decisión necesitamos tener una visión global de todos los proyectos, productos, servicios y/o iniciativas estratégicas que estamos financiando con los presupuestos de nuestra organización. Es lo que llamamos el portfolio.

Todos los frameworks de escalado Agile abordan este asunto de una manera u otra, pero no suelen entrar en cómo se financia cada uno de estos elementos. Quizás uno de los que lo aborda de una manera más detallada sea SAFe con su gestión del portfolio Lean. Define unas responsabilidades que se deben tener en cuenta y propone que se coordinen una serie de roles para tomar decisiones. En mi opinión, Kanban ESP lo resuelve algo mejor con la Strategy Review (descrita aquí muy esquemáticamente en la diapositiva 28). Sin embargo, ninguno de los dos enfoques me terminan de convencer porque, en una cultura jerárquica (que son la inmensa mayoría), es fácil que la información importante no fluya y que, por tanto, las conversaciones que se deben producir no se establezcan entre las personas adecuadas.

Una herramienta que he conocido recientemente y que estoy deseando poner en práctica es el portfolio de modelos de negocio (de los creadores del archiconocido Business Model Canvas). Me gusta mucho porque obliga a visualizar la estrategia de la empresa y facilita los debates acerca de la misma. Esto, en combinación con procesos genuinamente participativos, podría ayudar a romper los silos funcionales de las organizaciones jerárquicas y poner a los gerentes a resolver impedimentos y dar guía estratégica más que a establecer planes que deben ser cumplidos, con lo que las conversaciones dejarían de ser monólogos de arriba hacia abajo y pasarían a ser conversaciones entre pares con diferentes grados de especialización en su trabajo pero con un propósito compartido, que es la misión de la compañía.

Si tu empresa es pequeña, igual esto de los portfolios resulta innecesario, pero créeme que a la que la empresa crece un poco ya no hablamos de conversaciones sencillas y objetivables, con tableros, métricas y demás, sino que entran en juego otras variables como compromisos con instituciones fuera de la organización (inversores, accionistas, sindicatos, etc) y, sobre todo, el reparto del poder. A esas conversaciones las conocemos como “hacer política”, pero ya quedan fuera del ámbito de esta serie de artículos.

Los cambios en el producto

Distingo entre producto y negocio porque no siempre es lo mismo. Voy a poner un ejemplo.

Seguro que alguna vez has estado comprando en una tienda online y te ha aparecido un “mensaje persuasivo”. ¡Compra ya! ¡Sólo quedan 2 en el almacén!. ¿A que sí? Bien, es un poco molesto, ¿verdad? Sobre todo porque en la inmensa mayoría de los casos no es cierto que haya escasez de ese producto. Simplemente están tratando de convertir tus dudas en una compra. Te están persuadiendo. Y el caso es que lo hacen porque funciona. Podría poner otro ejemplo. Los anuncios en mitad de la pantalla para que te registres o conozcas una nueva oferta antes de seguir navegando. En fin…

El caso es que es difícil pensar en una historia de usuario que diga: “Como usuario que aún no me he registrado, quiero que me muestren un formulario en mitad de la pantalla para registrarme y que la tienda sepa mucho más de mi aunque no esté seguro de si voy a comprar o no”. Claro, nos suena raro porque nos estamos olvidando de satisfacer al usuario y pasamos a satisfacer a algún departamento de nuestra empresa (probablemente Finanzas o Marketing).

No podemos resolver esa impedancia fácilmente. El negocio tiene que seguir funcionando y para ello tenemos que seguir haciendo anuncios y persuadiendo a los usuarios para que compren. Pero sí que podemos dedicar más tiempo a imaginar de qué manera hacerlo mejor. A éso lo llamamos mejorar la experiencia de los usuarios. Y sólo la podemos mejorar incorporando su feedback.

En el diagrama con el que empezaba esta serie, esta feedback llegaría a una parte del proceso que no hemos dibujado. Algunos la llaman ideación, otros upstream. Personalmente prefiero ideación porque me sugiere que el objetivo es producir ideas que luego serán clasificadas, priorizadas, construidas y puestas a disposición de los usuarios para validar nuestras hipótesis. Aquí es donde entra en juego Design Thinking y otros métodos similares. En el fondo, lo que uses es lo de menos. Lo importante es cómo llegan las ideas a tu proceso de desarrollo y cómo vuelve el feedback.

Aspiro a que algún día pueda completar esta serie de artículos con las conversaciones que se producen durante esta parte del proceso. Y aspiro también a que algún día todos llamemos a la ideación, parte del proceso de desarrollo de software, y no lo tratemos como algo separado. Enfoques más integradores como Lean UX aún no parecen que hayan encontrado un encaje perfecto en los contextos más industriales, a pesar de qué marcos de escalado como SAFe proclaman que le han encontrado ese hueco. Permíteme que sea un poco descreído aquí hasta que tenga evidencias.

Experiencia de usuario

El precio de nuestro producto, por ejemplo, puede afectar a la opinión del usuario (si es que, además de usuario es cliente), pero la experiencia de uso es clave. Si no entiende cómo usarlo, si se ha creado una expectativa y luego no puede satisfacerla, si se encuentra con obstáculos que le impiden conseguir su objetivo fácilmente… entonces no está contento y su opinión será negativa. Así que, si queremos conocer cómo de buena ha sido su experiencia de usuario, habrá que preguntarles. Hay muchas maneras de hacerlo.

Una medida indirecta son las métricas de negocio de las que hablaba más arriba. También les podemos preguntar: con encuestas, entrevistas, observación diferida, pruebas de usabilidad, formularios tipo UserVoice, etc. Todas estas herramientas y técnicas se basan en (de alguna manera) establecer una conversación con los usuarios, incluso aunque estos puedan ser miles o incluso más.

Por supuesto, también existen técnicas cuantitativas: generalmente medidores embebidos en nuestro código que nos permiten analizar el comportamiento de los usuarios al usar nuestro software sin molestarles. De esta manera podemos saber de dónde nos llegan los usuarios (por ejemplo a nuestra página web), de qué página a qué página navegan más, establecer mapas de calor que nos permita saber qué botones se usan más y cuáles menos, etc. Pero bueno, así no tenemos lo que normalmente entenderíamos como una conversación, pero sí podríamos abstraernos un poco e imaginar que los cambios que incorporamos en nuestro producto a partir de lo observado con estas métricas es el resultado de una cierta “conversación” con los usuarios de manera agregada.

Tests A/B

Si construimos nuestras funcionalidades como experimentos independientes, que pueden ser ejecutados contra una muestra de la población mientras la funcionalidad original sigue siendo ejecutada para el resto de usuarios, y comparamos ambos resultados, entonces podremos validar o refutar la hipótesis correspondiente. Si la validamos, eliminamos la funcionalidad vieja y nos quedamos con la nueva. Si la refutamos, habremos mejorado nuestro entendimiento de los usuarios y podremos seguir experimentando para darles algo que les satisfaga más.

En todos los casos, la idea es conocer con el mayor detalle qué hacen los usuarios cuando usan nuestro software. Y mejor aún si además sabemos qué piensan. Actualizar nuestras User Personas a partir de las observaciones cuantitativas y/o cualitativas sería un resultado del feedback que no deberíamos perder de vista.

Iterativo e incremental

En otros sitios ya he escrito sobre cómo Agile propone construir productos de manera iterativa e incremental, es decir, de a pocos. Para explicar este concepto, yo suelo usar la imagen de Monalisa que popularizó Jeff Patton y que resumen muy bien en este artículo.

En este contexto ya hemos hablado de herramientas que nos ayudan a planificar de esta manera. Yo soy un gran fan de User Story Mapping porque, de una manera muy sencilla, provoca conversaciones muy potentes entre todas las personas involucradas y es muy fácil crear un plan de versiones iterativo e incremental, partiendo de un producto mínimo viable (MVP) y sobre el que vamos añadiendo funcionalidades.

También ya he comentado que me gustan bastante los Impact Maps porque permiten conectar con la estrategia de producto y las métricas de negocio. Las conversaciones que se producen entre las personas que participan en la creación de los mismos son realmente enriquecedoras para todos.

Además, Vicenç nos recomendó el Event Storming en la primera entrada de esta serie. Lamentablemente no he tenido tiempo de echarle un vistazo a las lecturas que recomendaba, así que no puedo opinar.

El mayor problema de cualquiera de estas herramientas es que es fácil que las usemos sólo al principio y que nos olvidemos de incorporar el feedback que obtenemos a medida que el proyecto o producto avanzan. Y con ello perdemos una de las mayores ventajas que el enfoque iterativo e incremental nos aporta: la capacidad de adaptarnos a lo que vamos descubriendo.

El último momento responsable

En general somos reacios a cambiar nuestros planes. Vivimos con la creencia de que un buen plan es el que se ejecuta completamente. Además, pensamos que cualquier cambio en el plan una vez comenzada su ejecución provocará un gran desperdicio porque son interrupciones, cambios de prioridades, etc.

El último momento responsable es un punto difícil de identificar, pero tenemos múltiples oportunidades para tomar decisiones que afectan a nuestros planes. Las reuniones de planificación de Scrum o las de reabastecimiento (o replenishment) de Kanban son ideales. Dependiendo de la situación, igual también podemos incorporar feedback a nuestro producto en las reuniones de refinamiento. Podemos ir yendo atrás en el proceso de desarrollo e ir reconsiderando decisiones que hemos ido tomando cada vez con un grano más grueso. Incluso, como ya he comentado más arriba, no deberíamos descartar cambios más drásticos como pivotar y movernos a un nuevo modelo de negocio. Lo importante es que sean decisiones que vienen alimentadas por feedback de nuestros clientes y usuarios, porque es lo que garantiza que sigamos trabajando para ellos.

Feedback sobre los procesos

La mayor diferencia entre los métodos Ágiles y el resto es que estos aceptan que no son perfectos y que, para ser realmente eficaces y adaptarse a las necesidades de cada organización, deben también ser modificados. Por ello, igual que incorporamos el feedback de los clientes en nuestros productos, debemos hacer lo mismo con el feedback de los usuarios de nuestros procesos internos, es decir, de nosotros mismos.

Me gustaría aquí distinguir dos categorías. Por un lado, el feedback centrado en actividades, tareas, procesos, herramientas, etc, es decir, en la parte más mecánica de cómo trabajamos. Y por otro lado, el feedback centrado en las relaciones entre personas, es decir, la parte más emocional.

Las actividades y tareas

Como se dice en el Manifiesto Ágil: “aunque valoramos los elementos de la derecha, valoramos más los de la izquierda”. Es decir, aunque valoro los procesos y herramientas, le doy más importancia a los individuos y sus interacciones. Sin embargo, cambiar los procesos hará que cambie el contexto de las personas y éstas se adaptarán al mismo, normalmente cambiando sus comportamientos, incluidas las interacciones entre ellas. Por tanto, es muy importante que entendamos el impacto que los cambios en los procesos tienen en el conjunto de nuestro sistema.

Mirar hacia atrás

La mayoría de los métodos ágiles incorporan algún feedback loop para revisar el propio proceso. Scrum, por ejemplo, propone las retrospectivas. Kanban propone cadencias (reuniones periódicas) alimentadas por datos, y las distingue dependiendo de dónde esté poniendo el foco. A nivel de equipo, es muy fácil de implementar una Service Delivery Review en la que, al menos, echemos un vistazo a métricas fáciles de registrar (como lead time y throughput) y revisemos nuestros WIP limits aprendiendo de lo que vemos en nuestro diagrama de flujo acumulado (CFD).

También podemos diseñar talleres de Value Stream Mapping para identificar y eliminar desperdicios. Aunque pueda parecerlo, no consisten en hurgar en la basura sino en analizar un proceso, todos juntos, con el espíritu de encontrar oportunidades de mejora. A veces hay que complementarlo con alguna formación previa para que los participantes sea capaces de distinguir qué aporta valor realmente y qué no.

La agrupación de bloqueos (blocker clustering) es una técnica que también puede ser muy útil para entender y mejorar nuestros procesos. Personalmente no la he usado, pero hay buenas experiencias con ella y creo que merece la pena que la probemos. Como digo siempre, si tienes alguna experiencia que compartir, por favor, usa los comentarios de ahí abajo. Serán más que bienvenidos.

Insisto una vez más en que lo más importante en estas reuniones no son tanto la eficacia de las medidas de mejora que se pongan en marcha como el entendimiento colectivo que se produce a través de las conversaciones.

El problema que he observado sistemáticamente es que es muy fácil ser reactivo y cortoplacista en la mejora continua. Es frecuente que sólo pensemos en qué arreglar cuando llega el momento de la retrospectiva y que no veamos más allá. Por eso abogo tanto por las iteraciones muy frecuentes (semanales), porque favorecen que nuestros recuerdos estén frescos y que podamos pasar fácilmente a una mentalidad en la que cualquier problema en los procesos se trata inmediatamente, al más puro estilo Jidoka.

Mirar hacia adelante

Las retrospectivas no tratan, por defecto, la mejora continua con acciones estratégicas, es decir, que contemplen objetivos a largo plazo y de impacto más sistémico. Esta carencia se puede compensar con métodos como A3 Thinking o Toyota Kata.

A3 Thinking es muy sencillo y yo suelo usarlo como técnica para conseguir que equipos de trabajo acuerden planes de mejora siguiendo un enfoque experimental, pues reserva una parte del debate a establecer la validación de si, una vez ejecutado el plan, se ha conseguido o no el cambio deseado. Jaume Jornet tiene aquí un buen resumen de esta técnica y aquí te dejo una plantilla simplificada con un ejemplo que vengo usando desde hace años. Cópiala y hazla tuya sin problemas.

Toyota Kata es un método más elaborado. Aún me estoy leyendo el libro de Mike Rother y tampoco he podido usarla en primera persona, aunque en esta serie de artículos, Peter Kerschbaumer explica su experiencia empleando Toyota Kata para mejorar el tiempo de entrega de software en eDreams ODIGEO. Si sólo quieres una introducción, te recomiendo este video de Hiroshi Hiromoto. Lo más relevante de esta técnica es que está fuertemente basada en conversaciones de acompañamiento (Coaching Kata). El rol de los managers, por tanto, pasa de ser gestores de recursos a facilitadores de estas conversaciones, aunque quizás al principio de la introducción de esta técnica necesiten de alguien que les ayude a adquirir las habilidades necesarias.

Las relaciones entre personas

¡Ay, las personas!

Hace años, ya en reeeLab tratamos de poner foco en las habilidades de comunicación, negociación, gestión de equipos y motivación, en un taller que llamamos “Las habilidades del ScrumMaster”. Hoy le cambiaría el título y lo llamaría algo como “Las habilidades de cualquier trabajador del conocimiento”, pero no modificaría los objetivos del mismo. En este tiempo he llegado a la conclusión de que, si queremos instalar procesos de mejora continua en un entorno de incertidumbre con trabajadores del conocimiento, no nos queda más remedio que habilitar a todo el mundo involucrado con el mayor número posible de estas habilidades.

Dar y recibir feedback

De entre todas las habilidades, la que está en la base de todas las demás es dar y recibir feedback. En eDreams ODIGEO, mis compañeras del departamento de Learning & Development desplegaron un plan de formación específico, con muchísimo énfasis en la práctica, y que fue impartido al 100% de los empleados. Gracias a ello, las relaciones entre todos los empleados mejoró sustencialmente, a todos los niveles y en todos los contextos (no necesariamente ágiles). Por ejemplo, los conflictos ya no necesitaban (siempre) de la intermediación de un manager (o un Agile coach). Así, la presencia de un facilitador externo al grupo en una retrospectiva dejaba de ser necesaria, lo que permitió a los Agile coaches poner el foco en otras actividades, por ejemplo, en ayudar a los equipos a facilitar sus propias retrospectivas.

Esta charla de Raúl Quesada en la reciente CAS2017 me parece que explica muy bien el valor de adquirir y entrenar esta hablidad, e incluso da consejos que te serán muy útiles.

Identidad y valores

De todos modos, saber decirnos las cosas a la cara es necesario, pero no suficiente.

Creo que hablé en su momento de la dinámica de Alberto Martín sobre las 5 disfunciones de un equipo. Si en un equipo no hay confianza, ni se pueden abordar los conflictos, ni hay compromiso, ni responsabilidad, ni atención a los resultados, pues ya me dirás qué van a poder hacer juntos… Lo bueno de este enfoque es que nos aporta un criterio de por dónde empezar a trabajar las disfunciones, lo cuál ayuda mucho a la hora de plantear un proceso de mejora. Así, no tendría mucho sentido hablar de cómo mejorar nuestra atención a los resultados (por ejemplo, haciendo tableros para visualizarlos) si en realidad lo que pasa es que no la gente no se hace responsable de esos resultados. De hecho, bien podría ser que la causa raiz de todo ello sea un entorno donde no se fomente la colaboración sino la competencia, provocando que nadie se fie de nadie.

Personalmente me gusta mucho trabajar sobre la identidad de los grupos (normalmente equipos, pero también pueden ser roles). Le doy un enfoque muy tribal, por lo que pongo mucha atención a los símbolos que les permitan identificarse y a las misiones que los alineen en el trabajo que comparten. A partir de ahí me es más fácil trabajar para alinearnos en valores. Para ello suelo organizar retrospectivas específicas sobre los valores del equipo y facilito que debatan entre ellos acerca de los mismos. Me gusta especialmente la dinámica en la que les pido que reflexionen sobre qué significan para ellos los conceptos “autoexigencia”, “autodisciplina” y “ritmo sostenible”, que para mí reflejan tan bien la mentalidad del agilismo.

Todas estas conversaciones son muy íntimas, muy del grupo, y por ello son oportunidades excepcionales para que ellos mismos se den feedback unos a otros. También son buenas ocasiones para darles un tipo de feedback del que no he hablado hasta ahora, el del observador del grupo (en mi caso, el del Agile coach).

El feedback del Agile coach

El Agile coach actúa como un observador de los procesos y las personas. En este sentido, su feedback es privilegiado porque no está involucrado en las actividades del dia a día del resto.

La mayoría de los ScrumMasters, Agile coaches, agentes de cambio, consultores ágiles, etc que conozco, suelen comportarse más bien como consultores, cuyo objetivo es encontrar y ofrecer oportunidades de mejora para la organización (al nivel que cada uno pueda). Yo también lo hago en las organizaciones donde trabajo, y para ello aprovecho que soy ese observador privilegiado del que antes hablaba. Sin embargo, corremos el riesgo de convertir esta posición en imprescindible porque, de alguna manera, está evitando que el resto de la organización ponga el foco en la mejora continua.

Yo soy más de la opinión de que nuestro rol consiste en habilitar a las personas que ya están en la organización con las habilidades y la mentalidad necesarias para hacer este trabajo de identificación y ejecución de oportunidades de mejora. Ésa es una diferencia fundamental, lo cuál no quiere decir que frente a la pregunta “¿cómo podemos resolver este problema?” me parezca aceptable responder por sistema “¿y tú cómo lo resolverías?”. Está bien dejar espacio a que la gente encuentre sus propias respuestas a los problemas, pero no parece sensato dejar que la gente tarde 10 semanas de ensayo y error para encontrar una solución que, en una conversación de 1 hora, tú bien podrías haberles proporcionado junto a otras dos o tres opciones más y un poco de criterio para que ellos mismos decidan cuál es la que más les conviene para el problema en cuestión.

Además, a mí me gusta retar e irritar de vez en cuando para sacar a la gente de su zona de confort, que es donde se aprende. Para lo que, desde luego, intento crear siempre una relación de confianza tal que todos sepan que no soy ni un bastón ni un espejo, sino una vela con la que iluminar (algunos tramos) del camino.

Frameworks y feedback loops

Todos los métodos Agile (Scrum, Kanban o el que cualquiera se esté inventando en estos momentos) tendrán estos feedback loops que he comentado más arriba. De una u otra manera los contemplará, porque la mejora continua está en el ADN del agilismo.

Por ejemplo, Scrum habla del Sprint Review como esa oportunidad para revisar resultados, también la Retrospectiva para revisar procesos. La Service Delivery Review que proponen en Kanban ESP y que ya he comentado anteriormente, contempla discutir sobre cómo cada servicio está ajustando sus resultados a las expectativas de negocio previamente establecidas.

Si no trabajas con ningún framework, tranquilo. Simplemente no olvides que tienes que inspeccionar y adaptarte cuanto más frecuentemente mejor. Reserva en vuestro calendario un poco de tiempo para aprender de lo que ha sucedido hasta el momento y actuar en consecuencia. Para ello, hablad entre vosotros. En serio. Es la mejor herramienta.

Facilitación de conversaciones

Las conversaciones entre personas son un tipo particular de relación. Ya apuntaba más arriba que es necesario trabajarnos ciertas habilidades (soft skills) para que estas relaciones sean más fluidas. Además, también podemos identificar a personas dentro de los grupos y las organizaciones para que pocan mayor foco en según qué conversaciones.

El rol de dueño de producto es, en esencia, un facilitador de conversaciones que tienen que ver con el producto. Insisto en que es un rol, y no un puesto, porque no creo que sea imprescindible implementarlo en todos los casos como una cajita del organigrama. Creo que las responsabilidades y habilidades para desarrollar este rol pueden estar perfectamente desplegadas en el seno del equipo, de una manera autoorganizada. Lo he visto, y funciona.

Lo mismo podría decir del rol del ScrumMaster, que normalmente pondrá más foco en facilitar las conversaciones que tienen que ver con los procesos y las personas. Como antes, creo que es un rol que cuando es desempeñado de manera autoorganizada, dota al grupo de una mayor corresponsabilidad respecto de la mejora continua.

En algunos contextos he visto otros roles como el Flow Facilitator, una especie de ScrumMaster en equipos Kanban, encargado de que el equipo ponga foco en mantener un flujo sostenible de trabajo y que algunos también han llamado Flow Manager. Personalmente prefiero el término Flow Facilitator.

También he visto recientemente el rol de Release Owner, encargándose de que el tren de releases parta en tiempo y forma, informando del calendario y resolviendo los conflictos de la integración. En cualquier caso, la mayor parte de su tiempo lo dedica a facilitar conversaciones que permiten actualizar los acuerdos de trabajo de un equipo en esta parte del proceso.

Documentar las conversaciones

No quiero acabar este capítulo sin hablar de cómo documentar todas estas conversaciones, porque es muy tentador pensar que si estas conversaciones las registramos estaremos guardando su valor. En realidad no es así, las conversaciones son más o menos valiosas dependiendo de lo que suceda a continuación. Por tanto, como no lo sabemos de antemano, tratemos de viajar lo más ligeros de equipaje que podamos.

La idea de un documento de especificación de requisitos que se va rellenando no es bueno. He visto infinidad de historias de usuario en JIRA, donde cada cuál va poniendo su parte hasta que el documento llega a alguien que tienen que ejecutarlo. Es evidente que esa “documentación por deposición” no es útil. Necesitamos “documentación por conversación”, que registre sólo aquello que sea imprescindible y en función del contexto.

Por ejemplo, si tenemos un entorno muy complejo donde los detalles técnicos de una API son importantes para desarrollar una historia, quizás sea bueno dejarlo documentado en algún sitio. O quizás no, porque a fin de cuentas es algo que estará en el código y que, con una buena documentación técnica ejecutable (por ejemplo los tests de aceptación) podrían dejar claro ese detalle.

Otro ejemplo podría ser el de detalles de UX que se pueden ir actualizando con cada historia de usuario en una Guía de Diseño que esté viva en nuestra wiki. Igual con los manuales de usuario. Recuerda que, como agilistas, valoramos más los artefactos que aportan valor a los usuarios que la documentación que pretende demostrarlo, lo cuál no quiere decir que no tengamos que trabajar en ningún manual, informe o presentación que ayude a comunicar y que no pueda ser automatizado o eliminado.

Lo que sí me gusta que quede por escrito, al menos al principio de la vida de un equipo, son los acuerdos de trabajo. Hacerlos explícitos ayuda mucho a que no haya ambigüedades y a enfocar los debates en los procesos en vez de en las personas. Así, podemos pasar de “es tu culpa” a “este acuerdo necesita ser revisado”.


Conclusiones

Y por fin acabo esta serie. Debo reconocer que ha sido un ejercicio duro porque he tenido que poner en orden muchísimas ideas. Seguramente se me habrá quedado alguna en el tintero. Aun así he superado las 18000 palabras (WordPress dixit), de modo que creo que es mejor dejarlo aquí. 🙂

Me gustaría haber comentado sobre las conversaciones que suceden (o deberían suceder) durante el proceso de transformación de una organización, pero no quería salirme tanto del objetivo de esta serie: las conversaciones en el proceso de desarrollo de software. Sin embargo, al menos tangencialmente, he tocado otros procesos como el de desarrollo de producto o el de desarrollo de la estrategia de negocio. Creo que era imprescindible para entender que Agile provoca un cambio social y de procesos que se mete hasta las entrañas de una organización. Y que hay conversaciones muy necesarias en las que debemos participar lo más activamente posible.

Espero que al menos te haya sido ameno leer esta serie y que, ojalá, también te haya sido de utilidad. Si te ha gustado, como dicen los youtubers, “dale a Like, participa en los comentarios y comparte en tus redes sociales”. 🙂

 

LA FOTO: Es un detalle de un cuadro de Escher basado en una escalera de Penrose. Me parece que ilustra muy bien ese proceso de mejora continua en el que me he centrado en el artículo de hoy.