domingo, 1 de diciembre de 2019

¿Cómo escribir historias técnicas de deuda técnica?

La deuda técnica ralentiza la productividad y genera
productos de escasa calidad - cortesía de Pixabay
Un producto no es un producto de calidad si no da solución a las necesidades del usuario o cliente, eso representa su valor, y tampoco es de calidad si la infraestructura tecnológica que lo soporta no es excelente, eso lo representa su integridad tecnológica.

Centrarse únicamente en construir funcionalidades de negocio, como las historias de usuario, puede funcionar a corto plazo, e incluso proporcionar una gratificación inmediata al mercado, pero a medio plazo la velocidad de entrega se ralentizará irremediablemente por una carga aplastante de la deuda técnica que se va adquiriendo.

Es por ello que para garantizar que se realicen las inversiones adecuadas dentro del presupuesto para el producto o proyecto, es necesario incluir historias técnicas de resolución de deuda técnica en la pila del producto.

A menudo el Propietario de Producto no comprende la necesidad y los beneficios de reducir la deuda técnica y no considera historias técnicas para ello en la pila del producto. Recordemos que el Propietario del Producto es parte del equipo ágil y este debe de asumir la responsabilidad de reducir la deuda técnica y analizar esta con los miembros del equipo de desarrollo y trabajar juntos para darle la prioridad adecuada en la pila del producto: su dolor es el dolor del equipo y viceversa.

Los desarrolladores conocen la deuda técnica y son conscientes de la importancia de resolver este problema desde el punto de vista técnico. Hay un técnica provocativa que ideó un equipo de desarrollo para ayudar al Propietario del Producto a tener en cuenta la deuda técnica; utiliza el siguiente el patrón para escribir historias técnicas de esta índole:

If we don't do this [action required]
It will cause this impact [loss of service]
And that will result in [reputational damage] and/or [monetary impact]

Si no hacemos [acción requerida]
Causará el impacto [pérdida de servicio]
Lo que resultará en [daño a la reputación] y/o [impacto monetario]

un ejemplo podría ser:
Si no hacemos por resolver la cobertura de pruebas
Causará el impacto de un incremento mensual del 10% en el número de incidencias
Lo que resultará en una reducción de productividad mensual acumulada de aproximadamente 5 horas

Los equipos viven la realidad tecnológica (herramientas, hardware, entornos, etc.) día a día, ellos saben qué les cuesta en esfuerzo o en tiempo cada vez que se encuentran con un elemento con deuda técnica. Es su responsabilidad analizarla, estimarla y hacerla visible de forma argumentada al Propietario del Producto y a otros interesados.

Hacer partícipe al cliente e interesados tiene dos beneficios; hacer que estos entiendan los problemas del software, y que participen en la solución apoyando la resolución de deuda técnica o proporcionando una perspectiva de negocio que puede cambiar las prioridades.

Gracias Sara por compartir este patrón :-)

miércoles, 27 de noviembre de 2019

¿Cómo tiñe la PI Planning la intención de realidad?

PI Planning en el Big Picture de SAFe®
Una de las frases de SAFe® y que se refiere a la PI Planning dice así:

No hay magia en SAFe...
excepto quizá en la PI Planning

Veamos pues cual es la magia de este evento core del marco.

Recordando los inputs y outputs de la PI Planning tenemos entre otros como input el program backlog, la pila de features que Product Management ha preparado, y como outputs los objetivos del equipo, las pilas iniciales de los equipos y el Program Board con las features colocadas en la iteración en la que el equipo estima terminarlas y las interdependencias detectadas resueltas.


La primera clave está en comprender que el program backlog representa la intención de Product Management y negocio, representa aquellas cosas que desde el punto de vista de negocio son las que aportan el máximo valor y están limitadas en tamaño a la capacidad del tren, por tanto representan las features deseables para construir y obtener al final de PI. 

Cuando en PI Planning los equipos toman esas features, las desglosan en historias de usuario, resuelven dependencias que emerjen entre si y con equipos externos, estos están "cocinando" la intención para obtener factibilidad. Esa es la magia de la PI Planning, utiliza la complejidad del pensamiento focalizado de todos los individuos del tren como inteligencia colectiva para obtener un plan factible tiñendo así la intención, representada en el program backlog, de realidad.


Finalizada la PI Planning las pilas iniciales de los equipos y sus objetivos del PI no van a cuadrar al 100% con la intención, con las features del backlog, quizá un 80%... Habrá cosas que no es posible construir, puede que por razones tecnológicas o por capacidad para absorber dependencias, para otras habrán surgido ideas y soluciones mejores... lo importante es entender que la PI Planning hace que los equipos crean un plan de partida en el que crea cada individuo, un plan que sea factible y por tanto garantice el éxito.

Program backlog y Program Board y su maraña de dependencias
En la imagen de la derecha podemos ver un program backlog, el flipboard a la izquierda, mostrando en azul las features que ha sido posible planificar; las verdes son aquellas que no se han podido incluir por alguna razón. En el tablero de la derecha se puede ver el Program Board con todas las dependencias identificadas y resueltas, están representadas por las cuerdas rojas. ¿Qué precio tiene un plan trimestral para 8 equipos que tiene todos los números de ser exitoso? ¿Que precio tiene el Program Board en el que se nos muestra las dependencias resueltas para ese trimestre? No habrá retrasos ni bloqueos, porque el plan lo han cocinado, cada uno desde su perspectiva, todos aquellos individuos que lo van a ejecutar.

Resaltar que el compromiso se establece con los objetivos que los propios equipos han establecido, y un objetivo es una cosa flexible. Un objetivo se puede alcanzar con un grupo de historias de usuario u con otro, con más o con menos, lo importante es que al final de PI el cliente reciba la mejor solución posible a su necesidad. El compromiso por objetivos nos hace ágiles, hace que las pilas de los equipos sean flexibles al igual que una pila de producto de un equipo de Scrum.

Con la PI Planning los equipos son dueños de sus planes y esa responsabilidad es uno de los beneficios más significativos del evento, cada individuo siente su responsabilidad en el resultado del tren, creándose así un ambiente de trabajo mejor en el que se impulsa la colaboración. Durante la PI Planning ocurre otro beneficio casi mágico, todos hacen hincapié en el equilibrio entre el trabajo y la vida, asegurándose de no planificar excediendo la capacidad y obtener un plan de partida excepcional.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

lunes, 25 de noviembre de 2019

¿Cuáles son las novedades de la versión 5.0 de SAFe®?

En octubre Scaled Agile anunció y puso a disposición del público su actualización a la versión 5.0. Se trata de una actualización significativa del marco que proporciona orientación sobre las siete competencias básicas que ayudan a una organización a convertirse en una empresa Lean y alcanzar la Agilidad Empresarial (Business Agility), el paradigma empresarial para las compañías que van a florecer en el despliegue de la quinta revolución tecnológica.

La novedades que nos trae esta nueva versión se pueden ver resaltadas en la imagen al final post y son las siguientes:
  • Business Agility: Agilidad Empresarial, el nuevo marco incluye la capacidad para poder competir y prosperar en la era digital respondiendo rápidamente a los cambios del mercado y a las oportunidades emergentes con soluciones empresariales innovadoras.
  • Measure and Grow: se focaliza en cómo medir el estado de Business Agility y cómo acelerar el crecimiento para mejorar los resultados económicos generales.
  • Organizational Agility: esta nueva competencia de Agilidad organizacional describe cómo los líderes Lean thinkers y los equipos ágiles optimizan sus procesos de negocio, desarrollan estrategias con compromisos claros y adaptan rápidamente la organización para capitalizar nuevas oportunidades.
  • Enterprise Solution Delivery: antes Business Solutions and Lean Systems Engineering; esta competencia describe cómo aplicar los principios y prácticas Lean-Agile a la especificación, desarrollo, implementación, operación y evolución de las aplicaciones de software, redes y sistemas ciberfísicos más grandes y sofisticados del mundo.
  • Agile Product Delivery: antes DevOps and Release on Demand; se ha convertido en la competencia Agile Product Delivery, que es un enfoque centrado en el cliente para definir, construir y liberar en un flujo continuo productos y servicios de valor para clientes y usuarios.
  • Continuous Learning Culture: esta nueva competencia de cultura de aprendizaje continuo describe un conjunto de valores y prácticas que alientan a las personas, y a la empresa en su conjunto, a aumentar continuamente el conocimiento, la competencia, el rendimiento y la innovación.
  • Agile Teams beyond Technology: se ha reestructurado esta competencia de Team and Technical Agility que describe las habilidades críticas, los principios y prácticas Lean-Agile que los equipos ágiles y los equipos de equipos ágiles (ARTs) utilizan para crear soluciones de alta calidad para sus clientes.
  • Portfolio Vision: la competencia de Lean Portfolio Management se ha reescrito como una capacidad organizada para alinear la estrategia con la ejecución, cumplir con los compromisos existentes de manera confiable y permitir una mejor innovación.
  • Customer Centricity: el nuevo marco incluye design thinking para centrarse en sus herramientas y prácticas para poner al cliente en el centro.
  • Essential Level: los niveles de equipo y programa (ART) se han unido en uno sólo que corresponde a la configuración essential.
  • Continuous Delivery Clarity: se muestra más claridad en el flujo de exploración continua, integración continua y despliegue continuo en la ejecución de las iteraciones.
Las novedades de la versión 5.0 sobre el Big Picture de SAFe®
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

martes, 19 de noviembre de 2019

¿Dónde inspirarse para encontrar Leading Indicators?

Los Leading Indicators ayudan a los Propietarios del Producto
a tomar las decisiones acertadas - cortesía de Pixabay
Los Leading Indicator están tomando mucha importancia en el desarrollo ágil de software; este implica construir los mejores productos posibles de forma iterativa y con feedback frecuente, y los Leading Indicators son indicadores de feedback predictivo clave para el desarrollo ágil con una entrega máxima de valor.

Los Leading Indicators son cualquier indicador predictivo que cambia antes de que el resto de los indicadores económicos comiencen a ir en una dirección particular, nos sirven para detectar señales de advertencia tempranas y a tomar medidas decisivas mientras todavía estemos tiempo. No son indicadors precisos, pero ayudan a los observadores del producto en el mercado a tomar decisiones rápidas y acertadas, a Propietarios del Producto y Product Managers a decidir lo que construir y lo que no.

En entornos tradicionales estamos rodeados de Lagging Indicators, indicadores que miden el resultado final de nuestra estrategia y esfuerzos. Son fáciles de medir y nos dicen cómo nos está yendo como organización, pero en la mayoría de los casos son difíciles de influir o de mejorar directamente.

Veamos un ejemplo ilustrativo: Imaginemos que quiero adelgazar. Una medición clásica sería el peso, quizá al final del día o al final de la semana. El peso es un Lagging Indicator, la medición es a posteriori, a lo mejor me he esforzado mucho y he ido al gimnasio toda la semana, y resulta que no he perdido nada de peso, me he dado cuenta demasiado tarde. Un Leading Indicator sería medir las kcal que tomo durante el día, si me quedo un poco por debajo de las aproximadamente las 1800 kcal que necesita mi organismo al día, tengo todos los números de haber adelgazado al final de la semana.

Veamos un ejemplo de TI: imaginemos que queremos sustituir los diferentes logins de los sistemas de nuestra organización por un single-sign-on. Un Leading Indicator sería medir el aumento de single-sign-ons versus el descenso de logins individuales, esa tendencia nos muestra si nuestra idea de single-sign-on tiene o no éxito entre los empleados de la organización.

Leading indicators sobre el uso de historias de usuario, sobre la sustitución de funcionalidades como en el ejemplo del single-sign-on, sobre tests A/B en los que medimos que solución prefiere nuestro usuario o cliente, son una herramienta clave para que Propietarios del Producto y Product Managers tomen las decisiones adecuadas para construir el mejor producto posible, maximizando así el retorno de la inversión hecha en el mismo.

Podemos inspirarnos en el marco de Google HEART para encontrar Leading Indicators:
Google HEART Framework
y también en las Pirate Metrics de Dave McClure:
Dave McClure's Pirate Metrics

sábado, 16 de noviembre de 2019

¿Todos los equipos de un área o una compañía han de tener el mismo tablero?

Introduciendo límites WIP: Los tableros
deben de estar en continua evolución
Hoyendía la mayoría de compañías ya tienen varios equipos ágiles trabajando; llegado un momento de mínima madurez la inercia tradicional lleva a estas a querer estandarizar las prácticas y procesos ágiles. 

Nuestra mentalidad tradicional viene de la producción en masa, de la estandarización y de los productos commodity; la cuestión es que eso ya no funciona en nuestro mundo actual donde los proyectos y productos son de muy distintas naturalezas, de modelos de negocio dispares y de una hipersegmentación del mercado.

Para afrontar esa realidad necesitamos de la Agilidad y de equipos autoorganizados que hagan frente de forma adaptativa y flexible a esa realidad de proyectos y productos siempre cambiante. Visto esto podemos imaginarnos que los tableros de los equipos deben de ser únicos y haber evolucionado hacía aquella configuración que aporte más al equipo para que sean realmente una herramienta que les permita maximizar el valor entregado.

Tablero de un equipo de Kanban con multitud de estados
Una de las mejores formas para evolucionar hacia tableros útiles es mediante tableros físicos y post-its. Son una forma muy flexible de visualizar y ajustar continuamente el flujo de trabajo, permitiendo que cada equipo descubra su propio mejor proceso. Herramientas como JIRA llevan a que las personas se focalicen en aprender el proceso de la herramienta y limitan el descubrimiento del proceso propio y la mejora continua del mismo.

Como podemos ver los tableros que potencian al máximo a los equipos deben de ser únicos, lo que no significa que no pueda haber un patrón en común. Probablemente los flujos de trabajo y valor, y las políticas de la compañía lleven a un diseño con partes comunes.

Los tableros de equipos Kanban son los que más diferentes suelen ser. La metáfora para los equipos Kanban es la carrera de relevos; donde un especialista pasa el testigo al especialista del siguiente estado, donde los estados representan un flujo de trabajo o de valor muy específico. Cada equipo Kanban puede estar gestionando cosas muy distintas a los demás, por ejemplo el mantenimiento de un software, la venta y seguimiento de un producto, la planificación de un evento...

Tablero de Scrum o scrumboard (TODO, DOING, DONE)
En cambio los tableros de los equipos de Scrum suelen ser más homogéneos. Son equipos donde el enfoque es el holístico y su metáfora es el equipo de rugby, donde  un equipo al completo, como un ente de nivel superior, intenta recorrer el campo como una unidad, pasando la pelota de un lado a otro.

Los tableros de equipos de Scrum suelen ser mucho más parecidos, aunque casi nunca iguales. Puede haber áreas específicas del equipo, convenciones de colores o de elementos del equipo que los hacen diferir de los demás.

Los Scrum Masters y coaches ágiles aprendemos a leer los tableros de los equipos, y percibimos que la madurez en Agilidad se puede leer en la diversidad de tableros de los distintos equipos de una compañía.

miércoles, 6 de noviembre de 2019

¿Cómo de importante es dar permiso para fallar?

Permitido fallar, para aprender...
Cortesía de Pixabay
Uno de los beneficios que nos traen los marcos ágiles como Scrum son entornos de confianza donde los individuos pueden exponer su opinión sincera, un entorno donde el coraje es un valor, donde se puede disentir y decir que "no" sin temor a consecuencias y donde el conflicto es sano y representa diversidad. Solo así conseguimos entornos en los que las planificaciones de sprint y las PI Plannings se tiñen de factibilidad y llevan al éxito, ya que los que van a hacer el trabajo crean esos planes y tienen toda la libertad para hacer planes en los que crean de verdad.

Para que todo esto ocurra es necesario aprender, y para aprender es necesario fallar. Quizá algunos conozcáis el vídeo de la bicicleta invertida; en ese vídeo Destin de Smarter Every Day nos muestra entre otros aprendizajes que para aprender a ir en bicicleta invertida hay que desaprender primero el ir en bicicleta normal. El mensaje de fondo es que para cualquier cambio, como lo es una transformación ágil, se requiere de un aprendizaje, y para aprender hay que caerse unas cuantas veces de la bicicleta y levantarse para intentarlo de nuevo.

Por tanto en una transformación ágil es necesario que la compañía como sistema falle rápido para aprender rápido, y para ello es necesario desbloquear el posible miedo al fallo de los individuos. Como coaches ágiles debemos de sugerir al CEO o a los altos directivos y líderes dar un mensaje muy explícito, como por ejemplo: "Tenéis permiso para fallar, fallad rápido, aprended rápido y haced grandes cosas".

No podemos esperar que los equipos lean un libro sobre bicicletas, o un marco ágil, y después ya sepan montar en bicicleta; hay que empezar a caminar, a caerse y a levantarse. Es esencial que los directivos lo entiendan y den mensajes que desbloqueen ese miedo a caerse.

Lo que importa es un ritmo de mejora continua sostenible
Cortesía de Pixabay
Cuando los equipos sienten que pueden fallar son más valientes y se retan a ir un poco más allá de lo que creen que son capaces. Un equipo que se rete quizá solo llegue al 80% de lo que se ha propuesto, pero su coraje, su proactividad y su energía les habrá llevado a hacer mucho más de lo que hubieran hecho pensando en cumplir al 100% sus objetivos. Equipos que entregan el 100% de lo planificado son equipos que probablemente solo hagan lo de siempre, sin retarse ni evolucionar y sin mejorar de forma continua.

Uno de los mensajes más potentes que he oído fue de un directivo que dijo a todo el ART (Agile Release Train) de 80 personas, un equipo de equipos, que en el primer PI, ciclo de incrementos en entorno trimestral, el resultado podía ser un "piece of shit" que nadie quiera, y que eso no le importaba... lo que le importa es que el ART coja ritmo, ¡un ritmo sostenible de mejora continua! Les dio permiso a fallar, a rechazar, a decir que "no", y además les animó a planificar tiempo para aprender y explorar en sus sprints.

En nuestra cultura es esencial este tipo de mensaje. Venimos de una cultura del pecado original, del juicio ajeno y del "no" como primera opción. Para que nuestros equipos hagan grandes cosas solo los líderes pueden desbloquear esos comportamientos que tanto tiempo nos han impregnado.

martes, 22 de octubre de 2019

¿Qué dinámica utilizar para establecer los valores de un equipo o tribu?

Para que un árbol florezca
necesita buenas raíces (valores)
Cortesía de Pixabay
Aunque los equipos ágiles tengan interiorizados los valores de Scrum y las tribus o ARTs los valores de escalado o SAFe®, es importante ser conscientes de los valores que el grupo considera importantes y crear alineamiento entre y con ellos. No olvidemos que los valores son los fundamentos que guían la conducta para llevar a equipos y empresas a nuevas formas de trabajar con mejores resultados de negocio, entre ellas a la Agilidad.

En este post quiero presentar la dinámica de los valores guía que lleva a obtener acuerdos que los miembros de los equipos consideren necesarios para trabajar en equipo y fortalecer la cohesión, consensuando los valores principales y su significado.

La dinámica la ha de facilitar un Scrum Master, un coach ágil o una persona con habilidades de facilitador. En un primer paso se obtienen los valores individuales miembro a miembro, un valor por post-it, para luego consolidarlos todos en un único tablero. Para inspirarnos podemos mostrar valores principales como los de la lista que sigue:
  • Alegría: ilusión, jovialidad, buen humor
  • Alineamiento: para mantener el ritmo y un objetivo único del equipo o de la tribu
  • Ambición: trabajar fuerte, aspiraciones
  • Autonomía: libertad, autogestión, autoorganización, autodisciplina, independencia
  • Calidad: excelencia en el trabajo
  • Colaboración: creamos estructuras y utilizamos métricas para que los personas tengan interés individual en colaborar
  • Compromiso: sentirnos comprometidos con el trabajo
  • Confianza: crear un ambiente de confianza y creer que las personas hacen lo mejor que pueden dadas sus circunstancias
  • Coraje: aceptar retos juntos, defender ideas, decir que "no"
  • Cortesía: ser atentos, educados
  • Foco: trabajar en el mínimo número de cosas posible a la vez
  • Franqueza: manifestamos preocupaciones, expresamos lo que pensamos o sentimos con sinceridad y claridad
  • Honestidad: decente, decoroso, razonable, justo, probo, recto, honrado
  • Humildad: tenemos conocimiento de las propias limitaciones y debilidades, mostramos vulnerabilidad
  • Inspiración: sugerir ideas creadoras, suscitar sentimientos
  • Limpieza: ser cuidadoso, ordenado
  • Obediencia: ser sumiso, respetuoso
  • Perdonar: dispuesto a perdonar y a reconocer errores
  • Prestigio: reputación, fama o logros
  • Propósito: el sentido que se otorga al equipotribu
  • Reflexión: pensar 2 veces antes de actuar
  • Respeto: respetar a cada uno como es y el trabajo de los demás
  • Responsabilidad: seriedad, ser fidedigno
  • Servicial: preocuparse por el bienestar de otros
  • Tolerancia: apertura de mente
  • Transparencia: visibilidad, honestidad, sinceridad, veracidad
Obtenida la lista de valores consolidados, cada miembro del equipo o tribu la ordena según la importancia que le otorga como guía principal en sus vidas, de mayor a menor. El orden ha de ser estricto, no puede haber dos valores en la misma posición.

Se forman grupos de cuatro o cinco personas para que debatan y discutan el orden de los valores y para que reordenen la lista de forma consensuada. Finalmente el equipo o la tribu al completo reordena de nuevo la lista, el resultado es el orden final de los valores guías según lo que piensa y siente el grupo.

Se cierra la dinámica con una reflexión discutiendo y acordando lo que cada valor significa en la práctica diaria, ejemplificando cómo se debe de actuar. Todo ello se plasma en post-its y un tablero, con la idea de revisar y acuatizar los valores periódicamente.
Tablero con el resultado de la dinámica en el que el foco está en los tres primeros valores