¿Qué unidad es la mejor para estimar, horas ideales u horas reales?

Harry Potter, 8 horas de lectura ideales, y ¿cuántas reales?

Tiempo ideal es una medida de esfuerzo, mide en tiempo cuanto cuesta construir algo en condiciones mentales óptimas, sin interrupciones y con todos los recursos necesarios disponibles. El tiempo real es medida de tiempo, la duración que mide el tiempo real que se ha aplicado a una tarea. Por ejemplo, el esfuerzo para leer un tocho de Harry Potter puede ser entre 8 y 12 horas, pero leerlo seguramente será más de una semana.

Se puede utilizar tiempo ideal como unidad de medida del esfuerzo de las historias de usuario y de las tareas, pero no es recomendable. Imaginemos nuestra tarea que reza "leer el tercer tomo de Harry Potter = 8 horas" colgando en el tablero, entra un jefe o directivo, lo ve, y exclama "bien, ¡mañana el libro está leído!"...

El tiempo ideal es una unidad complicada; 24 horas ideales/40 horas reales es una buena productividad para un profesional, pero a quién no esté familiarizado y no lo comprenda le puede chirriar, no siendo consciente de que en la realidad tenemos reuniones, contestamos emails, llamadas telefónicas, descansos, hay días con el ánimo mejor y otros peor... es por ello que es preferible trabajar con una unidad relativa que no tenga nada que ver con el tiempo, unidad como los puntos de historia.

Actualmente nos está funcionando el siguiente esquema de unidades de estimación, historias en puntos de historia y tareas en horas: 

Historias de usuario y tareas estimadas en unidades distintas

1. Estimar las historias de usuario en puntos de historia, una unidad relativa arbitraria, obtenida con planning poker. Al final de cada sprint la velocidad será la suma de los puntos de historia entregados en la revisión de sprint. La velocidad media permitirá planificar el siguiente sprint y proyectar las entregas de la pila de producto en rangos de fechas futuras. Resaltar que elementos grandes como epics grandes y temas se pueden estimar de forma relativa en tallas de camisa.

2. La estimación de las tareas de la pila de sprint la haga el equipo en horas ideales y teniendo en cuenta la disponibilidad real de cada uno. De esta manera el equipo siente seguridad para comprometerse con las historias que ha incluido en el sprint. La suma de horas ideales no tiene porqué llenar el tiempo real disponible. Es la velocidad media, en puntos de historia y pila de producto, en lo que se debe de apoyar el equipo para decidir lo que entra en la pila de sprint.

3. En la reunión diaria cada miembro del equipo reestima en horas "reales" (entiendo como estas horas ideales inmersas en la realidad) sus tareas con el objetivo de marcar en el burndown las horas pendientes y así poder detectar desviaciones. Recordemos que en Agilidad lo que determina el grado de avance del proyecto/producto no es midiendo el trabajo realizado, sino el pendiente de realizar.

Puede sorprender que se mezclen unidades, pero cada una tiene su función y no tienen porqué cuadrar:

• Historias de usuario en puntos de historia: para planificar y decidir qué entra en el sprint.
• En la planificación de sprint las tareas en horas ideales: confirmar y dar seguridad al equipo.
• En la reunión diaria reestimación del pendiente de tareas en horas "reales": para detectar avance y desviaciones, por si fuera necesario tomar decisiones.

Venimos de una cultura de estimación/imputación de horas donde nos convencemos que los números representan la realidad y que han de cuadrar, cuando de lo que se trata, como vemos en este esquema, es de dotar el equipo de herramientas para que se planifique, tome decisiones y se gestione mejor.

¿Qué marco de Scrum escalado elegir?

Actualmente existen varios marcos de Scrum escalado sobre los que la empresas que quieran crecer en Agilidad han de decidir cuál se adapta mejor a sus necesidades. Es un tema de conversaciones y debate muy actual en mis clases y en las empresas que acompaño como coach ágil.

Nexus es un marco leve en detalles y que no trata cuestiones organizativas, y que ha partido de Scrum reutilizando los artefactos, los roles y las reuniones. Es un marco concebido para pequeñas empresas con 3 a 9 equipos de desarrollo.

LeSS consiste un marco de Scrum escalado mínimo que ofrece un alto grado de flexibilidad en su implementación, no es preceptivo y se limita a dar sugerencias. Es una gran opción para organizaciones maduras en Agilidad que estén en fase de crecimiento y que estén buscando un marco que les ayude a escalar Scrum.

DAD es un marco cuyo objetivo es llenar los vacíos de proceso que le faltan a Scrum. Lo hace de forma híbrida en donde gobernabilidad y gestión del ciclo de vida se basan en métodos tradicionales en cascada. Es un marco semi-tradicional válido para grandes empresas.

SAFe® es el marco ágil más conocido por sus éxitos de implementación en múltiples grandes compañías. Está muy estructurado y es prescriptivo, de manera que ayuda a las compañías en su madurez hacía la Agilidad en todos los niveles.

Áreas (de arriba a abajo: Visión, Estrategia y Táctica) que cubren los cuatro marcos:
Verde = cubre, Amarillo = cubre parcialmente, Rojo = no cubre
La imagen de edificio es una cortesía de Pixabay

Resaltar que entre estos marcos no hay ninguna bala de plata con soluciones milagrosas, son marcos de los que se pueden coger las partes que convienen y adaptarlas, pero cuidado, siempre dentro de la madurez ágil.

Veamos los cuatro marcos más en detalle:

---

Nexus

Nexus es el marco escalado de Ken Schwaber pensado para 3 a 9 equipos de Scrum, equipo de equipos que forma la unidad de desarrollo. Añade un "equipo de integración" que se centra en las dependencias, la interoperabilidad y la integración de código entre los equipos de Scrum. "El Equipo de Integración Nexus consiste en individuos que son expertos en el uso de herramientas y prácticas asociadas con el trabajo de desarrollo escalado".

Todos los equipos parten de la misma pila de producto y tienen pilas de sprint individuales que se manejan de forma agregada en el "Nexus Sprint Backlog", pila con la que se da visibilidad de forma integrada del trabajo que están realizando los equipos.

Contiene los eventos formales de Scrum a nivel de coordinación y le añade "Nexus" como prefijo, significa literalmente nexo o punto de conexión y es el mecanismo o nombre para el Scrum de Scrums. Por ejemplo "Nexus Scrum Diario" contiene representantes de cada equipo individual de Scrum.

Nexus, el marco que lleva al corazón del escalado de Ken Schwaber

¿Cuales son los valores de Nexus? Los mismos cinco que Scrum: 1) foco 2) coraje 3) franqueza 4) compromiso 5) respeto.

El marco no trata otras consideraciones organizativas como la estructura organizativa, como lo hacen DAD y SAFe.

---

LeSS (Large Scale Scrum)

LeSS, el marco de Craig Larman y Bas Vodde
para productos menores de hasta 8 equipos

Para la adopción de LeSS la compañía ha de comprender primero los propósitos y elementos de Scrum para un sólo equipo, y escalar a partir de ese punto, manteniendo el propósito dentro de las restricciones de los roles de Scrum formal.

Craig Larman y Bas Vodde crearon este marco para gestionar grandes proyectos dentro de las limitaciones del "Vainilla-Scrum", el Scrum más puro, y han creado con LeSS una elegante extensión de Scrum. Se han desarrollado dos marcos en función del tamaño del proyecto a desarrollar.

Debido a que estos dos marcos, LeSS y LeSS Huge, permanecen fieles a las restricciones de Scrum, LeSS no puede ser considerado como una práctica, sino un marco de diseño de la organización.

LeSS Huge, el marco de Craig Larman
y Bas Vodde para grandes productos

LeSS es para proyectos de hasta alrededor de 8 equipos. Las funciones básicas no han cambiado, pero algunas la de las reuniones cambian y algunas se replican a nivel de equipo cross. Por ejemplo, la planificación del sprint se divide en dos; la primera es una reunión para todos los equipos en donde elijen las historias de usuario en las que van trabajar, y las segunda es una reunión separada por equipo en la que cada equipo crea su plan de sprint. De modo análogo hay una una retrospectiva cross con representantes de cada equipo para facilitar la mejora continua global. Los equipos están organizados como equipos funcionalidades, de extremo a extremo. Se pueden añadir otras reuniones de coordinación entre equipos, por ejemplo en forma de Scrum de Scrums y reuniones Open Space.

LeSS Huge está diseñado para proyectos aún más grandes, con alrededor de un millar de personas para un solo producto. Este marco añade una función adicional, el propietario del área de productos, que asume la propiedad del producto de una sección importante del producto. También se añade una revisión de sprint y una retrospectiva generales para garantizar la coherencia del producto y la mejora de procesos global.

¿Cuales son los valores de LeSS? Los mismos cinco que Scrum: 1) foco 2) coraje 3) franqueza 4) compromiso 5) respeto.

---

DAD (Disciplined Agile Delivery)

Este marco de proceso de Scott Ambler y Mark Lines, en su versión 2.0, es "un marco de segunda generación que pugna por ofrecer una estrategia de extremo a extremo coherente con las prácticas de entrega de soluciones ágiles, con un enfoque ágil híbrido para entrega de soluciones IT basado en personas y orientado al aprendizaje. Cuenta con un ciclo de vida de riesgo-valor, está orientado a objetivos, y tiene en cuenta toda compañía". 

¿Qué valora DAD? Las cuatro prioridades principales son las siguientes: 1) Las personas primero 2) orientado al aprendizaje 3) ágil y 4) híbrido.

Híbrido significa que el DAD también recurre a otras fuentes más tradicionales, como un proceso unificado para la gobernabilidad y la gestión del ciclo de vida. Los proyectos se dividen en tres fases, Incepción, Construcción y Transición. En comparación con Scrum, DAD pone más énfasis en la arquitectura y la reducción del riesgo técnico a través de la designación de un Propietario de Arquitectura. DAD también cambia muchos de los nombres de Scrum, por ejemplo el Scrum Master se llama Líder del Equipo.

DAD 2.0, el marco desarrollado por Scott Ambler y Mark Lines, cómo metodología para IBM Rational

Uno de los puntos débiles de DAD es que, al ser híbrido, habla de fases, y eso puede anclarnos en la mentalidad de proyectos en cascada.

---

SAFe (Scaled Agile Framework)

Como lo describe su creador Dean Leffingwell, SAFe 4.0 es "una base de conocimiento expuesta libre y públicamente de patrones probados para la implementación de software y sistemas de desarrollo Lean-Agile a escala de la compañía. Provee de una guía exhaustiva para trabajar a niveles de la Cartera de la compañía, los Flujos de Valor, los Programas y los Equipos".

A nivel de equipo se acreca mucho a Scrum y Kanban, incluyendo las prácticas de XP. No todos los sprints producen necesariamente un incremento potencialmente desplegable en producción, aunque las entregas ocurren con frecuencia.

A nivel del programa los esfuerzos de los equipos ágiles están alineados e integrados para atender las necesidades de la empresa y sus grupos de interés. SAFe ofrece una buena cantidad de detalles sobre cómo hacer esto.

A nivel de flujo de la valor SAFe da independencia presupuestaria y táctica a las diferentes lineas de negocio de la compañía.

El nivel de la cartera ofrece estrategia y a alineación de objetivos entre los niveles de inversión y los niveles operativos de la organización.

¿Qué valora SAFe? Incorpora el pensamiento Lean, los principios de flujo de desarrollo de productos y los amplios beneficios que el desarrollo ágil (Manifiesto Ágil, Scrum, Kanban, prácticas técnicas XP), pero lo que realmente valora son: 1) Alineación 2) Calidad Built-In 3) Transparencia 4) Ejecución del Programa.

Para empresas que no dividen su estrategia por lineas de negocio y con un flujo de valor de alrededor de 120 personas, SAFe propone una versión del marco colapsada sin el nivel de flujos de valor:

Big picture con la versión 4.0 del framework de Dean Leffingwell colapsado a tres niveles

Para grandes compañías, las más grandes a nivel mundial, con más de un flujo de valor y con más de 120 personas en cada uno, SAFe propone una versión del marco expandida:

Big picture con la versión 4.0 del framework de Dean Leffingwell expandido a cuatro niveles

Después de su implementación exitosa en grandes empresas de todo el mundo, SAFe está recibiendo mucha atención, y como todo lo que se sitúa en el foco tiene que enfrentarse a críticas de los expertos ágiles mas reconocidos en todo el mundo.

Agradecimientos a Peter Stevens por su artículo "Scaling Scrum: SAFe, DAD, or LeSS?" del que he aprendido mucho para escribir este post.

¿Es necesaria la formación en Scrum para iniciar desarrollos con este marco?

¡Absolutamente! Scrum es un marco de trabajo con un proceso muy simple, pero muy difícil de implementar, pone al descubierto los problemas sistémicos de la compañía, por tanto la transformación a Agilidad es un cambio sustancial y la compañía debe de sobrevivir a la resolución de estos. 

La formación es fundamental para que equipos, Propietarios del Producto, interesados y líderes adopten una mentalidad Lean-Agile, comprendan los valores y principios ágiles y cómo su práctica puede mejorar sus productos, junto con la adopción de la perspectiva de la experiencia del cliente. También es importante que entiendan sus nuevas funciones y responsabilidades, y cómo ejecutar las prácticas de Scrum para obtener el máximo valor en todo momento. Muchas veces, aunque todo el mundo tenga experiencia “desarrollando ágil” no se puede asumir que tengan la necesaria, recordemos que para que funcione Scrum y resulte en proyectos exitosos es necesario implementarlo al 100%.

Esta formación también sirve para garantizar que todo el mundo juegue con las mismas reglas y tenga expectativas similares de lo que es Scrum. Por ello lo ideal es que todos los involucrados reciban primero una formación formal tipo certificación, y esta sea reforzada por agentes de cambio internos de la empresa, como un Scrum Master o un coach ágil. Estos pueden ofrecer las singularidades propias de la compañía aprendidas en proyectos de éxito. De ser una empresa que inicia sus primeros pasos en Scrum esta formación debe de darla un trainer experimentado en Scrum, uno que haya invertido tiempo en la comprensión de la organización.

La empresa deberá de considerar la formación continua para asegurar que nuevos interesados entiendan el fundamento y las expectativas de la organización como un todo.

En la cultura de las TI españolas es usual la formula de clientes y consultoras, en la que el cliente contrata recursos o equipos a la consultora para desarrollar un proyecto. Me he encontrado con equipos a los que he aconsejado fervientemente formarse, he visto adopciones de los artefactos de Scrum que pueden aportar algo, pero que no tienen nada que ver con Scrum.

Hay casos en que la consultora ha formado al equipo y estos se han convertido en equipos ganadores, pero también hay casos en que los equipos se encuentran en una situación de abandono. La consultora más tradicional no invierte en formación por considerar que el proyecto es finito en el tiempo, y una vez acabado al fin y al cabo el equipo se desmontará y sus miembros se integrarán en otros equipos. El cliente tampoco invierte en formación a empleados que al fin y al cabo no son suyos.

Ante situaciones como esta invito al equipo a formarse en nuestra plataforma on-line de Scrum Manager con sus cursos gratuitos que siempre refuerzo con la mentalidad ágil del Manifiesto y con algún taller en alguna sala de reuniones al mediodía o al finalizar la jornada laboral.

El autor entrenado a un equipo en un simulación de 3 sprints

¿Qué hacer cuando un equipo ha perdido su conexión con la realidad del proyecto?

Trabajar con Scrum con equipos de consultoras es un tema que trae nuevos retos cada día. Uno de los proyectos en que acompaño al Propietario del Producto y al equipo empezó en las oficinas del cliente final, equipo, Propietario del Producto, negocio y responsables de negocio trabajaron mano a mano habiéndose establecido una muy buena conexión entre todos ellos.

A mitad de proyecto, cuando ya todos los canales de comunicación estuvieron construidos y los artefactos y eventos de Scrum se han convertido en hábito, pensamos que era buena idea deslocalizar al equipo de desarrollo y que hicieran teletrabajo desde sus oficinas. La idea parece que tiene que funcionar, todos los involucrados ya están rodados en Scrum, las reuniones de planificación, retrospectiva y revisión de sprint seguirán siendo en presencial, la reunión diaria no, pero al fin y al cabo es una reunión para el equipo, y este sigue colocalizado.

¿Pero cuál fue la nueva realidad para el equipo? Estando cerca del Propietario del Producto y de los demás interesados, el equipo interactuaba y colaboraba con estos en el día a día, en la sala, en los pasillos... en definitiva viviendo la realidad del proyecto de primera mano; las prioridades, el guiado por valor de negocio... Una vez en sus oficinas se impone otra realidad, una realidad en la que lo que importa es desarrollar las funcionalidades contratadas, y el foco se traslada de "vivir y colaborar" a "cumplir con". Lo que antes era una participación activa en el proyecto de negocio se convierte en el cumplimiento del proyecto de software. Las personas son las mismas, igual de profesionales y eficientes, pero sus decisiones, antes guiadas por una interacción diaria, ya no son tan acertadas.

Otro peligro que acecha es caer en la comunicación por email. Como individuos nos sentimos cómodos con el email y no nos damos ni cuenta de cómo se empobrece la comunicación con este medio. Por ejemplo, las incidencias pueden acabar redirigidas a una bandeja específica que "ya miraremos", con lo que hemos perdido todo contacto con lo que ocurre en el lado de negocio.

Reunión diaria por videoconferencia con un portátil

La solución es muy fácil, incluir en la reunión diaria al Propietario del Producto y hacerla por videoconferencia. Es una de las reuniones core de Scrum en la que se produce microplanificación y conexión entre todos los miembros. Ante la nueva puesta en marcha de la reunión diaria, antes de la primera aún, se pueden oír excusas como "nos falta la infraestructura necesaria" o "no tengo tiempo, ni 10 minutos"... pero pronto, al final de la primera reunión, vienen las alabanzas como "por fin se ha aclarado el tema...", "ya sé por dónde seguir" o "que bien, había un malentendido en...". Hasta había ocurrido que en un fin de semana habían coincidido el equipo desarrollando y desplegando, y el Propietario del Producto probando, ¡y no sabían unos de otros! ¿Alguien no se imagina los beneficios perdidos por no probar mano a mano?

Comentando esta experiencia con David Roncero, uno de los miembros más activos de MadriAgil y con experiencia en coaching, me dio la explicación del porqué está funcionado. La reunión diaria se convirtió en "estaca" o "token" que traslada al equipo a la realidad del proyecto, a como este era antes de la deslocalización, realidad de la que desconectaron probablemente antes de la primera semana de vuelta a sus oficinas.

A los que no podáis aplicar Scrum por las razones que sean, si os pudierais llevar una sola cosa a vuestros proyectos, os animo a llevaros la reunión diaria. Y llevárosla tal cual, 15 minutos y con su guión, "que he hecho, que haré y qué impedimentos tengo".

¿Cuál es el mecanismo de Scrum para absorber los cambios?

En el último curso se produjo un debate sobre el segundo principio del Manifiesto Ágil, que dice:

Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo.
Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.

Mecanismo de absorción de los cambios de Scrum
basado en un gráfico cortesía de Scrum Manager

Finalmente ilustramos en el debate el mecanismo de Scrum para absorber de forma natural el cambio. La herramienta para ello es la pila de producto, esta está viva y cambia cada vez que haya un cambio, debe de reflejar la realidad en cada momento y puede incorporar, modificar o eliminar funcionalidades cada día, cada hora, cada semana, cada mes...

Llegada la reunión de planificación de sprint se congela la pila de producto para que el equipo seleccione el conjunto de funcionalidades mas prioritario que le quepa en el sprint, se basa en las prioridades del Propietario del Producto y en su capacidad, la del equipo, para desarrollar funcionalidades. Estas las desgrana en tareas y obtiene la pila de sprint.

Llegado a este punto se adquieren dos compromisos, el equipo se ha de sentir comprometido a construir la pila de sprint en el tiempo que dura el sprint, y el Propietario del Producto (y otros jefes, directores y gerentes) se comprometen a no cambiar ni intervenir en el sprint. Este último compromiso es necesario para que el equipo pueda llegar a cumplir el objetivo del sprint y lograr tener el incremento esperado. Una de funciones principales de Scrum Master es proteger al equipo durante el sprint velando que nadie externo haga cambios en las funcionalidades comprometidas en la reunión de planificación del sprint.

Acabada la planificación de sprint se descongela la pila de producto para que vuelva a estar viva y absorba todo cambio que se produzca. Así los cambios ocurren entre sprints, es cuando el Propietario del Producto junto con los interesados puede decidir cambiar funcionalidades de la pila de producto porque el valor de negocio haya cambiado o este esté en otras funcionalidades.

Durante el sprint el equipo está focalizado en las tareas de la pila de sprint, cuando termine, para la siguiente planificación de sprint, habrá finalizado al 100% todas la funcionalidades a la vez que habrán acabado y cerrado mentalmente. Para el nuevo sprint puede entrar lo que sea, el equipo empieza con un nuevo sprint, y el mundo puede haber cambiado totalmente desde la planificación anterior.

Es simple y casi trivial. La dificultad para los que se inician en Scrum es aprender a crear funcionalidades (historias de usuario) de tal manera que quepan en un sprint, estas queden cerradas y aporten valor.

Quiero dar mis agradecimientos a Gertrudis que ha hecho posible este debate.

¿Cómo incluir nuevas historias cuando el burndown indica que el sprint está sobreestimado?

Estamos en el segundo sprint, en plena calibración; en el primer sprint el equipo ha entregado mucho menos de lo planificado, y ahora, en el segundo, va avanzado con un burndown como el que se muestra en la siguiente imagen:

Burndown indicando un sprint sobreestimado

Y el equipo, recordemos que está empezando en Agilidad, se plantea la pregunta ¿incluir nuevas historias?, o ¿trabajar directamente en historias del sprint 3?

Ambas soluciones tienen aparentemente consecuencias no deseadas, si incluimos nuevas historias de usuario, la curva ideal del burndown no variará y se mantendrá con los puntos estimados en la planificación de sprint, y puede interpretarse como que muestra información falseada. Por otro lado hacer tareas de un sprint futuro, fuera del mismo e imputando el esfuerzo a ese sprint, también es falsear...

Scrum siempre trata de reflejar la realidad, por tanto si a medio sprint hay espacio para nuevas historias de usuario, y el equipo está de acuerdo de forma unánime, se pueden y deben incorporar estas. El burndown no es un gráfico de reporting, es una herramienta para el equipo con la finalidad de ayudar a tomar decisiones. En el caso de la imagen de arriba el equipo ve que va avanzado con respecto a la curva ideal, y puede tomar la decisión de incorporar una nueva historia en consonancia con el avance. Una vez incorporada una nueva historia, el burndown queda como la siguiente imagen:

Burndown en la que el equipo ha vuelto a la curva
ideal, que es su guía, incorporando una nueva historia

Si nos fijamos en ambos burndowns veremos que son idénticos, excepto el último segmento que muestra claramente que no se quemado trabajo en el último día, que no ha habido avance. ¿Cómo interpretar esto? ¿Qué ha ocurrido realmente? 

En el siguiente gráfico se muestra lo que ha pasado realmente:

El trabajo quemado y el esfuerzo incorporado se suman

• A es el segmento de trabajo quemado
• B representa la inclusión de nuevo esfuerzo, que se suma a A y se anula

Lo que se suele hacer para hacer visible lo que ha pasado es incluir la curva C, en marrón, que indica el tamaño absoluto de la pila de sprint en todo momento. Esta hace visible que a medio sprint hemos incorporado una nueva historia de usuario.

Dado que el gráfico burndown ha de aportar para la toma de decisiones del equipo, es mejor hacer visible la inclusión de esfuerzo extra el día anterior a la inclusión. Así queda visible el trabajo quemado en el último día, que da idea del avance reciente y que es más relevante para una posible nueva toma de decisión. Finalmente el burndown quedaría como en la siguiente imagen:

Burndown final después de la inclusión una nueva historia

Software como Redmine tiene un cron que reprocesa automáticamente los burndowns transformando burndowns como el de la segunda imagen a uno como este último.

Una vez terminado el sprint se registran velocidad estimada en la planificación y velocidad del sprint para ayudar al equipo a afinar la estimación de velocidad para próximos sprints. El burndown simplemente se archiva en la papelera, como herramienta ha perdido toda utilidad y con ello el aparente falseado simplemente no ha lugar.

A quien le interese profundizar en el gráfico burndown le invito a leer el artículo de Dusan Kocurek "Understanding the Scrum Burndown Chart".