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 entre 1 y 3 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 de desarrollo, o Development 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 de desarrollo.
Dos formas de desarrollar un producto: proyecto en cascada y flujo de valor de desarrollo
Para entender mejor un flujo de valor de desarrollo repasemos primero lo que es un proyecto; este se compone de un alcance inicial cerrado, un presupuesto cerrado y una 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 de desarrollo 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 de desarrollo 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 de desarrollo 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 de desarrollo. Los beneficios que obtenemos al trabajar con flujos de valor de desarrollo son:
  • 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 particular 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.

lunes, 18 de marzo de 2019

¿Cómo acercar y mantener a las personas de negocio comprometidas?

Recordemos que en las revisiones de sprint los interesados o stakeholders, los Business Owners y usuarios, en definitiva los clientes, son la audiencia primaria. En la reunión el equipo de desarrollo muestra lo que ha construido durante el sprint y así obtener feedback para mejoras y finalmente entregarles ese incremento en un entorno donde puedan probarlo. Esto es parte del ciclo de feedback que incorpora Scrum, con el objetivo de que el equipo de desarrollo siempre esté focalizado en construir lo que más valor aporte.

Los interesados no solo son importantes en las revisiones, lo son también en los refinamientos que el Propietario del Producto haga con ellos, y el la participación u aceptación de la pila y meta de sprint resultantes de la planificación de sprint.

Podemos desprender del ello que lo que asegura que se construye la mejor solución posible, y por tanto se obtenga el mayor beneficio económico posible, es el compromiso de los interesados en estos eventos de Scrum.

Los interesados tienen el conocimiento de negocio y mercado necesario para garantizar que la financiación asignada a los productos que se construyan se destine a las cosas correctas. Por lo tanto son un elemento crítico para garantizar que las prioridades de los equipos estén alineados con necesidades reales y con la estrategia de negocio.
Jenga, un juego de habilidad física
No es inusual encontrar interesados con tiempo escaso y que por sus otras tareas están poco comprometidos con los equipos de desarrollo. Esa carencia de compromiso suele ser un problema habitual en compañías que recién incorporan Scrum, con lo que es necesario realizar actividades y dinámicas para atraerlos e involucrarlos en los eventos de de Scrum.

La mejor forma para crear compromiso es crear confianza y entendimiento, y hacerlo a través de la gamificación es una opción excelente ya que las personas cuando jugamos dejamos de lado nuestras mochilas, somos más abiertos de mente y nos comportamos tal como somos.

Así que ante un problema de involucramiento diseñamos un juego para que interesados y equipos de desarrollo jugaran juntos, se creara esa confianza y todos entendieran que la construcción de las cosas correctas es responsabilidad compartida de ambos, y que por tanto colaborar es una necesidad.

Fran y Nayua propusieron basarnos en Jenga, un juego en el que se construye una torre con piezas de madera que luego se retiran una a una intentando que no se desmorone. La idea de nuestra dinámica fue que interesados y equipo de desarrollo construyeran de forma iterativa y como un equipo único la torre más alta posible.

Anunciamos que todos, Propietarios del Producto, Business Owners y equipos iban a colaborar con el objetivo de construir LA TORRE MÁS ALTA.

La construcción se hace en 3 "sprints" con:
Todos los elementos de la sala son válidos, la única restricción es que la torre ha de empezar por y acabar en un pieza de madera de Jenga.

Efectuamos la dinámica en multitud de equipos y sus interesados, la creatividad fue increíble. Como elementos de la sala los participantes utilizaron post-its, cinta de carrocero, percheros, mesas, sillas... elementos mucho más allá de lo que hubiéramos podido imaginar. Con la restricción de que la torre hubiera de empezar y acabar en una pieza de Jenga pretendíamos decir que la torre se construyera con piezas de Jenga, pero la suma de ideas y de creatividad llevó a construcciones fantásticas:
Algunas de la construcciones fantásticas de aquellas sesiones
A lo largo de cada dinámica, que duraron dos horas, interesados y equipos estrecharon lazos y crearon sinergias. Percibimos un éxito total cuando algunos de los interesados y equipos de desarrollo decidieron ir a comer juntos después de la dinámica; la barrera negocio/tecnología había caído.

He aquí el equipo de Scrum Masters que facilitó todas estas sesiones
A partir de entonces el involucramiento y compromiso de los interesados se reforzó sensiblemente, estos comenzaron a asistir de forma más regular a los eventos de Scrum y los equipos de desarrollo construyeron soluciones alineadas con necesidades reales.

El equipo de Scrum Masters ensayamos previamente la dinámica con Jenga, nuestra torre la construimos exclusivamente con piezas de Jenga y viendo el resultado pensábamos que fuimos creativos... aún no podíamos imaginarnos lo que ocurriría después.

Mis agradecimientos al equipo de Scrum Masters con los que disfruté mucho: Fran, Nayua, Esther y Mario.

jueves, 14 de marzo de 2019

¿Existe alguna dinámica que facilite una estrategia de mejora de la Agilidad organizacional?

En este post quiero mostrar una herramienta concebida a tal efecto desde Scrum Level®, a continuación replico el post original del blog de Scrum Manager:

Análisis y escalado de la Agilidad con Agilevel 2D Dynamic

Agilevel 2D Dynamic es una dinámica que facilita el análisis y la identificación de la estrategia más adecuada para mejorar la Agilidad organizacional.

A través de un análisis estructurado de los componentes propios de la Agilidad se identifican las áreas que requieren especial atención o acciones de mejora.

Agilevel 2D Dynamic se basa en el modelo Scrum Level® y emplea mecánica de “gamificación” para facilitar la comprensión e implicación por parte del equipo que la realiza. Este equipo lo forman personas del departamento o área que se desea analizar y a través de esta dinámica evalúan de forma colaborativa las dos dimensiones de la organización.

El resultado es un diagnóstico global de la Agilidad de la empresa o departamento, incluyendo las valoraciones parciales de cada principio y valor ágil e identificando los impedimentos que encontrarán las iniciativas de mejora. Este análisis muestra qué áreas se pueden acometer sin cautelas especiales y cuáles requieren especial atención.
Muestra de láminas incluidas en el Agilevel 2D Starter Pack
Agilevel 2D Dynamic ayuda a comprender las implicaciones de los cambios, tanto en la dimensión operativa de la empresa como en su organización o cultura y revela qué acciones podrían producir problemas en lugar de soluciones. Dibuja por tanto una línea guía para el diseño de la estrategia de mejora más adecuada a las características de la organización.

Agilevel 2D Dynamic es una herramienta de asesoría y también puede emplearse como actividad de gamificación en cursos y talleres educativos de Agilidad organizacional basados en el modelo Scrum Level®.

El material se puede descargar desde el enlace siguiente, o desde la página de materiales de agilevel donde también se puede adquirir ya impreso.
Agilevel 2D Starter Pack
Los derechos de uso están parcialmente liberados con licencia cc by nc nd.

No hay ninguna restricción para usos sin ánimo de lucro o de autoformación. Para usos en actividades, empresas u organizaciones mercantiles:

Ensayo de la dinámica Agilevel 2D
Recientemente hicimos un ensayo de la dinámica con un grupo de mandos intermedios que están en el trayecto de adoptar Agilidad en sus áreas.

Después de una sesión con mucho debate los resultados fueron muy interesantes; los productos y servicios que realizan son de calidad pero el ritmo de trabajo actual no es sostenible, con lo que se hizo patente la necesidad de un cambio en la forma de trabajar e ir en dirección Agilidad.