We like a Spike Solution to take no more than a couple of days, and a half day is ideal
/ Nos gusta que un Spike Solution que no lleve más de un par de días, medio día es ideal.
— Ron Jeffries
Cada vez que voy a algún sitio, alguien me pide que le eche una mano con mejorar su gestión Ágil, si me toca opinar de un Backlog, un clásico es hablar de los Spikes, típicamente, mal usados, mal interpretados, mal gestionados. En mi cuenta personal 8 de cada 10 Spikes están cargados de Lado Oscuro, desperdicio y mala aplicación.
Hay prácticas, ideas, términos, aparentemente simples… que luego dan para debates tremendamente largos y profundos. Y que son puertas sugerentes, pero que con facilidad somos capaces de transformarlas en portales que dan… al Lado Oscuro. Una de esas prácticas, que no sé por qué ahora (y mira que tendrá sus 20 años, como poco) está de moda, son los Spikes.
Hace más de 5 años, en 2013, ya te hablé de los Spikes por aquí, en un post extrañamente corto para lo que se acostumbra. Traté demasiado leve y brevemente un tema que hoy está dando para juegos peligrosos, desperdicios disfrazados de Agilidad y prácticas típicas de la era Cascada, pero bajo un nombre molón y que suena Ágil.
Los orígenes de la idea de Spike vienen (como tantas otras prácticas Ágiles) de eXtreme Programming (no de Scrum), el framework Ágil con el que muchos nos iniciamos en esto de la agilidad (la ppt, la presentación, de mi primer proyecto Agil, ojo, del 2001).
Si llevas poco tiempo en esto de la Agilidad y te pierdes con los nombres, frameworks, etc., te puede venir bien ver este vídeo.
Quizá por venir de eXtreme Programming los Spikes han tardado más en ponerse de moda, eXtreme Programming, que en mi opinión es más rico que Scrum, siempre se ha mantenido fuera del «nuevo gran público Ágil», en parte porque la palabra «programming» (y extreme) asusta a muchos y en parte porque se ha mantenido más limpia respecto al, en muchas partes Oscuro, mundo de la certificación (de Scrum hay decenas de certificaciones, de eXtreme Programming no, por suerte)
En sus orígenes, los Spikes eran una tarea, que llevándolo a Scrum hoy estaría en el Backlog, que no concluía en un producto potencialmente entregable o incremento, tarea que se usaban para investigar, cuando no se tenía claro cómo afrontar una historia de usuario. Pero (ojo, que aquí viene el lío) seguían siendo y concluyendo en un programa, en software (no en papel, no en un pdf de análisis):
– «What is the simplest thing we can program that will convince us we are on the right track? Kent dubbed this a Spike» /
«¿Qué es lo más simple que podemos programar que nos convenza de que estamos en el camino correcto? Kent [Beck] apodó a esto Spike»
Recuerda… «lo más simple que podemos programar» que nos ayude a entender. Puedes leer lo anterior y más sobre el origen del Spike aquí.
¿Dónde está el peligro de los Spikes?
En que sea un nuevo nombre molón para hacer papeles y pdfs, para escribir «requisitos», escribir «análisis», escribir «diseños». Y no para hacer una tarea de programación (o, si tu producto no requiere programación, algo muy cercano a producto final, ya sabes, Working Software o Working Solutions).
Yo aún no sé como hay gente ayudado a otros a ser Ágiles y no les advierten, incluso les recomiendan, sobre cosas como esta de los Spikes del Lado Oscuro.
Alta probabilidad de desperdicio «en vena» si, además, no se les da un time-box (un máximo de tiempo), incluso he visto Spikes planificados para… DURAR MÁS DE UN SPRINT. E, incluso, para los que usan la idea de Velocidad (medida en, por ejemplo, Puntos Historia), y para que terminar de poneros mal cuerpo y que os siente tan mal que os impida disfrutar de la siguiente comida… Spikes que suman… VELOCIDAD.
Bueno, que se me extiende el post, amig@… cuídate de los Spikes del Lado Oscuro.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Jejejeje Leo tus POST y me siento identificado, pero además siento la emoción y sentimiento con que los escribes. Pues bien, es común ver equipos que hacen un mal uso de los Spikes y como dices que incluso el esfuerzo usado para el mismo, aporta a la velocidad del equipo, pero creo que todas estas situaciones son aceptables si un equipo apenas está emergiendo, adaptando y adaptándose a estos marcos de trabajo, pero si el equipo ya es maduro y de hecho se encuentra liderado por alguien con experiencia y entendido en la materia, me parece que no sería aceptable.
Pero ahora mismo estamos en la moda de los «Gurús» para todo, incluso que enseñan lo que nunca han aplicado.
Hola Javier,
No sé si he entendido bien la manera «correcta» de gestionar los spikes.
¿Pueden convivir en un sprint con tareas derivadas de las historias?
Al no deberse «pesar» con puntos de historia ni van a quemar puntos del sprint ¿cómo establecemos un tiempo máximo aceptable para estas tareas?
Aprovecho para agradacerte enormemente el trabajo que realizas en tu blog. Es muy enriquecedor.
Un saludo
Jorge.
Nosotros les ponemos siempre time-box, que resultado esperamos y que terminen en un mini mvp