Te equivocas si piensas que Scrum debe aplicarse al pie de la letra, sea cual sea la situación.
En realidad, tienes total libertad para embellecerlo con múltiples prácticas personalizadas… siempre y cuando se encuentren dentro de los límites indicados en la Guía. De hecho, en algunos casos, una aplicación demasiado académica o austera de Scrum puede ralentizar o entorpecer el trabajo de los equipos. ¿Cómo nos damos cuenta de esto? Por lo general, los síntomas son claros:
- Ceremonias experimentadas como tareas
- Intentos de negociar la frecuencia de las retrospectivas (como recordatorio, en Scrum son inquebrantables…)
- Los stakeholders no están motivados por el Sprint Review (”… Estoy bajo el agua, ¡llegaré al próximo!…”)
- El nivel de motivación es mínimo y todos se quejan
- Etc.
En resumen, la atmósfera está en su punto más bajo. ¿Cómo se puede corregir esta situación que no es propicia para la generación de valor?
¿La respuesta? Depende…
Si además de los puntos mencionados anteriormente: el equipo tiene dificultades para formular un Sprint Goal claro en cada Sprint Planning, cada desarrollador web trabaja sobre objetivos sin vínculos con los de sus colegas, el increment parece un lote inconsistente de diferentes “historias”, o si el sprint se interrumpe constantemente al agregar tareas que deberían asignarse a otro equipo…
Así que tal vez sea hora de considerar cambiar de marco (¿Kanban, por ejemplo?)…
O no… Tal vez Scrum está bien, pero se usa mal o se malinterpreta (o ambos).
Algunas preguntas que deben hacerse:
- ¿Todos están haciendo lo necesario para asegurarse de que todo salga bien?
- ¿Los gerentes están trabajando activamente para eliminar los obstáculos que encuentran los equipos?
- ¿El Scrum Master escucha bien al equipo?
- ¿Los valores y pilares de Scrum se reflejan en las decisiones que se toman?
- ¿No son los eventos de Scrum demasiado largos y agotadores? (Aunque el ambiente sea de compañerismo, las retrospectivas de 1h30 al final de la semana desgastan mucho)
- ¿Son los eventos demasiado repetitivos? ¿Quién no sufriría un derrame cerebral en su quinta retrospectiva consecutiva de “estrellas de mar” o speed boat?
La lista puede seguir y seguir… Afortunadamente, existen muchas astucias que le permiten adaptar Scrum sin traicionar sus fundamentos. Algunas ideas :
- Lo que haces durante tus retrospectivas La energía que le pones, el tiempo que le dedicas, el lugar donde te encuentras, lo que obtienes de ello (beneficios, observaciones), el ambiente general…
- La cadencia de los Sprints ¿Un mes, dos semanas, una semana? Es fijo, pero sujeto a revisión de acuerdo a sus necesidades de inspección y adaptación. Cuanto más impredecible sea el contexto (alto riesgo), más tenderemos a experimentar con iteraciones cortas.
- Modificaciones de equipo Los desarrolladores web (en sentido amplio) no son solo engranajes de la maquinaria. Hay que tener en cuenta, hasta cierto punto, las afinidades de uno u otro con sus compañeros, sus tecnologías…
- Prácticas diarias de Scrum Hay otras cosas que hacer además de las tres preguntas soporíferas habituales (¿Qué hiciste ayer? ¿Qué harás hoy? ¿Hay algún impedimento?), que como era de esperar, desaparecieron de la guía Scrum 2020.
- Etc.
También te equivocas si crees que el marco
Scrum debe ser sistemáticamente sujeto a ajustes y alojamientos.
Veo allí una especie de fantasía de diversidad y también una cierta forma de esnobismo. Como todos somos diferentes, y todos trabajamos en contextos distintos (cada organización tiene sus especificidades), cada uno debería tener también su propio “Scrum”. Todo el mundo debería tener su “Scrum casero”, con unas cualidades ciertamente muy superiores al original, ya que, al fin y al cabo, “es apto para nuestra organización”. Así que hicimos el “hecho a la medida” y ¿qué podría ser mejor que eso?
Como si este marco no fuera ya suficientemente permisivo, como si no diera suficiente margen para organizarse “a la medida”. Porque obviamente no es casualidad que la estructura del marco sea básicamente tan ligera…
Antes de continuar, permíteme señalar que: eres libre de modificar la estructura de Scrum como mejor te parezca dejando los rieles definidos en la guía. Probablemente obtendrás grandes beneficios de él, pero como se especifica en esta misma guía… ya no es Scrum. Entonces será mejor adaptar su terminología al nuevo modelo/marco que ha creado para evitar confusiones.
Algunos ejemplos de chapuza extraño, practicados bajo el estandarte de Scrum:
- Retrospectivas “a la carta” Despues de la VOD (Video On Demand), tienen el FOD (Framework On Demand). Elija sus eventos del menú, recíbalo el día y la hora de su elección… Una idea que puede provocar un mal clima: mucha más presión para expresarse, ya que es necesario formular una petición explícita. Si la misma persona lo reclama sistemáticamente… corre el riesgo de ser visto como una oveja negra…
- Colocar la retrospectiva del Sprint 1 después de la planificación del Sprint 2 Es original, divertido y no confundirá a nadie, ¿verdad? ¿Por qué hacerlo simple cuando puedes hacerlo complicado?
- Product Owners que participan activamente en Daily Scrum (respondiendo preguntas de los desarrolladores) Un punto muy controvertido. Algunos, como yo, argumentan obstinadamente que esto es un error. Otros creen que aporta su parte de los beneficios a los desarrolladores, ya que el PO (Product Owner) está ahí para responder a sus preguntas si es necesario. Mi opinión personal es que en realidad no aporta mucho, porque es un evento reservado para los desarrolladores web y que el PO está de todos modos a su disposición para responder preguntas fuera del Daily Scrum. Está contraindicado por la guía de todos modos a menos que el OP también es desarrollador web: “The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.” (Scrum Guide 2020)
- Sprints de consolidación (Hardening Sprints)… … En el que los equipos corrigen errores y abordan (demasiado tarde) la deuda técnica. En este caso, ya no es “raro”, está “formalmente prohibido” por la guía. La excelencia técnica emerge sobre los Sprints, no es un interruptor que encendemos en caso de pánico o ante una “gran presentación/producción/demostración”…
Finalmente, si no juegas con la estructura original de Scrum, ¿qué queda? Scrum, aplicado con normalidad y, si es posible, con eficacia. Habitualmente, la mitad de los lectores ya se han ahogado con la mera idea de aplicar Scrum tal y como es y sin embargo… Hay muchos artículos en internet anunciando con aire victorioso que tal o cual organización ha secuestrado Scrum y que la magia por fin ha operado en equipos. Sin embargo, existen otros tantos artículos en la web que denuncian casos de “Zombie Scrum” y otras desviaciones derivadas de un mal uso del framework.
Al igual que modificar Scrum sigue siendo una opción que se elige bajo su propio riesgo. El marco ha sido descrito durante mucho tiempo como “fácil de entender pero difícil de dominar” (en la versión 2017 de la Guía), una advertencia que dice mucho. Difícil para algunos resistir la tentación de cambiar la estructura del marco cuando los problemas comienzan a acumularse…
¿Finalmente, qué hacemos?
Para poder decidir sobre una situación particular, será necesario poder observar con precisión el contexto en el que se implementa el marco. ¿Cómo se implementa? Comprobar si se aplican los valores (apertura, valentía, enfoque, respeto, compromiso), ver si se respetan los pilares (transparencia, inspección, adaptación), ver cómo lo viven las personas que lo practican, etc. Si después de un período de experimentación bien definido, la adopción de Scrum está estancada por todos lados, y si se ha intentado mucho dentro del marco establecido del framework, entonces tal vez sea hora de seguir adelante… pero los peligros que se encuentran con frecuencia en su adopción no deben conducir sistemáticamente a arreglos cuestionables…
Finalmente, para los más atrevidos, no podía terminar sin mencionar el excelente artículo de Jeff Sutherland, Scott Downey et Björn Granvik: “Shock Therapy, A bootstrap for Hyper-Productive Scrum” (2009), en el que analizan los excepcionales resultados obtenidos con una aplicación “militar” del framework durante un breve período de lanzamiento (tras el cual el equipo recupera progresivamente su autonomía y libertad de decisión).
