¿Existe alguna herramienta de coaching para ayudar a crear una visión sólida de una transformación ágil?

Alexey Krivitsky presentando el Agile Coaching Canvas

En el Global Scrum Gathering Munich 2016 Alexey Krivitsky nos presentó el Agile Coaching Canvas y nos llevó por un viaje interior en que cada uno de los coaches ágiles que asistimos hicimos un viaje interior a como serían nuestra empresas cuando las hayamos llevado a la Agilidad.

Sueña el futuro,

así conseguirás llegar a tu objetivo.

Solo tu puedes hacer que tus sueños se hagan realidad,

es tu responsabilidad.

El canvas es una herramienta para ayudar a crear una visión sólida y pegadiza de una transformación ágil, aplica desde los equipos y agentes del cambio a los líderes de la compañía. El canvas está concebido para tres escenarios principales:

1. Como una herramienta individual o de auto-coaching: el lienzo puede ayudar a construir una visión de la ruta de entrenamiento para nuestros clientes, así como para los miembros de equipos de Scrum.

2. Como una herramienta de entrenamiento entre iguales: puede ser de gran ayuda durante los diálogos entre coaches ágiles / Scrum Masters para ayudarse mutuamente a obtener imágenes más claras de sus estrategias y tácticas de coaching.

3. Como una herramienta de entrenamiento del equipo: durante "futurospectivas" del equipo el lienzo puede ayudar a estos a crear de forma colaborativa una visión compartida de su futuro junto con algunas ideas sobre cómo llegar allí.

Agile Coaching Canvas y las instrucciones en el reverso que están descargables en la página del autor

La ruta del canvas empieza con el apartado del visionado (visioning) en el que nos imaginamos nuestro mayor sueño del futuro éxito. Abrimos la mente dejando de lado la situación actual, nos imaginamos como queremos que sea el futuro de la compañía, buscamos qué es lo que ha cambiado y a quienes les ha cambiado la vida.

En el siguiente paso nos situamos en dónde estamos para entender la situación actual (navigating), y así encontrar dónde poner el foco de nuestro esfuerzo y encontrar los retos por los que empezar.

Finalmente dibujaremos el camino de cómo hacer la transformación (detailing), qué aptitudes hay que desarrollar, de quienes necesitaremos ayuda y como y a quién aplicar nuestros esfuerzos de formación, coaching, facilitación y mentoring.

Es una gran herramienta, yo vi una empresa llena de luz, de tableros vivos que mostraban que se está haciendo un gran trabajo, equipos hablando seguros y motivados, gente contenta... y vi por donde empezar :-)

---

Descargas / Downloads

Co-create, capture and share with the help of the Agile Coaching Canvas, the instructions.

La versión 1.2.5 traducida que corresponde a este post.

¿Como modelar el producto desde la perspectiva del cliente?

Mapa de empatía, lo que piensa, oye, dice y siente

El objetivo último de cualquier proyecto o construcción de un producto es que nuestro cliente sea más competitivo, se
sitúe fuertemente en el mercado y por ende tenga más beneficios. Agilidad está centrada en el cliente, por tanto debemos de comprender a nuestros usuarios y sus necesidades para poder darles un mejor producto.

Quiero presentar en este post una técnica que hemos trabajado en el Global Scrum Gathering Munich 2016, el mapa de empatia, una técnica desarrollada por XPLANE y que se utiliza en Design Thinking, un conjunto de métodos que tratan de desarrollar la innovación tomando como único punto de partida a las personas que son beneficiarias del producto.

El mapa de empatía nos permite ir más allá de lo que parece que quiere el usuario o cliente, o de lo que dice que quiere. A través de la empatia hacia la persona llegamos a entender lo que realmente quiere, a comprenderla dentro del sistema de su compañía, sus rutinas, motivaciones, aspiraciones, preocupaciones, necesidades y frustraciones. Solo comprendiendo a las personas nuestra propuesta de solución puede ser guiada por valor.

El mapa permite responder de forma más acertada a preguntas como: ¿qué servicios necesita nuestro cliente?, ¿nuestra propuesta de valor soluciona algún problema real del cliente?, ¿qué aspiraciones tiene el cliente y cómo podemos ayudarle a alcanzarlas?, ¿el cliente está realmente dispuesto a pagar por esto? y ¿cómo prefiere que sea la relación y se establezca la comunicación?

¿Cómo funciona la dinámica?

Antes de nada debemos identificar quienes son los clientes objetivo en base a una serie de atributos comunes (desde demográficos hasta por cómo usan el producto) para obtener así los grupos o segmentos sobre los que focalizarnos. Los mapas de empatía tratan de personas, no de segmentos, por tanto el siguiente paso será materializar esos grupos dando vida a unas pocas personas de cada uno de ellos mediante la técnica de la User-Persona.

A partir de aquí ya podemos construir el mapa de empatía colocando de forma colaborativa respuestas escritas en post-its en las diferentes partes que componen el mapa:

¿Qué piensa (think)?

• ¿Qué es lo que le mueve?
• ¿Cuales son sus preocupaciones?
• ¿Qué es lo que le importa realmente (y qué no dice)?
• ¿Cuales son sus expectativas?

¿Qué escucha (hear)?

• ¿Qué es lo que escucha en su entorno profesional?
• ¿Qué le dicen sus amigos y familia?
• ¿Quienes son sus principales influenciadores?
• ¿A qué medios y canales atiende?
• ¿A qué tipo de ofertas está expuesto?
• ¿A qué tipo de problemas se enfrenta?

¿Qué dice (say)?

• ¿Cual es su actitud?
• ¿Cómo se comporta habitualmente en público?
• ¿Qué dice que le importa?
• ¿Con quien habla?
• ¿Influencia a alguien?
• ¿Existen diferencias entre lo que dice y lo que piensa?

¿Qué siente (feel)?

• ¿Qué lo conmueve?
• ¿Qué le quita el sueño?
• ¿Cuales son sus sueños?

Una vez obtenido el mapa hay que validarlo, salir a la calle y analizar las hipótesis sobre las que ha sido construido y comprobar si motivan al cliente o no. El mapa no es estático, hay que revalidarlo y refinarlo, e incluir cada descubrimiento que hagamos.

Preparación de un mapa mental en el taller de Design Thinking en el Global Scrum Gathering de Munich 2016

En el taller imaginamos a un supuesto futuro directivo ágil encargado de ejecutar la transformación ágil de una compañía clásica, en la que empezaría por aplicar Scrum a un primer proyecto. Estos fueron algunos de los resultados:

¿Qué piensa (think)?

• Razones por las que no cambiar
• ¿Para qué sirve en realidad?
• No sé si esto va a funcionar
• ¿Qué conseguiré ganar con ello?
• La gente necesitará guía, yo habré de decirles en qué consiste

¿Qué escucha (hear)?

• El mundo está cambiando
• Hay que hacerlo
• La Agilidad ayudará a nuestra compañía a crecer
• A los empleados les encanta
• Reducirá el time-to-market

¿Qué dice (say)?

• Una cosa grande para los empleados
• Buen enfoque, pero pienso que no es aplicable a mi
• Necesito más información

¿Qué siente (feel)?

• Miedo
• Inseguridad
• Incertidumbre
• Reluctancia

¿Cuál podría ser la mascota de Scrum?

La tortuga, una opción como mascota de Scrum
cortesía de Pixabay

Uno de los malentendidos más comunes sobre la Agilidad es cuando se confunde Agilidad con velocidad. Como coach ágil suelo encontrarme frecuentemente con directivos que así lo creen. Mike Beedle, uno de los firmantes del Manifiesto Ágil que propuso el nombre de Agilidad, me confesó que hubiera sido mejor utilizar el término flexibilidad.

Manoel Pimentel menciona que la mascota para Scrum podría ser una tortuga, y lo hace pensando en la fábula de la tortuga y la liebre. Me gustó mucho la idea y quiero compartir los paralelismos que hacen que la tortuga sea una buena candidata a mascota de Scrum. Recordemos la fábula:

"Una liebre y una tortuga se retan a una carrera para ver quién de las dos es más rápida. La liebre parte en cabeza y en poco tiempo coge una gran ventaja sobre la lenta tortuga. Al verse con la victoria en el bolsillo la liebre se entretiene aquí y allá, hasta permite sentarse a descansar a la sombra de un árbol y cae dormida. Cuando despierta la tortuga está a punto de cruzar la meta y pese al esfuerzo de la liebre que trata en vano de retomar la cabeza, la tortuga acaba ganando la carrera".

La moraleja de la historia es que despacio se llega lejos, y aquí está en el origen de refranes presentes en casi todos los idiomas:

• Anda despacio si quieres llegar lejos
• No temas ir despacio, solo teme no avanzar

Con Scrum los proyectos no se ejecutan mas rápido, lo que ocurre es que ponemos el foco en lo que importa, en lo que da valor de negocio, y para construir imprime un ritmo sostenido que optimiza el flujo de entrega de historias de usuario, todas ellas construidas con calidad siguiendo la definición de hecho (DoD). Si pensamos en la tortuga de la fábula vemos claros paralelismos, tiene el foco puesto en llegar a la meta y un ritmo constante que le permite llegar la primera.

Pensemos en la liebre, ¿no podríamos hacer un paralelismo con la contratación de proyectos tradicional, en los que al igual que la liebre que solo avanza entre sus paradas, los avances se producen irregularmente entre los momentos en los que los equipos ya están rodados y el fin de los proyectos donde se desmonta todo? Quizá, pero la liebre no sería una buena mascota para la gestión predictiva, pero la tortuga si lo es para la gestión ágil. ;-)

---

¿En qué situaciones es aplicable un Propietario del Producto proxy?

Propieario del Producto proxy trabajando con el equipo de negocio

En el curso troncal reciente de Scrum Manger uno de los asistentes escribió al hilo del cuarto principio del Manifiesto Ágil que establece que:

Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto

y relacionado con el rol de Propietario del Producto, le parecía interesante incidir en la naturaleza del mismo en los casos en que hablamos con un cliente que no ha interiorizado los valores del Manifiesto Ágil. Es decir le interesaba la naturaleza (o cuál debe ser) del rol de Propietario del Producto como interfaz entre un equipo de desarrollo ágil que trabaja para entregar incrementos de un producto a una organización que sigue anclada a un enfoque tradicional para la gestión de requisitos y seguimiento del proyecto.

El éxito de un proyecto depende en gran medida del desempeño correcto del rol de Propietario del Producto, ya que solo él, como responsable del producto, tiene conocimiento para tomar las decisiones correctas sobre el producto y guiar al equipo de desarrollo a través de una prioridad alineada con el valor de negocio.

El Propietario del Producto más eficiente es aquel que asuma el rol desde el equipo de negocio, desde el cliente mismo. Un proyecto no es un proyecto del equipo de informática o del proveedor, un proyecto es la construcción de algo nuevo o algo que hará mejorar o evolucionar el software que gestiona el corebusiness del cliente, por tanto un proyecto tiene una repercusión directa en la competitividad del cliente y bien liderado hará de que este venda más o se sitúe con ventaja en el mercado. La combinación que resulta en el mejor producto posible es aquel que el proyecto es liderado por el cliente y construido por un equipo de especialistas técnicos.

Hasta aquí el escenario ideal, hay otros escenarios en los que no hay posibilidad de un Propietario del Producto proveniente del cliente. Por ejemplo si no hubiera nadie del equipo de negocio del cliente formado o dispuesto a asumir ese rol, o en el caso de equipos deslocalizados en los que el Propietario del Producto colocalizado con el equipo de desarrollo no es del cliente.

En estos casos el rol de Propietario del Producto que guía al equipo de desarrollo a través del valor de negocio ha de ser alguien proveniente de TI y que desempeñe un rol de proxy entre el equipo de negocio y el equipo de desarrollo. En este caso el rol lo pueden desempeñar todo tipo de expertos como:

• Analistas de negocio - Business Analysts (BAs)
• Expertos en la materia - Subject Matter Experts (SMEs)
• Gestores y jefes de proyecto - Project Managers
• Expertos en el dominio - Domain Experts
• ...

Mi consejo es que el proxy participe en todo lo posible de las actividades del equipo de negocio, incluso que desempeñe temporalmente sus tareas para comprender con profundidad las necesidades y prioridades de negocio.

Lo que merma el desempeño del Propietario del Producto proxy es el hecho de que el poder de decisión y el compromiso no se pueden delegar, con lo que en el peor de los casos el proxy puede verse reducido a un corre-ve-y-dile entre equipo y negocio.

¿Qué es y cómo funciona el control sutil?

Para el inexperto el término control sutil podría significar un control imperceptible a la vista y con connotaciones de manipulación. Nada más lejos de la realidad en el contexto de la Agilidad. En este contexto gerencia evita el tipo de control rígido que impide la creatividad y la espontaneidad y pone el énfasis en el "autocontrol", en el "el control por peer pressure" y en el "control por amor", lo que de forma colectiva se conoce como control sutil.

Para explicar como funciona el control sutil voy a empezar con una pregunta ¿Alguna vez te has sentido absolutamente comprometido con algo que has decido hacer? Puede ser un hobby, una actividad profesional, es algo que te ha hecho entrar en flujo, una cosa con la que has disfrutado y con la que casi no podías parar hasta acabar.

Cuando nos comprometemos de forma verdadera y auténtica hacemos todo lo que esté en nuestras manos para un resultado excelente, si las cosas se tuercen duele dentro de nosotros, y entonces somos nosotros mismos los que tomamos decisiones y buscamos soluciones. Eso es control sutil, el que viene desde dentro de nosotros, desde dentro de las personas y de los equipos. Parte de ello es el control por amor en el que hacemos las cosas por amor a nosotros mismos, dejando atrás todo aquello que nos hace infeliz y focalizandonos en poner la energía en lo que nos hace feliz.

Los equipos autoorganizados no están libres del control de la gerencia ni tampoco de la influencia del sistema. Las primeras referencias a Scrum fueron claras acerca de ello en "The New The New New Product Development Game" de 1986 donde Takeuchi y Nonaka escriben que el control sutil es coherente con el carácter de autoorganización de los equipos de desarrollo. La responsabilidad de un equipo ágil trata de autoorganizarse en torno a los retos y dentro de los límites y limitaciones impuestos por gerencia. La responsabilidad de gerencia es poner los retos apropiados y eliminar los obstáculos a la autoorganización de los equipos ágiles.

Scrum implica responsabilidad y compromiso, y eso se consigue en los equipos ágiles, los que construyen y están en las trincheras, cuando se les da la responsabilidad de determinar las historias de usuario que entran en la pila de sprint.

Si por ejemplo hay 10 historias de usuario por construir, se le dice al equipo que elija las que honestamente cree que puede construir en un entorno correcto en las próximas dos semanas, y elijen 5 por ejemplo ¿no darán todo por hacerlo bien? Cuando somos nosotros mismos quienes decidimos cuanto y como vamos construir nos duele mucho cuando las cosas se tuercen, y trataremos de hacer todo lo posible por cumplir con nosotros mismos: eso es fruto del control sutil.

En los equipos ágiles, en los que el objetivo es común y los fracasos y éxitos son compartidos, se suma la peer pressure, la presión que sentimos cuando uno de los miembros no se siente a la altura del equipo, del que siente que forma parte y que son sus compañeros de viaje a muerte.

Equipo: uno para todos, todos para uno - cortesía de Pixabay

Uno de los problemas que tenemos en nuestra cultura empresarial, en la que gestionamos proyectos en que creamos equipos para cada proyecto, es que al inicio realmente no tenemos un equipo, tenemos un grupo de personas susceptibles de ser equipo. Con el entorno y acompañamiento correctos la naturaleza humana llevará a formar equipo, las personas nos gusta, hasta diría que necesitamos, formar equipo.

En un equipo ágil de verdad cada miembro se siente acompañado, siente que aporta, tiene absoluta confianza en los demás, siente que va en el mismo barco que los demás, sabe que le apoyaran en sus equivocaciones, igual que él apoyará a los de los demás... es lo que también se llaman equipos de excelencia o tiger teams... y el control que les aplica es el control sutil.

¿Cómo desarrollar equipos impulsados por las motivaciones intrínsecas?

Eric Bowman hablando de los equipos en Zalando

Estos días estoy aprendiendo, creciendo y disfrutando como nunca en el Global Scrum Gathering Munich 2016. La presentación de apertura "Scaling Agile at Zalando throught Radical Agility" la dió Eric Bowman, y en esta presentación Eric habló de como estructuran los equipos por motivaciones y los impulsan con 3 poderosos factores de la motivación intrínseca:

• El propósito o meta
• La autonomía o libertad
• La maestría

Rodear a los equipos de personas cuya motivación primaria sea el propósito y dotarlas de un profundo entendimiento del producto, tanto Propietarios del Producto como miembros de equipo. El propósito es el anhelo de que nuestro trabajo sea una contribución a algo mucho más grande. Le da sentido y significado a lo que hacemos y nos recuerda que colaboramos con nuestro equipo para el éxito de un producto, un producto que será una herramienta de trabajo diaria para nuestros clientes y usuarios.

En la primera línea de las entregas poner a personas cuya motivación primaria sea la autonomía. Personas que se mueven con el impulso de dirigir su propia acción, un estado de independencia que les hace sentir totalmente responsables de sus propios resultados. Estas personas resolverán como "tigres" los posibles problemas de implementación y entrega.

Personas cuya motivación primaria sea la maestría y que velen por un desarrollo con calidad y excelencia. Esta es la determinación de lograr una mejora continua en nuestro desempeño y así disfrutar de nuestros resultados porque estos se llevan toda nuestra experiencia y conocimiento, acompañado con un sentimiento de orgullo y propiedad (responsabilidad).

¿Qué tal CCM (Change and Configuration Management) de IBM para la gestión de proyectos Scrum?

Recientemente he tenido la oportunidad de acompañar un equipo de Scrum que utiliza CCM (Change and Configuration Management) 4.0.6 junto con el Rational Jazz Team Server de IBM, en este post quiero exponer la experiencia con esta herramienta.

Tengo grandes esperanzas en esta herramienta, IBM ha anunciado que la versión 6.0.1 de CLM (Collaborative Lifecycle Management) soportará SAFe 3.0 de principio a fin.

Lo que no me gusta:

• El nombre... si el nombre, porque habla de gestión del cambio y eso no es nada ágil, en Scrum "abrazamos el cambio", recordemos el segundo principio del Manifiesto Ágil: "Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente".
• La usabilidad, es una herramienta poco user-friendly y poco intuitiva, requiere unos pocos intentos para aprender a utilizarla correctamente y ser capaz de encontrar las cosas.
• Las historias de usuario de la pila de producto, al igual que las tareas, tienen demasiada información, hay mucho desperdicio desde el punto de vista de la Agilidad, se hace patente que forma parte de una gestión tradicional completa y pesada.
• El tablero de Scrum, aunque está muy bien resuelto, se corta con más de 3-5 historias y por tanto requiere de scroll. Esto reduce la visión agregada del mismo y reduce la visión del todo y del avance del sprint.

Lo que me gusta:

• El sistema de pilas es completo y funcional:
• El backlog representa la parte viva de la pila de producto por construir.
• La release representa la parte comprometida de la siguiente subida a producción según la hoja de ruta. Ojo, recordar no caer en la tentación de planificar más de una release a futuro, eso comprometería una mayor parte de la pila. Para una planificación a más alto nivel existe la hoja de ruta.
• La pila de sprint contiene las historias de usuario del sprint y sus tareas asociadas y permite tener una vista de a quién están asignadas. Lo importante es que esta pila es el resultado de la planificación de sprint, una vez creada el equipo utilizará la vista de tablero de Scrum en las dailys.

Las pilas de release, producto y sprint

• El tablero de Scrum está bien resuelto, con una columna para las historias de usuario, un srum board clásico para las tareas y una quinta columna "verificado" para las historias que en la revisión de sprint han cumplido con los criterios de aceptación. Los estados se asignan automáticamente al mover historias y tareas de una columna a otra.
• Igual que Redmine, y a diferencia de iceScrum, el tablero permite que cualquiera con los privilegios suficientes pueda mover los post-its, haciendo posible así su uso para las dailys.
• Permite asignar colores a los post-its según la naturaleza del mismo y el estado en que se encuentren.

Tablero Scrum

• Desde la vista del sprint y desplegando los detalles del plan, hay que practicar un poco para encontrar y recordar el link, se accede a un burndown perfectamente funcional, un gráfico dirigido al equipo para que tenga información del avance y pueda tomar decisiones adecuadas.

Gráfico burndown

¿Cómo alinear a varios equipos para que la unidad punto de historia signifique lo mismo?

Cómo recordaréis la estimación ágil se basa en una unidad relativa, una unidad arbitraria propia del equipo u organización. Representa cantidad de trabajo o esfuerzo, considerando dos variables: la complejidad o dificultad y el tamaño.

En proyectos/productos en los que varios equipos trabajan en una misma pila de producto es necesario utilizar la misma escala y unidad, se vuelve esencial algún tipo de normalización, ya que de lo contrario los tamaños de las historias de usuario serán inconsistentes. Además por lo general surge la necesidad razonable para saber el tamaño de todo el proyecto/producto, y eso solo es posible con una unidad normalizada.

Los puristas en Scrum cuestionan esta normalización, pudiera llevar a comparar las velocidades de los equipos, cosa muy contraproducente porque cada equipo/cliente/proyecto/producto/entorno son únicos. Por otro lado es una práctica aceptada en el marco SAFe, por lo que es una necesidad que es probable nos podamos encontrar a menudo.

Para definir una linea base es necesario que las estimaciones de las historias de usuario de referencia sean y signifiquen lo mismo para todos los equipos, por tanto se deben utilizar historias de referencia que todos los equipos sean capaces de estimar e implementar.

La mejor manera para hacer la normalización es hacer un taller de calibración con los equipos a alinear. La idea es hacer que los equipos estimen de forma conjunta aproximadamente una docena de historias de usuario de una pila de producto preparada para el taller. No todos tienen que entender cada elemento, pero la mayoría debe de entender la mayoría de las historias. Las historias a estimar no tienen que ser nuevas, algunas podrían ser de un proyecto terminado recientemente, han de ser historias conocidas por muchos. Algunas pueden estar creadas solo para el taller, algo así como estimar una "pantalla de login" o un "informe típico de ventas del día". Lo importante es que esas historias signifiquen algo para la mayoría de los equipos y permitan su alineamiento.

La experiencia muestra que un taller de este tipo requiere una duración de entre 1 y 2 horas para tres equipos de unos 7 miembros y estimando 12 historias de usuario. Acabado el taller los equipos estarán alineados, pero es necesario repetirlo periódicamente ya que los equipos tendrán la tendencia natural a divergir, a menos que se vayan recalibrando mediante estos talleres.

Sala preparada para la normalización del punto de historia para tres equipos