martes, 16 de abril de 2019

¿Por qué utilizamos post-its en Scrum?

Tableros con post-its que gestionan los
flujos de valor y trabajo de la compañía
La Agilidad se ve rodeada de post-its, solemos asociar una pared con post-its con equipos de Scrum o Kanban, transformaciones ágiles y Agile. ¡Hasta he oído que la Agilidad consiste en pegar post-its en un tablero o las paredes!

A parte del colorido que aportan los post-its ¿cuáles son los beneficios de utilizarlos?

El post-it es algo muy flexible, podemos escribir en él lo que tenga valor, podemos llevarlo a otra área de la sala o del edificio y tener conversaciones con otros alrededor del concepto escrito, y llegar a acuerdos y decisiones que podemos refleja en otro post-it, quizá de otro color. Los colores de los post-its nos permiten mostrar items de diferentes naturalezas; quizá amarillo para unidades de trabajo, rojo para bloqueos, verde para incrementos funcionales, etc... las personas somos visuales y los post-its son un elemento de trabajo muy alineado con la naturaleza humana que nos hace asimilar y recordar mejor sobre lo que tratan.

En Agilidad los equipos de Scrum o de Kanban hacen que sus post-its recorran tableros en los que se representan diferentes estados en columnas, por tanto los post-its recorren flujos de valor o flujos de trabajo. Eso convierte a los tableros y sus post-its en una gestión visual del flujo y verdaderos puntos de referencia para los equipos, áreas y la compañía en sentido más amplio. Estos dan absoluta visibilidad y transparencia al progreso, podemos ver la situación general o agregada cuando observamos el tablero desde la distancia, y podemos ver el detalle acercándonos a los post-its individuales. Irradian de forma continua la situación actual, son puro elemento de gestión del flujo y de conexión y comunicación entre personas.

Pero, ¿no valdrían de igual manera herramienta con tableros y post-its virtuales como JIRA o Redmine

Visto el punto anterior una de las grandes desventajas de las herramientas con tableros virtuales es que no suelen estar preparadas para dar una visión agregada del tablero, este no suele caber al completo en un solo pantallazo, con lo que se minimizan los beneficios de la visión holística, y eso provoca que las personas pongan el foco en los elementos individuales, probablemente los propios, y se pierda la visión periférica y la colaboración se sienta resentida.

La desventaja más importante es que las herramientas tienen sus procesos embebidos, con lo que las personas ponen el foco en aprender a utilizar la herramienta y sus procesos, no a desarrollar su propio proceso a través de la mejora continua, tal como fomenta la Agilidad. A diferencia de estas los tableros con post-its fomentan la colaboración y el desarrollo del propio proceso a través de la mejora continua.

Para los ecologistas y los que piensan que los post-its hacen que empresas como 3M se forren, quiero invitarles a leer el artículo de Alexander Helleboogh "About post-its and trees" en el que se concluye que un árbol medio provee de 100 post-its al sprint a 10 equipos de Scrum durante 5,5 años, mientras que un árbol no es suficiente para proveer de papel de WC a una única persona en el mismo periodo.

sábado, 13 de abril de 2019

¿Qué significa que un Scrum Master es un System Thinker?

Equipo de desarrollo, el sistema del Scrum Master - cortesía de Pixabay
Imaginemos una situación en la que en un evento de Scrum, por ejemplo una planificación de sprint, un miembro del equipo participa escasamente y está sumido en su móvil.

Un facilitador no System Thinker lo que haría sería dirigirse a la persona en concreto, quizá en un break, y hacerle ver que su comportamiento no es el adecuado y que perjudica seriamente al resto y al evento.

Para fomentar un comportamiento adecuado como equipo integrado es necesario una comprensión superior del sistema y hacerles entender a todos los miembros que la creación del valor solo es posible mediante la colaboración de todos los miembros. Por tanto un Scrum Master System Thinker percibe y entiende el problema a nivel de equipo e intentará resolver el problema desde el equipo, utilizando el sistema para resolver el problema y así hacer evolucionar y crecer al equipo.

En la situación descrita al inicio del post un Scrum Master reconoce el problema que hay en el sistema y pensará en qué actividad o práctica puede intentar aplicar para hacer emerger el problema y que ayude a que el propio equipo lo resuelva. Por ejemplo una práctica colaborativa, como un planning poker, una retrospectiva, una dinámica de team-building... una dinámica en la que todos tengan que participar y donde la peer pressure hará que la persona disonante se alinee.

Liberating Structures tiene un repositorio de 33 métodos
Podemos utilizar actividades de Liberating Structures que nos provee de un repositorio de casi medio centenar de métodos accesibles a un Scrum Master para hacer que todas las voces de un sistema o equipo participen, son métodos 100/100, 100% de los miembros al 100% en el 100% de las actividades. Mencionar que un 20/80 no es inusual, un 20% de los miembros acaparan el 80% de la actividad. Con estas actividades el Scrum Master hará que todos se sientan incluidos y comprometidos.

En otras ocasiones el Scrum Master utilizará alguna dinámica dirigida a resolver el conflictoEn una ocasión distribuí tres caramelos a todos los miembros del equipo y les invité a regalar sus caramelos al resto acompañando cada caramelo de unas palabras de agradecimiento por alguna razón concreta. El miembro disonante se quedó sin caramelos; me quedé cerca de él y cuando se acercó conversamos; él sabía perfectamente porqué había ocurrido.

Por ello es tan importante que los Scrum Masters tengan habilidades blandas como las habilidades sociales y conocimiento de coaching sistémico como el impartido por ORSC™.

El coaching sistémico entiende a empresas y equipos como un sistema formado por elementos interconectados cuyas acciones y decisiones individuales repercuten en los demás y en todo el sistema. Este tipo de coaching ayuda a cada individuo a contribuir al sistema completo y a lograr un equilibrio global, aporta soluciones sencillas y rápidas a situaciones complejas a través de la interrelación entre los individuos. Por otro lado sirve para detectar el origen de diferentes problemas o conflictos organizacionales para analizarlos y ayudar a solventarlos.

miércoles, 10 de abril de 2019

¿Scrum es una metodología o es un marco?

Marco de Scrum, cortesía de Miguel Ángel Sobrino :-)
En múltiples ocasiones hemos oído el término metodologías ágiles, concepto que chirría a los agilistas y que estos suelen corregir por métodos ágiles y/o marcos ágiles. Entonces, ¿cuál es la diferencia entre metodología y marco?

Alexandre Magno en una clase magistral resumió la diferencia en una comparación muy clarificante:
  • Una metodología es una forma de trabajar lista para usar, una forma de trabajar para followers.
  • Un marco es un conjunto de valores y prácticas que está listo para empezar a construir la propia forma de trabajar a través de la mejora continua, para aquellos que lideran su forma de trabajar en su propia singularidad e identidad de empresa.
La definición formal del concepto de metodología hace referencia al conjunto de procedimientos racionales utilizados para alcanzar el objetivo que rige una serie de tareas que requieran habilidades, conocimientos o cuidados específicos. A su vez un marco de trabajo se define como un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia para enfrentar y resolver nuevos problemas de índole similar, por tanto es algo incompleto que desarrollamos a nuestra medida.

Scrum por tanto es un marco a la vez que un contenedor para otras prácticas o métodos ágiles como TDD y BDD por ejemplo, marco que fomenta equipos autoorganizados que deciden qué, cuando y como usar estas prácticas. En una metodología los equipos no piensan en su forma de trabajar, se basan en un proceso con pasos predefinidos; en cambio con Scrum los equipos piensan y reflexionan sobre su forma de trabajar y la mejoran continuamente a través de las retrospectivas, lo que fomenta el descubrimiento y empirismo hacía una mejor forma de trabajar en continua evolución.

martes, 2 de abril de 2019

¿Qué es y como funciona un Centro de Excelencia Lean-Agile (LACE)?

Velando por la excelencia - Cortesía de Pixabay
SAFe® define el Centro de Excelencia Lean-Agile (LACE) como un equipo de personas dedicadas a la implementación de la forma de trabajo Lean-Agile.

Equipos de 4 a 6 personas dedicadas el 100% pueden apoyar a unos pocos cientos de practicantes, mientras que equipos de 8 a 12 personas pueden apoyar proporcionalmente a grupos más grandes.

Punto focal

Evaluación y mejora de cada una de las cinco competencias básicas que identifica SAFe de una empresa Lean:
Responsabilidades
Forma de trabajar

El funcionamiento es el de un equipo ágil. Como resultado, se necesitan roles similares:
  • El Propietario de un Producto trabaja con las partes interesadas para priorizar la pila de transformación de los equipos.
  • Un Scrum Master facilita el proceso y ayuda a eliminar obstáculos e impedimentos.
  • El equipo es multifuncional. Personas creíbles de varias áreas funcionales son los miembros integrales del equipo. Eso les permite abordar los elementos de la pila donde sea que surjan, ya sea que estén relacionados con la organización, la cultura, el proceso de desarrollo o la tecnología.
  • Un líder de nivel C generalmente actúa como el gerente de producto del equipo.
En base a la información anterior proponemos un ejemplo de la misión de una LACE para una empresa proveedora de servicios de TI ficticia:
Para ADVANCED IT Inc.
Quienes proveen de servicios de TI a terceros (desarrollo, mantenimiento, servicios)
El Centro de Excelencia Lean-Agile
Es un equipo multifuncional Lean-Agile a tiempo completo de gestión del cambio
Que conduce la transformación de ADVANCED IT Inc. a una forma de trabajar Lean-Agile
A diferencia de nuestros esfuerzos tradicionales de transformación
Nosotros proveemos agentes de cambio Lean-Agile dedicados al 100% y el liderazgo comprometido para implementar el entrenamiento, procesos, tecnología, cultura, herramientas y cambios a nivel de gobernanza necesarios para alcanzar los beneficios de una forma de trabajar Lean-Agile

Dentro del Alcance
Fuera del Alcance
  • Cambios en la estructura organizativa
Criterios de éxito
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

miércoles, 27 de marzo de 2019

¿Quiénes son los interesados?

Interesados, cliente, usuarios, Propietarios de Negocio... cortesía de Pixabay
Los interesados son el rol que representa a todos aquellos que no son equipo Scrum y que son consumidores del producto en construcción o que pueden influir en él; ayudan a descubrir, desarrollar, lanzar y promover el producto. El éxito no depende directamente de ellos pero su participación si puede ser decisiva. Son el cliente, los usuarios, un patrocinador o sponsor, un inversor... cuyas responsabilidades suelen cubrir el dar feedback, dar claridad sobre el valor de negocio, asesorar, sugerir, colaborar, apoyar...

El Propietario del Producto es el responsable de identificar a los individuos de esta categoría y mantenerlos siempre presentes e involucrados.

Clientes: los usuarios o destinatarios finales del valor entregado que por ende van a consumir el producto y están dispuestos a pagar por él, no olvidemos que sin cliente no hay producto

Clientes proxy: En las empresas hay personas que entienden las necesidades del cliente y que nos permiten desarrollar comprensión para una buena solución, a veces entienden al cliente directo y a veces representan a clientes indirectos como lo son los potenciales compradores de una tienda on-line. Pueden ser personas del servicio de atención al cliente, del centro de contacto, de ventas, de finanzas, de marketing, de legal...

Ambas clases de clientes son clave para la mejora continua del producto, su feedback es el más valioso para tomar decisiones sobre cómo y en qué dirección seguir evolucionando el producto.

Stakeholders: son aquellos interesados que se ven afectados por cada uno de los incrementos que se generan a lo largo las etapas del ciclo de vida del producto... todos ellos pueden aportar sus necesidades, deseos, inquietudes y feedback en las revisiones de sprint.

Business Owners: los Propietarios de Negocio son Key Stakeholders, aquellos interesados clave que guían en la construcción por valor y hacia los resultados apropiados, son fundamentales para garantizar el éxito. Las responsabilidades principales del Propietario de Negocio son:
  • Asegurar que los objetivos comerciales se comprendan y que todos estén alineados con estos.
  • Con su asesoramiento juegan un papel clave clarificando el valor de negocio para garantizar y maximizar el valor de los sucesivos incrementos.
  • Estar atentos a los compromisos y dependencias externas.
  • Asistir a revisiones de sprint para ver el progreso y proporcionar feedback.
  • Ayudar a que la inversión/presupuesto se aplique en las historias de usuario y objetivos de sprint adecuados.
  • A través de la comprensión del negocio y el hecho de que no hay valor si no hay entrega, ayudar a comprender la cultura de responsabilidad compartida DevOps.
Los Propietarios de Negocios pueden identificarse a través de preguntas como las siguientes:
Como podemos ver la participación activa de los Propietarios de Negocio es un factor crítico para el éxito de la construcción de productos con Scrum, o en caso de un producto grande con un marco de escalado. Por tanto Scrum Masters y Propietarios del Producto deben de tratar de que estos estén lo más alineados e involucrados posible.

domingo, 24 de marzo de 2019

¿Porqué la Agilidad desarrolla productos con flujos de valor?

En el meetup de modelado de una visión de portfolio con el SAFe® Portfolio Canvas Sonia preguntó sobre el significado de flujo de valor, o Value Stream en SAFe. Resultó que explicarlo fue más complicado de lo que hubiera pensado, de hecho no lo conseguí ya que yo mismo no tenía toda la claridad necesaria, así que decidí trabajar el tema y escribir este post.

Hoy en día conviven dos formas para desarrollar un producto de TI, la clásica a través de un proyecto en cascada enmarcado por el triángulo de hierro (alcance, coste y tiempo fijos), y la ágil a través de lo que SAFe denomina un flujo de valor. 
Dos formas de desarrollar un producto: proyecto en cascada y flujo de valor
Para entender mejor un flujo de valor repasemos primero lo que es un proyecto; este se compone de un alcance inicial cerrado, un presupuesto cerrado y un línea de tiempo con fecha de entrega. Incluye también un equipo constituido para el proyecto, los materiales y los sistemas y recursos necesarios. 

Un flujo de valor es, a semejanza, un conjunto de pasos por los que fluye un elemento de valor (una petición de un cliente por ejemplo), las personas necesarias en forma de equipos, tribus o trenes, y los materiales y sistemas necesarios. Tiene un presupuesto inicial sobre el que se pivota o persevera en función de lo aprendido a lo largo de ciclos de mejora continua sobre el producto. Son la forma ideal de desarrollar un producto con el ciclo de Lean Startup
El flujo de valor (ValueStream) incluye la secuencia de pasos para la entrega de valor, las personas, los sistemas y materiales
Imágenes PixaBay: Equipo Scrum, ART, Incremento y Sistemas y Materiales, y Tribu de Henrik Kniberg & Anders Ivarsson
Aplicando mentalidad ágil comprendemos que invirtiendo en flujos de valor en vez de proyectos maximizamos el beneficio económico y minimizamos los costes de la demora, entendiendo como tales los costes derivados de no utilizar flujos de valor. Los beneficios que obtenemos al trabajar con flujos de valor son:
  • Equipos, trenes y tribus hiperproductivas concebidas para continuidad a largo plazo, permitiendo así que se integren verdaderamente sus miembros y formen algo más grande que los individuos. El flujo se acelera a través de la autoorganización, la multifuncionalidad, el empoderamiento y en el caso de TI la cultura DevOps. El mayor desperdicio en los proyectos suele ser todo el aprendizaje por el que equipos formados específicamente para el proyecto han de pasar, para que cuando estén rodados se desmonten para crear nuevos equipos para nuevos proyectos y se inicie un nuevo ciclo de aprendizaje.
  • Sistemas, materiales y recursos que facilitan a equipos y al flujo a ser eficientes. Las herramientas adecuadas para la construcción de software, así como herramientas que aceleran el flujo, como son la integración continua, los tests automatizados, los despliegues automatizados etc., son esenciales para maximizar flujo y beneficio. Estas requieren inversión en infraestructuras y herramientas necesarias, que en todo caso es mucho más económica que los retrabajos, tests manuales y despliegues manuales que ocurren en la mayoría de proyectos en cascada.
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

martes, 19 de marzo de 2019

¿Cuáles son los tres puntos críticos comunes de los que hemos de aprender al implantar Scrum?

Las compañías tradicionales que inician su andadura en Agilidad e intentan implantar Scrum suelen tener que pasar por tres puntos críticos y efectuar su aprendizaje particukar para tener éxito y acelerar la entrega de valor.
Los tres puntos críticos susceptibles de aprendizaje
1. Los equipos son quienes deben de estimar lo que cabe en la pila de sprint

Una de las disfunciones habituales se produce cuando no es el equipo de desarrollo el que estima qué cabe en la pila de sprint; en ocasiones lo hace un "jefe de proyecto" y en otras ocasiones el contenido del sprint es la parte proporcional de un alcance de proyecto cerrado negociado de antemano.

Este último es el caso de empresas que se basan en un modelo de obediencia de sus empleados, un gestor les dice al equipo cuál es la pila de sprint a ejecutar y este simplemente lo hace... o lo intenta. Este modelo no suele funcionar ya que el equipo no siente verdadero compromiso hacia la pila, se esfuerza y hace lo que puede y si no llega siente que no es culpa suya ya que la pila fue una imposición.

En un modelo de compromiso hemos de entender que sólo las personas que van a hacer el trabajo pueden estimarlo. Obtendremos compromiso cuando el equipo decide libremente lo que cabe en la pila de sprint, al final de la planificación de sprint el equipo debe de estar totalmente convencido de que la pila es perfectamente ejecutable a lo largo del sprint. Solo así conseguiremos compromiso y que el equipo ponga el esfuerzo y toda su energía en la construcción del incremento.

Para que los equipos tengan oportunidad de aprender qué cabe en su pila de sprint hemos de darles la oportunidad para encontrar su capacidad, llamada velocidad en Scrum. Eso implica que la compañía les ha de dar permiso a fallar para aprender del fallo, usualmente un equipo novel encuentra su capacidad a partir del tercer sprint.

2. Aprender a terminar el sprint antes de empezar el siguiente

Una de la características del ser humano es que nos es muy fácil abrir y empezar cosas nuevas, pero nos cuesta horrores acabar las cosas. En este punto crítico el equipo, y el entorno que le rodea, ha de aprender uno de los mantras que provienen de Lean Kanban:

Stop starting and start finishing - Termina de empezar y empieza a terminar

Un incremento resultante de un sprint se define como un parte del producto totalmente terminada, con todo lo acordado hecho, y potencialmente liberable a producción. Para que todos entendamos qué significa terminado Scrum introduce el artefacto de la definición de hecho (DoD). Algo no está terminado hasta que todos los puntos de la definición de hecho estén chequeados y el usuario o interesado pueda usarlo o probarlo en un entorno del que sea propietario.

Una de las mayores disfunciones de Scrum ocurre cuando los equipos no son capaces terminar los sprints de manera recurrente. Puede haber diferentes causas detrás de la disfunción, como el punto 1 por ejemplo, cuando el equipo no tiene la oportunidad de aprender cual es su capacidad para la pila de sprint, o cuando el entorno que rodea al equipo no permite que cumplan con la definición de hecho; un ejemplo corriente es un entorno de despliegue para el usuario, test o preproducción por ejemplo, que no es estable e idéntico al de producción.

A nivel de compañía hay que pasar por el aprendizaje de que lo más importante para un Scrum exitoso es que los equipos encuentren su ritmo en el que de forma sostenible sean capaces planificar y entregar cosas totalmente terminadas. Llegado a este punto es donde los equipos aceleran y se pueden alcanzar incrementos de productividad del 400%, como muestran algunos estudios como el Chaos Report de Standish Group y los Annual State of Agile Reports de Versionone. 

3. Apoyar a los equipos para acelerar el flujo de entrega de valor

Las retrospectivas son el latido de la mejora continua, en cada una de ellas el equipo identifica su mayor "dolor" y busca mejoras para que no tropiece de nuevo en las mismas piedras en ocasiones futuras.

Las causas raíz de sus problemas pueden tener el origen dentro del equipo, con lo que el mismo equipo encuentra las mejores soluciones al visibilizar y tratar el problema desde dentro. En otras ocasiones las causas raíz son externas y por ellos mismos no pueden mejorar, así que Scrum Master ha de elevar las soluciones a donde corresponda para que se apliquen.

Este es otro punto crítico, ya que las compañías han de poner los medios para que el entorno del equipo dé solución a sus problemas, un aprendizaje a realizar para entender que es necesario poner los medios para que los equipos estén focalizados en un trabajo de valor, y para que el flujo de trabajo del equipo de desarrollo acelere y aumente la productividad del sistema. Cuando no ponemos los medios ocurre que los equipos tropiezan una y otra vez con el mismo problema y sientan frustración, hecho que a su vez afecta negativamente a la construcción de un software que de buenas soluciones a las necesidades de nuestros clientes.

Termino con una frase que me encanta: ¡para que hacer cosas serias es necesario divertirse! Encorsetados, cansados, estresados... difícilmente haremos cosas serias.