sábado, 28 de octubre de 2017

¿Cómo mostrar la importancia de la integración continua?

Este es un ejercicio del curso CSD de
Jugadores ordenando las fichas
Una de las prácticas que son absolutamente necesarias para ir a favor del flujo de entrega de valor en un equipo Scrum es la integración continua, asegurarnos de forma continua o muy frecuente que las partes construidas por los diferentes miembros del equipo, o de varios equipos que trabajan alrededor de un mismo producto, integra y se engarza para funcionar correctamente de forma conjunta.

Martin Fowler describe la integración continua como: "Integración continua es una práctica de desarrollo software donde los miembros del equipo integran su trabajo frecuentemente; normalmente cada miembro integra al menos una vez al día. Cada integración es verificada por un build automatizado (incluyendo test) para detectar los errores de integración tan rápido como sea posible. Muchos equipos encuentran que este enfoque permite reducir los problemas de integración y permite al equipo desarrollar software cohesivo más rápidamente".

Pero, ¿cómo hacer comprender a personas no técnicas, como lo pueden ser Propietarios del Producto, coaches, líderes, directivos, etc. la importancia de esta práctica técnica?

Para ello podemos utilizar un juego de fichas recortables que permite a los asistentes entender la importancia de integración frecuente. La dinámica trata de que los jugadores encuentren dos caminos, el de integración continua y el de no continua, ordenando las siguientes fichas:
Juego de fichas con imágenes a ordenar
Se les dan un par de pistas:
  • La ficha de inicio es común para ambos y es la 04
  • Con integración continua acabamos las casas en verano, y sin, más tarde en invierno
La solución al juego es la siguiente:
Solución al juego
Con puntos de integración, el camino en verde, los constructores construyen por separado las estructuras de las casas (04), luego comparan y se dan cuenta que no tienen la misma altura (07), retrabajan las estructuras (02), vuelven a comprobar y ahora si integran (10), después trabajan en las paredes (11) con un punto de integración para asegurarse de que son iguales (09), finalmente hacen los acabados (01) y cuando integran en verano el resultado es excelente (12).

Sin puntos de integración, el camino rojo, los constructores empiezan por separado por las estructuras (04) y siguen directamente con las paredes y los acabados (08), cuando integran las cosas no cuadran (05) y tienen que hacer muchos ajustes y retrabajo (06) que requieren mucho tiempo, representado por el calendario que corre, finalmente obtienen un buen resultado en invierno (03), mucho más tarde y con más costes de retrabajo que si lo hubieran hecho con puntos de integración.

Descargas / Downloads
Quiero dar mis agradecimientos al autor de las imágenes y del juego, lo utilizo frecuentemente para explicar la integración continua y no soy capaz de encontrarlo en la web.

sábado, 21 de octubre de 2017

¿Cómo trabaja un coach ágil desde la inteligencia emocional, social y de relaciones?

El coach ágil trabaja el sistema completo, las relaciones del
mismo, entre todos los miembros del equipo - cortesía de Pixabay
Una de las habilidades que todos tenemos es saber leer la energía o el campo emocional de un grupo u equipo de personas. Todos la tenemos, algunos más desarrollada que otros, sabemos ver, oler, intuir algo antes de que ocurra. Cuando entramos en una reunión por ejemplo, sabemos en el mismo momento al entrar por la puerta qué ocurre desde el punto de vista emocional del grupo de personas.

Un coach ágil está entrenado para leer el campo emocional, es experto en los valores, principios y prácticas ágiles, y su función es transformar de forma consciente e intencional las relaciones entre las personas del equipo/grupo para alinearlas con Agilidad y así beneficiar el trabajo de estas.

En función del campo emocional puede detectar si el grupo o equipo entiende su situación como un problema. En ese caso el coach ágil empieza normalizando, haciendo ver a todos que la situación en concreto es algo normal, es algo que ocurre cuando trabajamos con otras personas y que puede pasar en cualquier grupo o equipo.

Para iniciar cualquier transformación el coach ágil lo hace revelando el equipo a si mismo, su realidad, quienes son y quienes están, qué tipo de interrelaciones y roles formales e informales existen en el grupo, sobre su salud o toxicidad, qué aspectos mejoran sus resultados como equipo y cuales los empeoran... A partir de este momento el equipo o grupo es capaz de observar su realidad desde otra perspectiva, distinguir "hechos" de "interpretaciones" y reconocer la relación entre los "estados de ánimo" y "la creación de futuro", aprender a aprender y a desaprender.

Es el momento de establecer el contexto, la primera etapa de la conversación, creando un ambiente idóneo para que fluya la comunicación de manera clara, con empatía, escucha activa y el estar presentes. También es el momento de formar y trabajar la mentalidad ágil, recordemos los valores se Scrum (transparencia, franqueza, foco, respeto y coraje), y dos de los cuatro valores del Manifiesto Ágil que hablan de relaciones entre personas:
Es fácil leer el campo emocional de este equipo
El coach ágil crea un campo emocional consciente que cambia la energía del equipo, así podrán lograr los resultados deseados y descubrir nuevos aprendizajes. Es el momento de difuminarse, de que el coach ágil se aparte y deje que el protagonista de su rumbo y futuro sea quien debe de serlo: el equipo.

ORSC™ en su modelo de coaching de organizaciones y sistemas relacionales introduce el concepto de MetaHabilidades. Para que el coaching funcione mejor es necesario que el espacio y la atmósfera del coaching sean los correctos. Una MetaHabilidad es la actitud y postura con la que opera el coach ágil, como por ejemplo el compromiso, el respeto, la democracia profunda, el corazón, la juguetonería o la colaboración.

lunes, 16 de octubre de 2017

¿Cómo liderar el crecimiento de equipos impulsados por las motivaciones intrínsecas?

Porqué tenemos POCLACs
Aquellos con roles de liderazgo ágil deben de hacer todo lo posible para que los equipos aprendan y crezcan de forma continua en un ambiente adecuado con el objetivo de hacer equipos más productivos y motivados. En Agilidad el liderazgo se hace en equipo y por aquellos roles que pueden facilitar las motivaciones intrínsecas de los miembros del equipo: propósito, maestría y autonomía.

En los diferentes marcos de Agilidad, desde Scrum a los marcos escalados, nos encontramos con un liderazgo distribuido en una coalición de tres roles:
El modelo Spotify define un evento denominado POCLAC para que estos roles de liderazgo trabajen en cómo ayudar a los equipos a desarrollarse, es más fácil empoderar un equipo que a personas individuales. POCLAC viene de las siglas de la coalición de Propietario del Producto (PO), Chapter Lead (CL) y Agile Coach (AC), y es el evento que da respuesta al post, a cómo liderar el crecimiento de equipos impulsados por las motivaciones intrínsecas.

El evento se materializa en una reunión informal y regular dentro de la cadencia establecida, al menos debe de efectuarse una vez por sprint. Dentro de la misma se discute acerca de cómo está funcionando el equipo y sobre qué podría hacerse para que trabajen mejor. Podemos apoyarnos en diferentes fuentes de información:
El resultado de la reunión se materializa en una serie de acciones a poner en macha para hacer crecer a los equipos; reconocimientos, adquisición de recursos, resolución de impedimentos, eventos de team-building, formaciones, …

No debemos tratar a los miembros de forma individual, sólo sería adecuado discutir una contribución individual si esta estuviera directamente vinculada al rendimiento del equipo. El resultado de tal discusión puede variar desde dar un gran cumplido a alguien que haya influido positivamente en el rendimiento del equipo, o tener una charla con alguien que está teniendo problemas y hacer un plan para ayudar a ese miembro de equipo a crecer.

Una de las disfunciones más comunes de POCLAC es que se covierta en una reunión de discusión sobre la pila de producto o los hitos de la hoja de ruta, por tanto como facilitadores de la reunión hemos de estar alerta y si ocurre refocalizar la reunión en el equipo. También debemos cuidar que cada rol se mantenga dentro de sus responsabilidades y no asistan otros interesados.

Mis agradecimientos a Scrum Manager por difundir este post también en su blog, y por su "aparición" en el blog de PMIdeas, hecho que me halaga ya que muestra la repercusión de mis posts. :-)

viernes, 13 de octubre de 2017

¿Cómo planificar utilizando hitos en Scrum?

Los hitos son una serie de etapas dentro de un mismo proyecto, provienen de la gestión de proyectos en cascada, son una forma de conocer el avance del proyecto sin estar familiarizado con el mismo y simbolizan el haber conseguido un logro importante en el proyecto.

La gestión clásica se basa en montar líneas de tiempo con hitos (planificaciones) atadas a un alcance inicial y dotar la línea de tiempo de los recursos para cumplir con esa línea, sin tener en cuenta capacidades ni dependencias. Trae la gente al trabajo. La dotación de recursos, tanto de personas, infraestructuras, herramientas... a una planificación no deja de ser intencional, algo que puede ser muy lejano a la realidad posterior. Marcar hitos en este tipo de gestión suele dar resultados frustrantes, los desvíos y mala calidad del software de proyectos tradicionales suele venir de hitos marcados sin tener en cuenta realidades.

Agilidad mide la capacidad de flujo de los sistemas incluidos los equipos existentes, para poder así ajustar el trabajo a la capacidad y poner el foco en mejorar el flujo de forma continua, alineando, sincronizando y teniendo en cuenta las dependencias. Trae el trabajo a la gente y en la cantidad de la capacidad de ésta.

Se determinan en la fase de incepción y marcan la hoja de ruta. Estos se van revisando a medida que avanza la construcción del producto y se van ajustando a los cambios de necesidades del producto o cliente. Correctamente gestionados dan flexibilidad a la construcción del producto, como por ejemplo en el desarrollo software.

Mike Beedle, con quién he compartido cursos como co-trainer, dejó en mi impresa una de sus frases que suelo utilizar en todas mis clases cuando hablo de métricas:

Quién predice sin medir, se equivocará

Para poder marcar hitos factibes necesitamos métricas basadas en la evaluación objetivas de sistemas funcionando. SAFe lo resalta de forma muy clara, incluye en sus principios, en el quinto concretamente, "Basar los hitos en la evaluación objetiva de sistemas funcionando".

En Scrum la velocidad es la métrica objetiva por excelencia, nos da la capacidad media por sprint de un equipo en la misma medida que los tamaños de la pila de producto, por tanto habiendo medido la velocidad en un equipo estabilizado, podemos proyectar la pila de producto a fechas futuras en forma de hitos con gran grado de acierto y poblar la hoja de ruta. De la misma manera que tratamos velocidades de equipos, en Agilidad a escala hemos de tratar velocidades de equipos de equipos.

Ejemplos de métricas objetivas:

jueves, 12 de octubre de 2017

¿Cómo lidiar con la incertidumbre inherente a los proyectos/productos?

Los principios de un proyecto son una situación de gran incertidumbre, conocemos los problemas de negocio más urgentes de forma general pero no al detalle, no tenemos aún sentido de su evolución en el tiempo, aún estamos sin experiencia en el mercado y por tanto desconocemos las necesidades reales, realmente es un momento en el que se puede saber muy poco.

En gestión clásica se suele tener la convicción de que existe una solución única e ideal y que esta se puede conocer al principio, y la tenemos en ese momento de máxima ignorancia. En gestión ágil si observamos el comportamiento de Scrum a lo largo del cono de la incertidumbre vemos que con cada sprint hay un punto de aprendizaje que nos permite reconducir la construcción hacia la mejor solución posible.

Recordemos el método INVEST para medir la calidad de una historia de usuario, en concreto la N de negociable: los detalles de una historia deben de ser acordados con el cliente o usuario durante la fase de conversación, poco antes de su inclusión en un sprint, en el último momento responsable, cuando la información es más fresca. De la misma manera debemos de decidirnos por diseños o componentes en el último momento posible, ya que de esta manera tendremos la opción más adecuada.

La Agilidad se basa en realidades, la variabilidad es inherente a todo producto y si eliminamos la variabilidad demasiado temprano limitamos ganar experiencia de lo que funciona y lo que no.
A través de puntos de aprendizaje terminamos en la solución óptima
SAFe incluye entre sus principios el tercero, el que nos habla de "asumir variabilidad y preservar opciones", este nos hace considerar un abanico de opciones en las soluciones de diseño y no pretender determinar las opciones al principio, los puntos de aprendizaje a lo largo del proyecto nos enseñarán cuál es la opción ideal:
Por ejemplo; como Propietario del Producto debemos de buscar la mejor solución funcional posible a una necesidad de negocio, y a veces hay varias soluciones posibles de las que de antemano no sabemos cual es la mejor de ellas. En ese caso podemos añadir tantas historias de usuario a la pila de producto como soluciones posibles veamos. A medida que avancemos en el proyecto iremos ganando información y aprendizaje, y así descartando las historias menos adecuadas. En el momento de la inclusión de la historia de usuario en un sprint, lo haremos con la que es la mejor solución posible.

miércoles, 11 de octubre de 2017

¿Cómo combinar un software de gestión de tareas con tableros físicos?

Elena Moreno dándo el seminario ¿Cómo Confluence y Jira
nos pueden ayudar en nuestros proyectos ágiles?
Hace poco asistí a un seminario que dio Elena, una compañera coach ágil, sobre cómo Confluence y Jira pueden ayudarnos en los proyectos ágiles. Al final de la sesión le dije que me había hecho feliz, ya que me dio la solución a la dicotomía de conciliar los tableros físicos y los virtuales.

Cuando las compañías se plantean introducir una herramienta con la que registrar y hacer seguimiento de sus historias de usuario y tareas suelen decantarse por una herramienta tipo JIRA o Redmine en su versión Agile. Son herramientas que suelen estar ya instaladas y que se utilizan para la gestión de proyectos con las metodologías establecidas, usualmente en cascada. Lo que suele gestionarse en estas herramientas son tareas, de las que se registran las horas estimadas y se hace seguimiento a través de las horas realizadas.

Uno de los inconvenientes es que se mezclan peras con manzanas, ya que las horas estimadas, que se miden en horas ideales, son una medida de esfuerzo (trabajo), y las horas realizadas, se miden en tiempo transcurrido y representan duración. Realmente la métrica que reflejamos en la herramienta es el tiempo invertido, y esta métrica no representa la productividad del equipo.

En Agilidad ponemos el foco en la entrega, considerando esta como un conjunto de elementos que tienen valor de negocio, como lo son las historias de usuario, finalizadas según la definición de hecho e instaladas en un entorno al que los usuarios finales tengan acceso. La suma de las estimaciones, en horas ideales o puntos de historia, de aquellas que el equipo entrega a final del sprint, representa la velocidad del equipo, y esta si es una métrica de la productividad.

Como podemos ver, los elementos de los que es interesante hacer seguimiento son las historias de usuario, aquellos elementos que agregan valor una vez entregados y que al fin y al cabo recorren la cadena de valor del producto y de los que es interesante tener trazabilidad.

Las tareas son elementos fungibles, nacen al principio del sprint en la planificación de sprint, y mueren al finalizar este. Por supuesto debemos de ser capaces de hacer seguimiento y poder ver el avance del sprint a partir de las mismas, pero su ciclo de vida es muy corto.

Informes de Jira Agile
Las herramientas como JIRA aportan multitud de informes y gráficos para el seguimiento, son una opción ideal para hacer seguimiento de los elementos que dan valor a negocio. Estos son elementos de larga duración, nacen en la pila de producto y su ciclo de vida acaba una vez están instalados en producción y se hayan tomado métricas como el ROI (Retorno de Inversión). Por tanto las herramientas como JIRA, con sus tableros virtuales, son una herramienta excelente para la gestión y seguimiento de epics, historias de usuario y releases.

A nivel de tareas, y recordemos que estas las definen los equipos y se las autoasignan los miembros en las sucesivas reuniones diarias, las necesidades que debe de cubrir un tablero son ser punto de referencia, conectar a las personas y ser herramienta de comunicación en el equipo. A diferencia de un tablero que refleja historias de usuario con ciclos de vida largos y para un número relativamente reducido de Propietarios del Producto, el tablero para tareas con un ciclo de vida corto, debe de ser útil para un grupo mayor, de entre 3 a 9 miembros de equipo.

La solución ideal para los equipos y sus tareas son los tableros físicos, muestran la imagen completa del sprint, son fáciles de gestionar (mover los post-its), siempre están visibles con lo que irradian con fuerza y se vuelven punto de referencia con facilidad. El hecho de que los equipos tengan que dibujar los burndowns es otra ventaja, porque al hacerlo los miembros interiorizan el avance del sprint conviertiéndo este gráfico en una poderosa herramienta para la toma de decisiones en equipo.

Tablero de Scrum físico
La conclusión, y de ahí mi alegría, es que la conjunción de tableros virtuales para elementos que agregan valor y que requieren seguimiento a largo, junto tableros físicos para elementos de trabajo de vida corta y que requieren de microplanificación con todos los miembros del equipo presentes, es una solución excelente.

Tuve un equipo que por razones ajenas a los mismos tuvo que dejar de trabajar con Scrum, llevaban ya tres meses con las ceremonias de Scrum reuniéndose diariamente ante el tablero físico, y cuando apenado tuve que notificarles que dejaría de ser su Scrum Master, me pidieron que por favor les dejara el tablero físico, que aunque tuvieran que volver a su metodología clásica el tablero les estaba siendo de gran utilidad facilitándoles mucho la coordinación.

Mis agradecimientos a Esther, Dani, Juan, Raúl, Daniel, Noelia y Santi y a su tablero que les ayudó a ser un equipo ganador.

sábado, 7 de octubre de 2017

¿Cuál es la diferencia entre un enfoque de consultoría y de coaching en una transformación ágil?

La cultura se merienda a la estrategia - Peter Drucker
Uno de los temas que son más complicados de comprender por parte de la empresas tradicionales que inician su transformación ágil, es la el enfoque de como debe de acometerse las misma.

Están acostumbradas a los consultores de negocio, como Price Waterhouse Cooper, McKinsey&Company y Accenture, esos expertos que revisan y analizan la organización para entregar finalmente un informe que cuesta su peso en oro con todo aquello que deben de hacer para una transformación ágil exitosa.

Estos informes hablan de estrategia, del proceso de como hacer la transformación, de procedimientos a implantar, de un gran plan que llevará e nuestra organización a ser un compañía Agile.

El punto débil de este enfoque es obviar que la Agilidad implica un cambio cultural, un profundo cambio en los valores de la compañía y de los principios por los que esta deberá regirse. La resistencia al cambio, los secretos existentes que no pueden gestionarse y la inercia al cambio cultural pueden hacer que la estrategia fracase. Como dice Peter Drucker, considerado el mayor filósofo de la administración del siglo XX, cuando estrategia y cultura colisionan: "La cultura organizacional se merienda toda estrategia".

Toda compañía es singular en todos sus aspectos y no podemos conocer, ni por tanto concebir, la estrategia adecuada en todas sus vertientes al principio, en el punto en el que se hace la consultoría es el de mayor ignorancia. Por ello es necesario otro enfoque, un enfoque de aproximación sucesiva a la Agilidad.

En ese punto entra en juego el enfoque del coaching, a través de un equipo de agentes de cambio con roles de coach ágil. Estos son expertos en Agilidad y su misión para una transformación ágil es estirar a la organización sin piedad ni sentimiento de culpabilidad hacia los valores, los principios y las prácticas ágiles. Los procesos y procedimientos están escritos, llámese Scrum, SAFe, LeSS o modelo Spotify, lo que hará un coach ágil es acompañarnos hacía éstos haciendo que los detalles específicos para nosotros emerjan de la organización de forma paulatina a través de la mejora continua.

Dos enfoques para una transformación ágil
Un coach impregnará a la compañía de mentalidad ágil, marcará en cada evento y ceremonia la dirección adecuada. Observará e intervendrá en cada crisis y en cada decisión no alineada con la Agilidad, formará a quién lo requiera y mentorizará a Propietarios del Producto, Scrum Masters, lideres y a todas las personas de la compañía que lo requieran.

Se ocupará de organizar retrospectivas periódicas a diferentes niveles de la organización, en cada una de ellas habrá como resultado un punto de mejora que de tener éxito hará a la compañía más ágil. En ocasiones invitará a las mismas a lideres y directivos para que escuchen de primera mano lo que su gente tiene que decir, éstos son al fin y al cabo los que pueden desbloquear impedimentos sistémicos y organizacionales e impulsar la Agilidad. A veces habrá retrocesos, los puntos de mejora hay que probarlos y a veces simplemente no funcionan. Como nos dice William Edwards Deming "es mejor mejorar un poco cada día que intentar mejorar todo de una sola vez".

Un coach ágil no tiene un gran plan, sabe exactamente cual es la dirección de la Agilidad, dispará a la Luna y estirará de la organización en esa dirección, sabiendo que no llegará a la misma, pero si sabiendo que llegará a la mejor aproximación posible según las singularidades de la organización. Lo hará a través de la mejora continua, concibiendo pequeños planes en base a métricas ágiles, a modo de "think big, act small".

Un coach ágil no tiene la solución a la transformación ágil, pero si actuará de aceite para mover a la gente para que se se produzca la mejor transformación posible.