¿Qué técnica utilizar para estimar epics y temas?

Existen varias técnicas de estimación relativa, la más extendida es el planning poker basado en la serie de Fibonacci. Otra técnica común está basada en tallas de camisa: XS, S, M, L y XL. Está técnica tiene la ventaja de ser puramente relativa, no es posible traducir sus valores a tiempo, a jornadas u horas. Tiene dos desventajas frente a la serie de Fibonacci, sus valores no son aditivos, sería complicado medir la velocidad de un sprint en base a tallas de camisa, y la relación entre sus valores seguramente no significa lo mismo para los distintos miembros de un equipo.

Baraja para la estimación por tallas de camisa - cortesía de BEEVA

¡Nosotros utilizamos ambas técnicas! Dentro del ámbito de las historias de usuario utilizamos la serie de Fibonacci y para los epics grandes y los temas, las tallas de camisa. Nos hemos planteado utilizar la serie Cohn, derivada de la serie de Fibonacci, que sustituye el 21 por 20 e incluye el 40 y el 100, para historias, epics y temas, pero esos últimos dos valores, aunque muy grandes, dan idea de cierta precisión inexistente. Realmente los elementos más grandes de la pila de producto son muy vagos para estimar y el utilizar las tallas de camisa nos da algo como una intuición más que una estimación, con un gran grado de incertidumbre amplio acorde a epics y temas.

Así tenemos una pila de producto con elementos estimados con dos técnicas, pero coherente con Agilidad. Los elementos de la parte cercana de la pila están detallados, incluida la estimación, y los elementos más lejanos poco granulados, con una estimación más vaga y amplia. En la reunión de refinamiento, cuando epics se dividen en historias de usuario, es cuando reestimanos con la técnica correspondiente.

El Propietario del Producto se basa en el resultado de ambas técnica para priorizar la pila de producto, tiene valores más detallados de lo que tiene frente a sí y necesita estar más perfilado, y tiene valores con detalle suficiente para elementos los lejanos y poco prioritarios.

¿La respuesta al cambio por encima del seguimiento de un plan?

Del meetup de Madriagil
Agile Manifesto: Back to Basics

Scrum es un marco de desarrollo que se creó para dar respuesta a entornos inestables con un alto grado de variación, entornos que tienen como factor inherente el cambio y la evolución rápida y continua. Este cuarto valor del Manifiesto Ágil muestra que resulta mucho más valiosa la capacidad de respuesta al cambio que la de seguimiento y aseguramiento de planes preestablecidos. Los principales valores de la gestión ágil son la inspección y la adaptación, diferentes a los de la gestión de proyectos predicitiva donde tienen importancia la planificación y el control para evitar desviaciones sobre el plan.

De ahí nace uno de los mitos más extendidos sobre Scrum, hay la creencia de que en Agilidad no se planifica... nada más lejos de la realidad, ¡en Agilidad se planifica a cinco niveles!

El malentendido viene del hecho de que la Agilidad no le da importancia a los planes, pero sí, y mucha, a la al acto de planificar y la replanificación continua. Con cada cambio, con cada desgranado y detallado de las historias de usuario, con cada medición de la velocidad de los equipos, Scrum prescribe replanificar. El modo en que Scrum absorbe la variación y por tanto responde al cambio, hasta deberíamos decir "abraza al cambio", es aceptar el cambio y replanificar en cada nivel el siguiente paso correspondiente. A nivel de reunión diaria se microreplanifica día a día, a nivel de planificación de sprint se planifica el próximo sprint, a nivel de release se replanifica la próxima release, a nivel de hoja de ruta se ajusta sus etapas y finalmente a nivel de visión puede ser que se ajuste esta, aunque este caso es muy poco frecuente y solo ocurre con cambios sustanciales.

Alinearse con este valor requiere una mente abierta para recibir el cambio cultural que implica. Los planes, como herramienta establecida, hacen sentirnos seguros, pero ponen el foco fuera de la realidad. Cuando hemos logrado pintar nuestro plan en forma de un un gantt gigantesco, hay equipos que lo imprimen y decoran una pared con él y los irradia continuamente, luego creemos que cuando no se cumple el plan, el problema tiene que estar en la realidad.

En nuestra vida personal absorbemos fácilmente las cosas que se cruzan en nuestro camino, nos adaptamos y seguimos. Por ejemplo si viajamos de Madrid a Zaragoza y hemos planificado un viaje de 3 horas, si resulta que hay una tormenta a medio camino, bajamos de 100 km/h a 60 km/h y aceptamos sin más que el viaje serán 4 horas. Ese comportamiento natural no lo aplicamos igual en nuestra vida profesional, miramos el plan y nos aferramos a él intentando que se cumpla a toda costa. Por tanto el problema a resolver para adoptar la respuesta al cambio cuando aún no somos ágiles, está en nosotros, en superar nuestros miedos, inseguridades y incertidumbres.

¿La colaboración con el cliente por encima de la negociación contractual?

Del meetup de Madriagil
Agile Manifesto: Back to Basics

Este tercer valor del Manifiesto Ágil es tan evidente como algunas veces lejano a la realidad en ciertos proyectos de TI.

Un contrato es una formalidad que establece líneas divisorias entre responsabilidades y fija los referentes para cuando las cosas van mal, y como tal no aporta valor alguno al producto. En un proyecto con metodología predictiva, con una sola entrega a final del proyecto y en el que el cliente no ha participado durante el mismo, la negociación contractual suele ser inevitable. Ocurre hacia el final de proyecto, cuando la fecha de entrega aprieta, los equipos del proveedor hacen jornadas maratonianas a base de "tracción sangre" para llegar a mínimos, con el único objetivo de cumplir con el contrato. Cuando lo esperado no concuerda con lo construido, cuando ya es tarde para tomar medidas para reconducir el proyecto, es entonces cuando cliente y proveedor entran en negociación contractual.

En un proyecto ágil el cliente es un miembro más del equipo, está comprometido y se integra y colabora con el proyecto. Hoy en día la informática es algo necesario para toda compañía, está presente en las estrategias empresariales, por tanto lo que realmente necesitan las compañías son partners, no sólo proveedores, partners que construyan, liderados por el cliente, las herramientas que harán funcionar su core-business.

Por la naturaleza de entrega frecuente hay una constante sensación de avance por parte del cliente y del partner, y, especialmente de conducción del rumbo por parte del cliente. La transparencia, la entrega frecuente, sprints que dan los resultados esperados, generan confianza entre ambos, confianza que refuerza aún más la colaboración. Un proyecto ágil pone sobre la mesa los problemas y trae los riesgos al principio de proyecto, por tanto en un momento que permite tomar medidas de reconducción en una fase temprana y dentro de un marco de colaboración. La negociación contractual queda reducida a casos extremos y puntuales.

Para terminar, mencionar que los modelos de contrato de proyecto cerrado no encajan con la agilidad, es objetivo de un contrato ágil es establecer las bases para la colaboración.

¿El software que funciona por encima de la documentación exhaustiva?

Del meetup de Madriagil
Agile Manifesto: Back to Basics

Uno de los mitos sobre Scrum es "no hace falta documentar...". Los documentos son importantes ya que permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero ¿son más importantes que los productos que funcionan? y, ¿aportan valor al producto? o ¿quizá solo aporte la documentación justa y al 100% necesaria?

Tal como dice el segundo valor del Manifiesto Ágil, los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con prototipos, o el feedback estimulante y enriquecedor sobre partes elaboradas del producto que genera ideas imposibles de concebir en un primer momento.

Desde la perspectiva ágil los documentos deben ser cortos y centrarse en lo esencial, y deben de constituir la documentación necesaria que debe de ser mantenible, compartida y generada por todos mediante un flujo solapado con las demás fases de inicio a final del proyecto. Por tanto esta se escribe a lo largo de todo el proyecto, es viva y sólo recoge aquello que es de utilidad para alguien.

No olvidemos que la documentación (diseño, especificación técnica de un sistema) no es más que un resultado intermedio, y por tanto, siempre que sea posible, debe preferirse y reducir al mínimo indispensable el uso de documentación, ya que genera trabajo que no aporta un valor directo al producto y al cliente.

Un ejercicio interesante para detectar qué documentación de nuestra empresa aporta valor es preguntar al equipo completo (desde negocio al equipo técnico, analistas, usuarios...) quién escribe algún documento, para luego preguntar por quienes son los lectores de cada uno de esos documentos. Si descubrimos documentos de "solo escritura" habremos dado con posible desperdicio y deberemos de preguntarnos si no es preferible invertir el tiempo en el producto que estamos construyendo en vez de escribirlos.

Como anécdota contar que un colaborador mío incluyó la receta de la tortilla de patatas en la documentación de usuario para averiguar si alguien se daría cuenta. 2 años después un becario al que le dieron a leer un montón de documentos en su primer día, descubrió la receta durante la primera semana, jajaja.

Otro punto crítico se produce cuando la empresa y los equipos se comunican a través de documentos, cuando además de perder la riqueza que da la interacción con el producto, los documentos se convierten en barreras entre personas y departamentos. Un documento escrito es un dibujo incompleto de las ideas de quién lo escribe, y cuando lo lee un lector, este crea otra abstracción que está a dos pasos de distancia de lo que se escribió originalmente. No es sorprendente que de esta manera se generen malentendidos, haya peloteos que van y vienen (muy comunes en la comunicación por email) y se acaben empleando los documentos de forma defensiva.

Mi agradecimientos a Fernando por la receta de tortilla de patatas :-P

¿A los individuos y su interacción por encima de los procesos y las herramientas?

Hay un par de afirmaciones que expuestas en clase todo el mundo está de acuerdo:

"El 90% de los proyectos fallan por la falta de comunicación"

"El 90% de los proyectos que tienen éxito lo tienen por las personas que intervienen"

Del meetup de Madriagil
Agile Manifesto: Back to Basics

Este es el primer valor del Manifiesto Ágil. La industria del software es una industria de talento extremo que se basa en trabajadores de conocimiento, en personas que con sus diferencias hacen equipos ganadores, innovadores y creativos, que con su conocimiento tácito hacen posible lo que ningún proceso o herramienta puede hacer. Si, los procesos y herramientas son importantes, pero lo único que de verdad lo hace posible son las personas y las interacciones entre ellas.

Los procesos, como el marco de Scrum, deben ser una ayuda y un soporte para guiar el trabajo, un elemento alineante, y deben adaptarse a la organización, a los equipos y a las personas, y no al revés. Por ello Agilidad habla de prácticas en lugar de procesos, de procedimientos de ayuda a las personas, que son quienes aportan con su conocimiento tácito, el “saber hacer”, clave para lograr el resultado, marcando así muy claramente los límites del trabajo de persona/práctica.

Pensar que los procesos son más importantes que las personas y que se puede conseguir resultados extraordinarios con personas mediocres, hace que las personas con talento queden desmotivadas o abandonen la empresa. Incluso en los años 90, con la teoría de producción basada en procesos y la reingeniería de procesos en auge, estas deben gran parte de su valor al conocimiento y al talento de las personas que las realizaban.

¿Cómo preparar la reunión de revisión de sprint?

Preparando la sala para la revisión de sprint

He vivido unas cuantas reuniones de revisión de sprint y algunas han ido mal por diversas razones. A veces el problema fue ajeno al equipo y les creó una profunda frustración e impotencia, hasta he visto lágrimas. Durante todo el sprint, el software en construcción ha funcionado perfectamente y, el día de la revisión todo falló. Un análisis posterior reveló que alguien instaló una librería equivocada en el servidor de integración, justo antes de la reunión... Por tanto una pequeña revisión y preparación anterior maximizan las garantías de éxito de la reunión.

La preparación de la reunión no debe de consumir más de 30 minutos a 1 hora de un miembro del equipo:

• Repasar que todas las historias de la pila de sprint estén cumplan con los criterios de aceptación y hecho. Si hubiera alguna que no se podrá entregar hay que preparar una explicación clara, corta y concisa, que aconsejo se exponga al principio de la reunión, ya que así colocamos las expectativas de todos en la realidad en el primer momento.
• Preparar un pequeño guión con los pasos de la demo.
• Preparar una pequeña batería de pruebas básica para la demo.
• Preparar y comprobar que todo funciona en el ordenador en el que se va a efectuar la demo, quizá desplazar un ordenador del equipo de desarrollo a la sala de la reunión.
• Preparar la sala y que todo lo necesario (suficientes sillas, pantalla o proyector visible desde toda la sala, scrumboard, rotafolios, rotuladores, post-its...) esté disponible.
• Efectuar una prueba de humo de las funcionalidades que se van a mostrar.
• Si es posible avisar a sistemas para que durante la reunión no se despliegue nada en el entorno de la demo.

Una vez todo preparado os sentiréis más seguros y eso se irradia y todos lo sentirán. Quién haya preparado la reunión será quién exponga como ha ido el sprint (qué fue bien, qué problemas hubo y como se resolvieron) y mostrará el incremento de software. Es importante dirigirse a los interesados de negocio como audiencia principal, dar la bienvenida a todo feedback de estos y estar abierto a cualquier duda o pregunta.

¡Os deseo mucho éxito!

¿Cómo priorizar una pila de producto de la forma más completa posible?

Una herramienta que puede ayudar al Propietario del Producto a priorizar la pila de producto de forma adecuada es el cálculo del ROI (Return of Investment) o retorno de la inversión:

• Valor de negocio: el valor relativo del elemento para negocio o el cliente.
• Tamaño: estimación en puntos de historia del esfuerzo necesario teniendo en cuenta complejidad y tamaño.

El ROI aplicado de forma descendente resulta en una excelente guía para priorizar la pila, cuanto más alto el retorno de inversión tanto más alta es la prioridad del elemento.

Recientemente asistí a un curso de SAFe® con Dean Leffingwell en el que recomendó la técnica de priorización lean de Don Reinersten WSJF (Weighted Shortest Job First). Esta técnica esta basada en la economía de flujo de desarrollo de productos que calcula dividiendo el coste de demora por la duración.

Lo interesante del coste de demora es que incluso las historias técnicas, que intrínsecamente no tienen valor de negocio, lo tienen. El coste de demora representa el valor que no obtenemos por no construir determinada historia, y en caso de una historia técnica se puede no obtener el valor de negocio de las historias de usuario que consumen esta última.

Dado que la duración es imposible de estimar el coste de demora utiliza el tamaño del elemento como sustituto. Al coste de demora se considera que contribuyen los siguientes tres elementos:

• Valor de negocio
• Criticidad en el tiempo: Esta medida se ocupa de la "necesidad" de la entrega del elemento en una escala de tiempo, viene asociado con la caída de valor con el tiempo. A más "necesidad" de entrega más alto será el valor.
• Reducción del riesgo y valor de oportunidad: Esta medida da un valor relativo a la eliminación de uno o varios riesgos o, un valor por el potencial de nuevas oportunidades de negocio que puede aportar el elemento.

La técnica de priorización WSJF consiste en aplicar los siguientes pasos a la pila de producto:

Ejemplo de una pila de producto priorizada por WSJF

• La técnica estima las funcionalidades / historias de usuario / epics entre si de forma relativa
• La escala de unidades es la serie de Fibonacci: 1, 2, 3, 5, 8, 13, 21
• Se rellena la lista columna por columna
• Se pone un 1 en el elemento con el valor más pequeño, tiene que haber un 1 en cada columna
• Se rellena el resto de elementos de la columna con estimación relativa respecto a la del 1
• Hecha la última columna se calcula el WSJF y se ordena de mayor a menor
• El elemento con mayor prioridad es el de WSFJ más alto

Ejercicio sobre una diapositiva del curso de Leading SAFe :-)

¿Kanban se puede utilizar con Scrum?

Scrum y Kanban son marcos de desarrollo ágiles que adoptan una estrategia de desarrollo incremental, basados en equipos autoorganizados y el solapamiento de las fases del desarrollo. La diferencia entre ambos marcos es que Scrum construye con incremento iterativo a través de sus sprints y reuniones periódicas, y Kanban con incremento continuo a través de la gestión del flujo de trabajo en base a un sistema de arrastre con restricciones al trabajo en curso (WIP).

Kanban y Scrum, incremento continuo e iterativo, cortesía de Scrum Manager

Una gran diferencia es que Kanban se puede implementar en una compañía o departamento de forma evolutiva y Scrum siempre se implementa de forma disruptiva, todo el marco se aplica de un día para otro, por tanto puede parecer de entrada que Scrum y Kanban no se pueden utilizar a la vez.

Tablero Kanban o scrumboard de equipo Scrum

Lo que hace que un equipo construya de forma incremental e iterativa es el marco de Scrum, se planifica el sprint al principio y se revisa al final el incremento obtenido. Durante el sprint el equipo utiliza un scrumboard o tablero Kanban para hacer visible su trabajo, ver el avance de su trabajo e irradiar información. Dentro del sprint la construcción es con flujo continuo de tareas, no se espera a final del sprint para poner las tareas en "hecho", flujo que se ve puede  ver representado en forma de curva descendente en el gráfico burndown. Podríamos concluir que Kanban no utiliza sprints pero se puede utilizar dentro de un sprint. Hasta se podría poner límites WIP en el scrumboard, propios de Kanban, pero no se suele hacer ya que el propio timebox de 2 a 4 semanas del sprint resulta en un límite WIP que se establece con el contenido de la pila de sprint.

¿Cómo conocer el grado de madurez en Scrum de un equipo nuevo?

Recientemente tuve la necesidad de evaluar el grado de madurez de un equipo nuevo que se iba a incorporar para trabajar en Scrum. Me imaginé que preguntar directamente no serviría de mucho, reconocerán que no están certificados pero dirán que tienen experiencia en Scrum. Tenía claro que lo que tenía que observar es la confianza entre los miembros del equipo, ver cómo interactúan entre ellos y la seguridad con que se muestran como equipo, y para eso la mejor forma sería hacerlos colaborar en alguna dinámica frente a un tablero.

Así que idee una variante del tablero de acuerdos de trabajo y maté dos pájaros de un tiro. En este tipo de acuerdo se les pide a los participantes que escriban lo que no les gustaría que pasase, y para este tablero que idee debían de escribir lo que no les gustaría que pasase durante el proyecto relacionado con el Scrum Master (SM), el Propietario del Producto (PO) y el equipo (TEAM). Dado que lo que escribirían iría directamente relacionado con los roles de Scrum, obtendría de paso la madurez del equipo.

Resultado de un equipo que ha trabajado bajo scrumbut, no han vivido
problemas con el Scrum Master pero si con el Propietario del Producto

Fue una buena experiencia, me encontré con un equipo muy bien integrado y conocedor de los procesos de Scrum. Como podemos ver en la imagen superior hay un claro desequilibro, en la parte de Scrum Master prácticamente no hay post-its, mientras que en la del Propietario del Producto y la del equipo hay muchos, incluida la zona de separación, que en este caso representa la intersección de ambos.

Me llamó la atención que una de sus mayores preocupaciones fuera la interferencia en los sprints, la adición o modificación desde fuera del equipo de la pila de sprint. Con esto supe que el equipo sabe de Scrum, y también cual es su realidad. Me extrañó que la columna del Scrum Master no tuviera apenas post-its, pero todo encajó cuando conocí más a fondo la metodología de la consultora del equipo, habían incorporado los procesos de Scrum en su metodología tradicional. Básicamente no hay post-its en la columna del Scrum Master porque no hay gestión de personas, por tanto me encontré ante una situación de claro scrumbut. Fuere como fuere es un buen punto de partida, es un equipo integrado y conocedor de los procesos de Scrum, el hacerlos evolucionar ya solo depende de este Scrum Master.  :-)