¿Hay algún póster con buenas prácticas de historias de usuario?

Miguel Ángel, aprovechando un curso de historias de usuario que ha preparado, ha actualizado su póster con buenas prácticas que compartí en un post en febrero, me lo acaba de enviar así que aquí lo dejo para todo aquél para el que le pueda ser de utilidad.

Descargas / Downloads

El póster actualizado de buenas prácticas de historias de usuario.

Mis agradecimientos a Miguel Ángel Sobrino por compartir su póster actualizado a través de mi blog y por ponerlo a disposición de toda la comunidad y todos aquellos que les pueda ser de interés.

¿Scrum en Servicio al Cliente?

Scrum es aplicable a todos los ámbitos donde haya incertidumbre y donde haya que realizar mucho aprendizaje. Uno de estos ámbitos está en Servicio al Cliente, en el equipo que define los procesos de relación de la compañía con sus clientes. Si queremos dar la mejor experiencia a nuestros clientes hemos de ser conscientes de que vivimos en un mundo en constante cambio, y que la forma en la nos relacionamos e interactuamos con ellos debe de adaptarse constantemente a través procesos en mejora continua. Scrum a través de sus sprints permite construir los procesos de relación con el cliente de forma incremental y adaptativa.

Call centers con buena experiencia de cliente se basan en procesos en continua adaptación - cortesía de Pixabay

A principios de año inicié el acompañamiento en Scrum de un gran equipo de equipos de procesos, cuyo objetivo es mejorar la experiencia de los clientes, solucionando elementos deficientes y haciendo evolucionar los procesos de forma continua. La primera actividad que hicimos fue explicitar los valores que deberían de subyacer en el equipo y escribieron su propio Manifiesto Ágil de Servicio al Cliente, el resultado fue espectacular y encarriló al equipo a ser verdaderamente centrados en el cliente.

Una pila de producto de procesos consiste en elementos que hagan evolucionar el proceso, estos elementos pueden consistir en deficiencias y mejoras. Los elementos más grandes de la pila son los problemas que hay detrás de deficiencias y mejoras, son puntos de relación donde a nuestros clientes les "duele" o no les es agradable pasar, se los conoce como "pain points". La estructura de tipos de elementos de la pila propuesta es la siguiente:

• Tema: Pain points o puntos de dolor de nuestros clientes
• Epic: Causas raíz, cada una de ellas tiene un impacto y valor propio
• Historias de usuario: Soluciones a las causas raíz que sean implementables en los procesos

Historias de usuario que tratan pain points del proceso de facturas

Las historias de usuario de servicio al cliente se centran en la relación con los clientes, son historias más emocionales, similares a las de marketing.

Una historia de mejora puede tratar de cambiar el texto de una comunicación a nuestro cliente y mejorar la difusión del mensaje del 30% al 70% por ejemplo.

Una historia que trata de resolver una deficiencia puede ser mejorar la claridad y transparencia en la apertura de la incidencia, como por ejemplo informar al cliente del numero de incidencia.

En una pila de procesos hay más historias exploratorias que en una pila de un producto de software, dado que sus elementos influyen directamente en la relación con los clientes, es clave validar toda idea e iniciativa de forma rápida antes de implementarla. De la misma manera los criterios de aceptación son más bien criterios de éxito, hay que encontrar el proceso idóneo para gran parte de nuestros clientes, es imposible que lo vaya a ser para todos, quizá 3 de cada 4 sea un objetivo excelente y factible.

Equipo de procesos ante su pila de producto

Los equipos dedicados a los sprints de procesos son similares a los equipos de TI, son multifucionales y autoorganizados. En lugar de Propietario de Producto tienen un Propietario del Proceso y los perfiles de especialistas incluyen especialistas en todas las áreas necesarias para implementar procesos de principio a fin.

Entre estos especialistas puede haber expertos en los procesos existentes, frontliners que son comerciales y profesionales de los call centers para proporcionar feedback de primera mano sobre el funcionamiento de las mejoras de procesos, su facilidad de uso y el propio feedback de los clientes, y dado que probablemente la mitad de procesos pasen por modificaciones en las aplicaciones de software, alguien de TI para realizar una evaluación preliminar de posibles soluciones técnicas e impactos en sistemas.

Mi experiencia con estos equipos no constructores de software ha sido sorprendente, son menos binarios que los equipos de TI y la consolidación de Scrum en su forma de trabajar ocurre muy rápidamente, suelen decir que Scrum es una forma natural de trabajar.

Un miembro de un equipo de procesos me dijo que deberían de hacer sprints de una semana, ya que de esta forma el ciclo de feedback del cliente seria más corto y podrían encontrar las mejoras en los procesos de forma más rápida... ¡en Servicio al Cliente habían interiorizado los valores y prácticas de Scrum!

Este post también lo publiqué en el blog de Scrum Manager, y también "apareció" en el blog de PMIdeas, hecho que me halaga ya que muestra la repercusión de mis posts. :-D

¿Cómo alinear a las tribus desde la capa de estrategia?

QBR - Presentando valor entregado y resultados de negocio
Cortesía de Pixabay

ING tomó prestada una idea de Google y Netflix que agregó en forma de evento escalado al modelo Spotify, se trata del QBR, Quarterly Business Review o Revisión Comercial Trimestral.

A este evento asisten miembros relevantes de la junta de dirección, Tribe Leads y representantes relevantes de la tribu, como Product Managers, Business Owners y arquitectos, con el objetivo de revisar la entrega de valor trimestral de las tribus y los resultados de negocio obtenidos, y alinear a las tribus en estrategia, visión de negocio y definiendo objetivos trimestrales y hojas de ruta.

Tablero con los logros de la tribu por squad

Para el evento cada tribu recopila lo que logró durante el último trimestre, así como su mayor aprendizaje, mostrando tanto los éxitos como los fracasos, y describiendo lo que pretende conseguir durante el próximo trimestre y qué otras tribus o squads requerirá.

El Tribe Lead, apoyado por Propietarios del Producto y Chapter Leads, es el responsable de dar formato a toda la información a través del documento QBR, un documento de no más de 6 páginas que resume los resultados del último trimestre y describe los objetivos para el próximo trimestre, e incluye los siguientes puntos:

1. Introducción: Incluye un resumen ejecutivo del documento QBR con una actualización basada en hechos sobre el progreso hacia el propósito de la tribu
2. Visión y estrategia de la tribu: Incluye la definición del enfoque para la priorización
3. Revisión retrospectiva del trimestre anterior: Incluye la lista de iniciativas principales (hasta 10) del anterior trimestre, sus resultados y causas de raíz de éxito/fracaso
4. Hoja de ruta para el próximo trimestre: Incluye la lista de iniciativas principales (hasta 10) para el próximo trimestre con una descripción de alto nivel

QBR - Tribe Leads sincronizando tribus desde la estrategia
Cortesía de Pixabay

Los documentos QBR de todas las tribus deberían de estar disponibles abiertamente a toda la compañía al menos dos semanas antes del evento QBR, para que todos puedan leerlos y ofrecer feedback a través de comentarios y opiniones.

En el evento se tratan las iniciativas de las tribus desde un punto de vista estratégico y se discuten las interdependencias entre estas tribus. También se tratan preguntas abiertas, aunque no es recomendable entrar en detalles de tribu y salirse de lo estratégico, lo táctico no es objetivo del QBR.

Una vez finalizado el QBR los Tribe Leads obtienen el documento QBR enriquecido con comentarios de otros Tribe Leads, que resultan estratégicos para la hoja de ruta del próximo trimestre, así como estimaciones consensuadas a nivel estratégico del impacto esperado en el cliente/propósito.

¿Cuál es el ciclo de eventos del modelo Spotify?

Primero recordar que Henrik Kniberg y Anders Ivarsson hicieron público su modelo de Spotify para que ayude a comprender a otros cómo se hacen las cosas en Spotify, y que no pretende ser un marco de escalado que puedan aplicar otras compañías tal cual lo explican. El modelo cambia continuamente, Spotify alienta a sus empleados a aprender y adaptar su forma de trabajar continuamente.

Lo que conocemos hoy en día como el modelo Spotify ha sido enriquecido por otras compañías, como ING en Holanda, y en este post quiero presentar el ciclo de eventos que aplicamos actualmente.

EVENTOS DE SQUAD

---

Planificación de sprint

Periodicidad: cada sprint (primera actividad del sprint)
Asistentes: Squad, Propietario del Producto y Scrum Master/Agile Coach

Objetivos:

• Planificar siguiente sprint y obtener objetivo y pila de sprint
• Compromiso del squad e interesados

Reunión diaria

Periodicidad: diaria
Asistentes: Squad y Scrum Master/Agile Coach (Propietario del Producto para aclaraciones sin voz ni voto)

Objetivos:

• Microplanificación a través de la autoorganización del squad
• Visibilizar el avance del incremento

Refinamiento

Periodicidad: cada sprint (a mitad de sprint)
Asistentes: Squad, Propietario del Producto y Scrum Master/Agile Coach

Objetivos:

• Refinamiento de la pila de producto
• Inserción, retirada, repriorización, estimación y división de las historias de usuario

Revisión de sprint

Periodicidad: cada sprint (al final)
Asistentes: Squad, Propietario del Producto, Business Owners y Scrum Master/Agile Coach

Objetivos:

• Entrega del incremento construido
• Ciclo de feedback de mejora continua del producto

Retrospectiva

Periodicidad: cada sprint (última actividad del sprint)

Asistentes: Squad, Propietario del Producto y Scrum Master/Agile Coach

Objetivos:

• Identificar acciones de mejora para el siguiente sprint
• Ciclo de feedback de mejora de continua del proceso

EVENTOS DE TRIBU

---

Town-Hall

Periodicidad: bimestral o trimestral

Asistentes: Interesados, directivos, Business Owners, squads, Tribe Lead, Propietarios del Producto y Scrum Masters/Agile Coach

Objetivos:

• Demos resumidas del valor ganado en el bimestre o trimestre anterior, la audiencia principal son los Business Owners
• Retrospectiva general para evaluar como se ha trabajado a nivel de tribu
• Planificación cruzada en la que se planifica las historias de usuario y objetivos factibles a lo largo del siguiente bimestre o trimestre

Scrum de Scrums

Periodicidad: semanal

Asistentes: Representantes de interés de los squads/Chapter Leads y Scrum Masters/Agile Coach

Objetivos:

• Dar visibilidad del proceso desde los diferentes squads
• Alinear el proceso según experiencias de cada squad
• Identificar y tratar impedimentos sistémicos y de tribu
• Coaching y mentoring a Scrum Masters si los hubiere

PO-Sync

Periodicidad: semanal

Asistentes: Propietarios del Producto y Scrum Masters/Agile Coach

Objetivos:

• Visibilidad del progreso de las diferentes pilas de producto
• Ajustes de prioridades
• Identificación de dependencias y sinergias

POCLAC

Periodicidad: cada sprint (a mitad de sprint)

Asistentes: Tribe Lead, Propietarios del Producto, Chapter Leads y Scrum Masters/Agile Coach

Objetivos:

• Impulsar a los squads a ser de alto rendimiento
• Propietarios del Producto trabajan el propósito de los squads
• Chapter Leads trabajan la maestría de los squads
• Agile Coach y Scrum Masters como guías en la autonomía y el foco en el proceso Agile de los squads
• Tratar el feedback de las retrospectivas
• Feedback centrado en personas

Chapter Meeting

Periodicidad: semanal

Asistentes: Chapter Lead y especialistas de los squads

Objetivos:

• Tratar prácticas de ingeniería y estrategia tecnológica transversal
• Intercambio de experiencias y soluciones

QBR (Quarterly Business Review)

Periodicidad: bimensual/trimestral

Asistentes: Miembros relevantes de la junta de dirección, Tribe Leads y representantes relevantes de la tribu

Objetivos:

• Revisar entrega de valor y resultados de negocio
• Alineamiento en estrategia, visión de negocio y definición objetivos
• Discutir objetivos bimestrales o trimestrales y tratar planes futuros

¿Porqué la reunión diaria es del equipo para el equipo?

Equipo en la reunión diaria

Recordemos que en la reunión diaria el equipo trata el avance del incremento, la situación de las historias de usuario y tareas en curso, y sobre como mitigar los riesgos asociados al sprint. La reunión le da al equipo la información que necesita para asumir una responsabilidad compartida y administrarse adecuadamente, con lo que optimiza la colaboración y su rendimiento.

Si trabajan todos en una sola historia de usuario es el momento en el que resuelven dependencias entre las distintas tareas y microplanifican el trabajo de un día para otro. La reunión optimiza la probabilidad de que el equipo cumpla con el objetivo de sprint.

Es una reunión de capital importancia, es el momento en el se produce la autogestión y gran parte de la autoorganización, por tanto la reunión debe de ser del y para equipo de desarrollo. Scrum otorga un estatus especial a aquellos que están comprometidos, y muchos equipos hacen cumplir una regla durante la reunión diaria según la cual solo aquellos que están comprometidos pueden hablar.

Debe de ser el equipo quien establezca la estructura de la reunión, se puede realizar de diferentes maneras; algunos equipos de desarrollo usan las 3 preguntas, y otros basan la reunión en discusiones y conversaciones. Cada equipo encontrará la mejor forma de hacerlo por si mismo.

¿Quién debería de ser el propietario de la pila de producto?

Product backlog LeSS

Tal como nos enseña el marco de Scrum la pila de producto es responsabilidad del Propietario del Producto. Aunque todo el mundo puede aportar elementos a la pila, él es el único que puede agregar, repriorizar, modificar y extraer elementos de la pila.

Eso convierte al Propietario del Producto en el responsable de las historias de usuario y los epics, es él quién apoyado por el equipo las escribe y las gestiona, por tanto desde esta perspectiva el es el rol adecuado para ser el responsable de la pila de producto.

Veamos otras de sus responsabilidades:

• Su compromiso ha de ser con las necesidades y los problemas de los usuarios/clientes
• Ha de crear y comunicar la visión del producto a todos los interesados, incluido el equipo de desarrollo
• Pone la misión al equipo de desarrollo indicándole en cada momento donde y qué a construir
• Es el responsable de los aspectos de financiación y de retorno de inversión del producto

Vistas estas responsabilidades, y tomando esta perspectiva, se puede ver que un Propietario del Producto tiene una responsabilidad predominantemente estratégica, qué es donde debe de estar su foco. La gestión de la pila de producto es una responsabilidad operativa, es una herramienta en que se refleja la misión y transparencia al futuro posible que definen visión y estrategia, no deja de ser una herramienta fuente para los equipos de desarrollo, y entendiendo esto podríamos cuestionarnos si no sería más adecuado que el responsable y propietario de la pila de producto fuera el equipo.

LeSS, el marco escalado basado en principios, lo marca así, todos los equipos comparten una sola pila de producto y estos son los propietarios de la misma. Un Propietario del Producto hace mucho story-telling para comunicar y transmitir al equipo las necesidades y problemas de usuarios y clientes, de forma que las comprendan con la máxima claridad y libre de dudas. Un Propietario del Producto así, cuyo foco está esta en la estrategia y la visión, no necesita conocer los elementos de la pila de producto, confía en los equipos ya que ha transmitido con toda claridad y al fin y al cabo ellos saben lo que han de hacer mejor que nadie.

Este es un ejemplo de a lo que LeSS se refiere cuando habla de que para escalar hay que desescalar: escalamos a mas equipos desecalando parte de la autoridad y responsabilidad del Propietario del Producto a los equipos, por tanto descentralizamos algunas de las decisiones propias de este rol.

Dibujo de Jurgen De Smet de la pila de producto,
de su granularidad y de como el equipo la gestiona

Un Propietario del Producto LeSS se centra en transmitir la priorización para la pila de producto, y colabora con los equipos para poner claridad a los elementos de la misma. Anima y ayuda a los equipos a entablar conversaciones directas con los verdaderos usuarios y clientes y así obtener claridad. Este actúa como un conector, no como un intermediario.

Me impactó mucho esta perspectiva de la propiedad de la pila de producto, va en contra de todo lo formalmente aprendido, pero tiene todo el sentido. En equipos maduros a los que acompaño como coach ágil, la pila de producto es minimalista, y es el equipo quien recopila la información para las historias de usuario y quien gestiona la pila. Le conté mi aprendizaje a Juan, que es Propietario del Producto en Safe Creative, una compañía con verdadera cultura Agile, y me contaba que en su caso es así, que solo es necesario darle al equipo el objetivo con ideas claras, y este se pone en marcha sin más.

Para dar respuesta al post, si operamos en un entorno ágil maduro quienes deberían de gestionar la pila de producto es el equipo de desarrollo. Impacta, ¿verdad?, para mi fue una revelación que me llevó más allá de la Agilidad, di una paso mas en dirección a Teal. :-)

¿Scrum Level cómo evalúa la Agilidad en un equipo de equipos?

La versión 2.0 de Scrum Level incorpora Agilidad escalada a nivel organizacional y técnico. Hemos aplicado Scrum Level a un tren (Agile Release Train) que opera bajo el marco de SAFe® y quiero compartir la experiencia. Veamos primero que aspectos evalúa Scrum Level.

PI Planning, cadencia y sincronización de equipos, la construcción de estructuras de colaboración organizacional

Evaluación de la Agilidad en la dimensión operativa de la empresa

---

Los factores empleados para determinar el grado de Agilidad en la dimensión operativa de la organización son:

1- Soporte directivo

El análisis debe considerar el grado con el que la gerencia proporciona el soporte adecuado para el desarrollo de la Agilidad, a través de la observación y análisis de evidencias de las siguientes acciones directivas:

• Conocimiento de la Agilidad por parte del personal directivo e implicación en la mejora.
• Compatibilidad entre el paradigma cultural de la propiedad y gerencia de la empresa, y el desarrollo de la Agilidad en la dimensión o dimensiones esperadas.
• Dotación de medios y recursos necesarios para el desarrollo y mejora de la Agilidad.
• Facilitación de la formación necesaria a todas las personas implicadas.

2- Prácticas

La siguiente tabla muestra los principios que desarrollan la Agilidad técnica, junto con el tipo de prácticas que hacen posible su implementación.

• Foco en le valor para el cliente
• Mejora continua
• Asumir la variabilidad
• Desarrollo incremental y continuo
• Ritmo de trabajo sostenible
• Calidad técnica
• Transparencia
• Cadencia y sincronización de equipos

3- Conocimiento técnico

Criterio para valorar el conocimiento técnico de las personas del grupo evaluado.

El nivel de conocimiento se evalúa según dos parámetros; como para superar un examen de acreditación Scrum Manager de nivel técnico, o un examen estándar de Scrum Master de la Scrum Alliance o la Scrum.org, y tener experiencia trabajando en equipos ágiles y empleando prácticas ágiles.

4- Conocimiento profesional

El conocimiento profesional de las personas es un factor determinante de la fluidez, pero su evaluación excede el campo de una evaluación Scrum Level.

Evaluación de Agilidad en la dimensión organizativa de la empresa

---

Los factores empleados para evaluar el grado de Agilidad en la dimensión organizativa de la empresa son:

1- Soporte directivo

Se debe determinar el grado en el que la dirección de la organización proporciona el soporte adecuado para el desarrollo de la Agilidad a través del análisis de evidencias de las siguientes acciones directivas:

• Compromiso con la mejora de la Agilidad en la dimensión organizativa de la empresa.
• Conocimiento de la Agilidad por parte del personal directivo.
• Implicación del personal directivo en la mejora de la Agilidad.
• Dotación de medios y recursos necesarios.
• Facilitación de la formación necesaria a todas las personas implicadas.

2- Comportamientos

La siguiente tabla muestra los comportamientos que desarrollan la Agilidad organizativa, junto con los valores que se encuentran tras ellos.

• Personas sobre procesos
• Gobernanza descentralizada

Experiencia de una evaluación Scrum Level en un tren

---

Después de aproximadamente 3 meses de acompañamiento en su transformación ágil de un tren de aproximadamente medio centenar de personas que operan dentro de una organización de alrededor de 2.000 personas, hicimos una evaluación Scrum Level, en la imagen inferior se puede ver el resultado.

Visto de forma agregada, el nivel de Agilidad se puede situar en 2 sobre 3 en ambas dimensiones, lo que es totalmente coherente con mi experiencia, ya que la gerencia apoya plenamente la transformación, y el marco está funcionando.

Lo que no era tan evidente, y de alguna manera resulta invisible, se refiere a la gobernanza descentralizada. La evaluación desveló un nivel muy bajo, y analizando el tema nos dimos cuenta de que nuestro tren es como una burbuja dentro de la compañía. Dentro del tren la Agilidad está muy presente, pero por fuera la compañía sigue la inercia tradicional de siempre, y es en los bordes donde se producen los conflictos y se hacen evidentes las diferencias de objetivos e intereses.

Con las PI Plannings, en las que están presentes todos los interesados, se hacen visibles los éxitos y se crean planes alineados, especialmente con las primeras se establecen las conexiones entre personas y se crean las estructuras de colaboración que permiten la resolución de estos conflictos y el alineamiento de objetivos e intereses. La transformación ágil de una compañía de estas dimensiones requiere sus pasos y su aprendizaje, que son ineludibles y no tienen atajos, por lo que en la mayoría de los casos trata de entre 10 y 15 años. :-)