jueves, 24 de agosto de 2017

¿Cómo se sincronizan los sprints en un marco de Scrum escalado?

Actualmente Scrum se ha introducido en muchas compañías, todavía estamos en un estadío temprano en el que falta mucho por hacer y muchas compañías aplican un Scrum adaptado lleno de disfunciones y ScrumButs, pero ya es una realidad. En las compañías que llevan más tiempo y ya tienen varios equipos funcionando con Scrum, surgen necesidades cada vez más urgentes de coordinación y alineamiento de sus equipos, necesidad ante la que Scrum formal se queda corto y no proporciona soluciones.

Para ello han emergido diversos marcos de Scrum escalado en los que se trata de crear equipos de equipos alineados que trabajen como un único organismo. La visión, la hoja de ruta, la estrategia, los entornos… deben de ser compartidos y estar alineados para todos alrededor de productos, proyectos e infraestructura. Esto se consigue cuando todos los equipos planifican las releases de forma cruzada a la vez, con todos presentes, trabajan con la misma cadencia y de manera sincronizada, y entregan software funcional de forma frecuente e integrada.

En caso de productos grandes que requieran varios equipos, la cadencia de construcción puede ser diferente a la de las entregas o releases. Con cada sprint se producen entregas parciales que sirven para alinear e integrar, la entrega a negocio se produce con una cadencia superior, un supersprint o incremento de programa (PI) en SAFe, que es el resultado de lo construido e integrado en varios sprints.
Equipos trabajando con la misma cadencia y de forma sincronizada
  • La cadencia hace que las reuniones sean predecibles y sea posible coordinar agendas, por otro lado reduce la variabilidad ya que la limita el tamaño de los sprints proveyendo ritmo al desarrollo.
  • La sincronización crea entendimiento común, unifica e integra las diferentes ideas y perspectivas de los equipos. Sin sincronización no habría puntos de integración y de aprendizaje sobre el producto y el proceso, la sincronización provee de avance a nivel de equipo de equipos.
  • La combinación de cadencia, sincronización y una planificación cruzada provee a los equipos de una práctica para construir de forma efectiva dentro de un marco de un producto cambiante.
La cadencia y sincronización proporcionan
puntos de integración y aprendizaje
Aplicando la misma cadencia y de forma sincronizada obtenemos puntos de integración y puntos de aprendizaje con cada sprint

Como todos los sprint acaban en el mismo momento podemos integrar las entregas de cada equipo y asegurarnos que lo que han construido todos ellos ensambla y funciona conjuntamente.

De la misma manera podemos inspeccionar a final de sprint la entrega integrada de todos los equipos y así aprender sobre el producto que estamos construyendo, sobre su viabilidad técnica y si las funcionalidades construidas son solución a problemas de negocio.

Finalmente cada final de sprint nos proporciona la oportunidad para efectuar retrospectivas y mejorar el proceso, en particular retrospectivas a nivel de equipos de equipos que permiten mejorar de forma continua el sistema al completo.

sábado, 5 de agosto de 2017

¿Se pueden gestionar proyectos de ingeniería civil con Scrum?

Ya en 1992 se dieron los primeros pasos en investigación Lean en el sector de la construcción. Lauri Koskela, un profesor finlandés, le dio a esta disciplina el nombre de Lean Construction. En 1997 se fundó el Lean Construction Institute que enseña Lean Construction y ha colaborado en numerosos proyectos constructivos a nivel internacional (Estados Unidos, Rusia, Inglaterra, Canadá, Alemania, Dinamarca, Finlandia, Australia, Israel, Noruega, Irlanda, Perú...).

Las herramientas modernas de simulación y realidad virtual han permitido el modelado de información de construcción denominado BIM (Building Information Modeling) que va más allá de las fases de diseño. Se trata de un proceso de trabajo colaborativo para la creación y gestión de un proyecto de construcción, incluidos costes, calendarios y mantenimiento, así como un modelo de información digital que centraliza los datos de un edificio, como son la geometría del edificio, las relaciones espaciales, la información geométrica y las cantidades y propiedades de sus componentes, y lo hace a lo largo de todo su ciclo de vida.

Lo que hay detrás de las siglas de BIM:
  • Building (edificio): un proyecto colaborativo compuesto por áreas (arquitectos, constructores, ingenieros, clientes, propietarios...) en constante diálogo y apoyados por la visualización en tres dimensiones del edificio.
  • Information (información): creación y desarrollo de una base de datos siempre actualizada en sus diferentes perspectivas.
  • Modelling (modelado): el edificio y la gestión del proyecto asociado se modela y construye sobre datos organizados.
B.I.M. es un acrónimo de Building Information Modeling
Agradecimientos a Bonela
El hecho de que todos tengamos móviles ayuda a trabajar con ciclos cortos, al estar hiperconectados y podemos compartir al momento desde fotos a decisiones y todo tipo de actualizaciones del edificio. Todo ello permite iteraciones durante la construcción del edificio sin añadir costes al proyecto, iteraciones que facilitan el contacto y feedback del cliente ya desde la fase de diseño, lo que permite su inclusión en la toma de decisiones.

BIM se ha ido implantado de forma paulatina en diferentes países alrededor del mundo. Siguiendo la Directiva Europea de Contratación Pública 2014/24/UE en Inglaterra su uso ya es obligatorio en todos los proyectos públicos. En España, el Ministerio de Fomento creó en 2015 la Comisión Nacional es.BIM, en la que se está analizando cómo implementar BIM en el sector público y como introducirlo en las licitaciones públicas.

Para la gestión de proyectos de construcción de esta naturaleza, en los que prima trabajar de forma colaborativa, el producto final es complejo y donde la gestión de tiempos y riesgos es clave, se utiliza Scrum en la fase diseño. Marc Bach en su artículo "Scrum in construction" nos describe en 10 puntos en qué consiste Scrum en el ámbito de la construcción:
    BIM hace posible la aplicación de Scrum
    en la construcción - cortesía de Pixabay
  1. Definir el plazo del proyecto y seccionarlo en sprints (normalmente semanas o meses).
  2. En cada sprint se definirá un entregable en BIM a supervisar por la propiedad o el representante.
  3. Se definirán unos roles: Propietario del Producto (definición similar al Bim Manager en pequeños proyectos), Scrum Master (mentor del equipo de desarrollo) y equipo de desarrollo (los modeladores BIM).
  4. Unas reuniones semanales y diarias con los agentes que definen el proyecto con tiempo y tareas a comentar estandarizados.
  5. Las tareas se reflejarán en un panel visual. Así como gráficos de control y avance del proyecto.
  6. Cada sprint es una iteración. Y hay que planificar las tareas a realizar en cada sprint por el equipo de desarrollo.
  7. Es un trabajo colaborativo. Se toman las decisiones en equipo.
  8. El Propietario del Producto es el responsable de coordinar los requisitos del proyecto ejecutivo. Deberá asegurar que el modelo BIM que vaya definiendo el equipo de desarrollo cumple los requisitos del cliente tanto a nivel de coste, plazo, definición y uso posterior.
  9. Se trabaja con rendimientos y duraciones de tareas. Por lo tanto la recopilación de datos será muy importante para proyectos posteriores.
  10. El objetivo perseguido es establecer unos estándares de colaboración y ejecución definidos desde el principio con unos roles claros para garantizar un producto final (modelo BIM) de valor con un uso efectivo de los recursos. La clave del éxito es la repetición de esta estructura diaria y semanal durante el tiempo que dure la redacción del proyecto.

Quiero invitaros a visitar mi post que describe un ejercicio de simulación de Scrum en el que los alumnos construyen un resort del caribe con post-its y material del papelería. Lo hacen con 3 sprints y una de las exclamaciones de alumnos que más me llamó la atención fue: "¡Me esperaba algo más sencillo, no hubiera pensado que construiríamos algo tan bonito!".

Mis agradecimientos a Marc Bach cuya pasión es la divulgación de las buenas prácticas Lean y Agile, que buscan la eficiencia y eficacia, en el sector de la construcción.

jueves, 3 de agosto de 2017

¿Qué representan el objetivo y la pila de sprint?

El objetivo o meta del sprint
Cortesía de Pixabay
He vivido varios equipos que no ponen objetivo o meta de sprint (sprint goal) a sus sprints. Cada sprint debe de tener un objetivo y debe de que quedar reflejado en el tablero scrumboard. Se trata de darle una función coherente a los elementos de la pila de sprint, podemos pensar en el objetivo de sprint como un elevator pitch que habla de los beneficios que va a obtener negocio con lo que se construya en ese sprintLo importante es que el equipo se comprometa con el objetivo, no con el paquete de historias de usuario de la pila de sprintExisten dos términos en inglés que nos dan la pista sobre estos dos conceptos:
  • Output: la salida producida
  • Outcome: el resultado producido en términos de beneficio o de resolución de problemas para negocio
En la gestión clásica de proyectos ponemos el foco en la construcción de outputs. Lo hacemos en forma de funcionalidades, nos basamos en un input a base de una lista de requisitos que llamamos alcance, y a lo largo del proyecto construimos un paquete grande de funcionalidades que cubra esos requisitos, y lo hacemos de forma optimizada para el paquete completo.

Output vs. Outcome, no hay correlación entre uno y otros
Imagen de las monedas cortesía de Pixabay
En cambio en Agile y Lean el foco está en producir outcomes, en construir soluciones a problemas de negocio para hacer una compañía competitiva y que obtenga beneficios de forma sostenida.

Encontraremos ambos términos en cada uno de los sprints en Scrum, cuando obtenemos la pila de sprint y el objetivo en la planificación de sprint. La pila de sprint es el output y el objetivo el outcome; no importa tanto si las historias de usuario entregadas corresponden a lo que se planificó, lo que importa es que las historias entregadas sean la mejor solución para el negocio. Lo clave es que el objetivo guíe al equipo a lo largo del sprint focalizados en la necesidad o problema a solucionar.

Imaginemos la siguiente pila de sprint:
  • Como lector quiero buscar libros por título para encontrar los libros que me gustan
  • Como lector quiero buscar libros por autor para ver otros libros de autores que me gustan
  • Como lector quiero poder ver los resultados de la búsqueda efectuada para seleccionar el que me interesa
  • Como lector quiero una búsqueda avanzada para explorar la librería
cuyo objetivo es:
Permitir la búsqueda de libros a nuestros lectores

Ahora imaginemos que el sprint es a finales de agosto, a las puertas del comienzo de las clases, y a medio sprint nos damos cuenta que lo que necesitan nuestros clientes es otra historia de usuario:
  • Como madre quiero buscar libros por ISBN para comparar los libros de texto para mi hijo
Una posible solución sería incluir esa nueva historia dejando fuera la de menor valor, la búsqueda avanzada por ejemplo. De esa manera no se rompe el objetivo del sprint y maximizamos los beneficios que obtendrá la tienda.

En gestión clásica podemos construir por ejemplo 45 funcionalidades y en un proyecto con Scrum 22, en la gestión clásica quizá se hayan dado solución a 2 problemas de negocio (outcomes) con esos 45 outputs, en Scrum 10 soluciones con esos 22 outputs... esa es la verdadera esencia de Agile y Lean.

Vyacheslav Moskalenko nos describe en su artículo "7 Sprint Goal Patterns for Building Great Teams, Part One" 7 patrones que nos guiarán en la correcta identificación de un objetivo del sprint:
Veamos que ocurre con Scrum escalado, ¿los objetivos siguen siendo la clave para guiarnos hacia buenas soluciones de negocio?

Si miramos el marco de SAFe podemos observar que a nivel de los equipos se construye con iteraciones guiadas por objetivos (Goals), tal como marca Scrum. Cuando escalamos vemos que tenemos pilas de elementos a diferentes niveles, que priorizadas por valor de negocio (realmente WSJF), llevan las intenciones estratégicas a los equipos. Estos las cocinan y así obtienen los objetivos que escalan al equipo de equipos (Agile Release Train) en forma de objetivos agregados (PI Objetives). Estos son un plan factible de entrega de valor para las mejores soluciones a los problemas de negocio.
Essential SAFe con los elementos que guían hacia los outcomes - cortesía de Scaled Agile
La realidad, los verdaderos outcomes, se producen al final de los PI, en PIs guiados por los objetivos y la Continuous Delivery Pipeline. Recordemos que no todo puede saberse al principio, una buena solución se descubre y redefine a lo largo del camino, mediante exploración continua para despejar incertidumbre, puntos de integración y aprendizaje continuo que mejoran de forma iterativa el producto, así como con despliegue continuo que permite validar asunciones y conseguir la mejor solución posible a problemas reales.

martes, 1 de agosto de 2017

¿Cuáles son los beneficios de la estimación con planning poker?

Una de las prácticas más potentes para equipos que empiecen con Scrum es el planning poker, la estimación colaborativa que proviene de eXtreme Programming. Solemos pensar que el objetivo es obtener una estimación consensuada del equipo, cosa que es cierta, pero el objetivo es mucho más profundo: la construcción de una base de conocimiento compartida.

Ejercicio planning poker
Cortesía de Scrum Manager
Fijémonos en lo que significa que dos miembros del equipo estimen en individual una misma historia, y al destapar las cartas uno de ellos tenga una estimación baja, un "2" por ejemplo", y el otro una alta, como un "13" por ejemplo. Básicamente alguien sabe algo que el otro no sabe, o que en caso de un equipo los demás no saben. La conversación que se produce para descubrir el porqué de las diferencias de estimación es la parte más importante, ya que esta alinea el conocimiento de todo el equipo, y se comparten las perspectivas y las opiniones de todos.

El ejercicio trata de estimar el peso de 8 animales de forma relativa considerando al pingüino como un "1". Todos hemos ido al zoo alguna vez o visto documentales de La 2, no somos biólogos ni expertos, pero tenemos suficiente conocimiento sobre animales para poder extraer conclusiones interesantes.

La siguiente imagen muestra los resultados del ejercicio en una clase con 4 equipos, podemos observar que la diferencia entre la suma de la media estadística de medidas reales de los animales y las estimaciones de los no expertos está por debajo del 10%, lo que está dentro del margen que cualquier empresa u oficina de proyectos consideraría como éxito, margen que suele estar entre el 10 y el 15%. Imaginemos que queremos estimar un proyecto de TI de forma relativa y que la incertidumbre con la que lidian los que estimen el proyecto es similar a este ejercicio: ¿nos tiraríamos a la piscina viendo estos resultados? Planning poker es una técnica de estimación rápida que se basa en la inteligencia emocional colectiva, ¿con un margen inferior del 10% no es más que suficiente para estimar un proyecto?
Resultados del ejercicio de planning poker estimando el peso de los mismos en relativo al pingüino, que representa el "1"
Lo más interesante del ejercicio viene cuando pregunto a los asistentes si han aprendido algo sobre animales, algo que no sabían antes. El ejercicio de planning poker habrá hecho que intercambien conocimiento sobre estos animales, mis alumnos cuentan cosas como:
  • ¡No hubiera dicho nunca que una hiena es como un perro grande!
  • La jirafa es mucho más grande, realmente sólo los que hayan visto una en un zoo tienen noción de que puede alcanzar la altura de tres pisos. Es un animal con mucho debate, en ocasiones dividen la jirafa en partes menores y estiman cada una de ellas.
  • La oveja es otro animal del que mucho aprenden, tiene mucha lana, y eso abulta, pero debajo hay un animal mas grande de lo que suelen pensar.
Como podemos ver, el planning poker es una gran herramienta que impulsa la formación de equipos integrados y de excelencia.