jueves, 14 de junio de 2018

¿Cómo puede ayudar Scrum a una compañía tradicional que no quiere cambiar su cultura?

Las puertas representan decisiones, si no abrimos ninguna
seguiremos inmersos en la incertidumbre - cortesía de Pixabay
Tuve una interesante conversación con mi compañero José; me dijo que en los productos y proyectos de las grandes compañías no hay tanta incertidumbre como podamos creer, más bien las grandes compañías crean su propia incertidumbre... Con esta frase todos mis sentidos se agudizaron, en mi interior eso tenia sentido y nos sumergimos explorando esa posibilidad de incertidumbre inducida.

Las principales causas que crean incertidumbre en una compañía con un mando y control inflexible suelen ser:
  • El miedo a fallar es algo corriente en este tipo de compañías, y como nadie quiere fallar por las penalizaciones que pueda haber, resulta que los mandos intermedios no quieren tomar decisiones hasta que a posteriori ya no tienen riesgo. Se escaquean y le pasan la patata caliente al proveedor, de ahí que proliferen los proyectos cerrados en los que todo el riesgo lo asume el proveedor. Un proyecto liderado por un proveedor implica una toma de decisiones por parte de un jefe de proyecto que no están alineadas con el negocio, y por tanto ajenas a las necesidades reales de los usuarios. Y ya tenemos un primer grado de incertidumbre que se refuerza con la incertidumbre que genera el cliente, que para diluir la responsabilidad muestra el producto en forma de demos a gestores de TI, responsables de negocio y usuarios clave. La solución da vueltas por la compañía, y si no ha armado ningún revuelo significativo se acepta de forma tácita. Por supuesto esto lleva irremediablemente a productos mediocres.
  • Otro factor importante en la creación de incertidumbre es la no retención del conocimiento. Con cada nuevo proyecto licitian al menos tres proveedores, y si la compañía elige el más barato probablemente vendrá un equipo del proveedor que desconozca el producto y se meta de lleno en un código que desconoce y del que la documentación es insuficiente. Aunque se eligiera al mismo proveedor probablemente las personas del equipo no serian las mismas, porque en el tiempo entre proyectos el proveedor las habrá recolocado en otros proyectos. Personas ignorantes de la situación real del software se harán cargo del proyecto, ocultarán su ignorancia, y como se suele decir la ignorancia es valiente, así que se acaba inyectando incertidumbre a marchas forzadas.
  • La contratación también ayuda a crear incertidumbre; ninguna de ambas partes firmará el contrato hasta que esté convencida de que cuando se tuerzan las cosas podrá echarle la culpa a la otra parte, por tanto cuando haya problemas habrá una dura negociación alrededor las ambigüedades, asunciones y malentendidos del alcance inicial. Finalmente el cliente acabe asumiendo parte de estas como mal menor y la calidad del producto se verá seriamente afectada.
  • Cuando los intereses y objetivos de los involucrados no están alineados se produce una colaboración muy débil y ocurren situaciones imprevisibles que no sabes qué ha pasado y el proyecto toma una dirección divergente al sentido común. En este sentido los inyectores de incertidumbre más potentes son los bonus, incentivos y variables.
Scrum es un marco de aprendizaje sobre producto y proceso que a través de sus ciclos cortos lidia muy bien con la incertidumbre, y también puede lidiar con la incertidumbre inducida. Ante la carencia en la toma de decisiones, Scrum proporciona con sus ciclos cortos muchos momentos en los que los incrementos pueden rebotar en la compañía, a veces se aceptarán de forma tácita, otras se descartarán, pero de forma temprana. Ciclos cortos aceleran el aprendizaje, con lo que el conocimiento perdido se recreará antes. Ciclos cortos traen rápidamente a la luz ambigüedades, asunciones y malentendidos, con lo que sus efectos son mitigados y hasta eliminados rápidamente, y los incrementos crearán  confianza, que aunque solo fuera débil, mejorará la colaboración. De la misma manera la divergencia en los intereses y objetivos tendrá efectos tempranos y el sistema aprenderá de forma temprana a lidiar con los mismos.

Todo esto tendría sentido si la compañía permitiera una verdadera aplicación de Scrum, sospechamos que la realidad sería muy distinta, el intento acabaría en la aplicación de un ScrumBut adaptado que haya absorbido las disfunciones y problemas sistémicos, y finalmente estresaría la compañía hasta limites insospechados y se llegaría a la conclusión de que Scrum no es para la compañía.

Mis agradecimientos a José Moro, realmente disfrutamos con mucho humor de la conversación y las especulaciones... son años de experiencias y vivencias que nos muestran que el post no va tan desencaminado :-P

martes, 12 de junio de 2018

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

Miguel Angel, 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.
Enterprise Agile Coach Coach ágil Scrum Master Scrum Master Scrum Master
Póster de buenas prácticas de las historia de usuario

Descargas / Downloads
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.

lunes, 11 de junio de 2018

¿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:
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 ùede 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!

sábado, 9 de junio de 2018

¿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, con el objetivo de revisar la entrega de valor 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.

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.

viernes, 8 de junio de 2018

¿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. Planificación de sprint Reunión diaria Refinamiento Revisión de sprint Retrospectiva Town-Hall Scrum de Scrums PO-Sync POCLAC Chapter Meeting QBR
Ciclo eventos modelo Spotify
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:
Reunión diaria

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

Objetivos:
Refinamiento

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

Objetivos:
Revisión de sprint

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

Objetivos:

Periodicidad: cada sprint (última actividad del sprint)


Objetivos:
EVENTOS DE TRIBU

Periodicidad: bimestral o trimestral

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:
PO-Sync

Periodicidad: semanal

Objetivos:
POCLAC

Periodicidad: cada sprint (a mitad de sprint)

Objetivos:
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

jueves, 7 de junio de 2018

¿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.

martes, 5 de junio de 2018

¿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:
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.

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. :-)