“Hacemos Scrum, pero…” Los ScrumBut más comunes

En la actualidad Scrum se constituye en el framework más popular para el desarrollo, mantenimiento y entrega de productos complejos, es por ellos que las empresas han decidido adoptarlo, aunque en muchos casos casos con muchos problemas. Las dificultades por las que atraviesan, en la mayoría de las ocasiones se deben a los ScrumBut.

¿Qué son los ScrumBut?

ScrumBut hace referencia a las razones por las cuales los equipos no pueden sacar el máximo provecho de Scrum para resolver sus problemas y obtener todos los beneficios del desarrollo de productos con este framework. Cada rol de Scrum, artefacto, regla, y timebox se ha diseñado para proporcionar los beneficios descritos, y abordar problemas recurrentes predecibles. Normalmente los ScrumButs implican que Scrum ha puesto de manifiesto una deficiencia que está contribuyendo al problema, pero es demasiado difícil de solucionar. Un ScrumBut conserva el problema al modificar Scrum para que la deficiencia no sea visible y no se considere como problema del equipo.

Por lo tanto una situación de ScrumBut es afirmar que se está haciendo Scrum PERO tienen lo que sienten es una buena excusa para no usar Scrum en su totalidad o como fue diseñado para usarse.

Un ScrumBut tiene la siguiente sintaxis:

(ScrumBut) (Razón) (Solución momentánea)

Ejemplo:

Hacemos Scrum, pero los dailys no son eficaces, por lo que sólo las hacemos cuando sean necesarias.

Scrumbut que suceden con frecuencia

A continuación damos a conocer ejemplos que se pueden apreciar de manera común en las organizaciones:

  • Hacemos Scrum, pero nuestros equipos no son multifuncionales ya que las personas que hacen control de calidad se encuentran en otro equipo, por lo que al final del sprint se entregan incrementos sin las pruebas correspondientes.
  • Hacemos Scrum, pero los dailys se usan para solicitar estado del avance, por lo que decidimos suspenderlos y solicitamos al equipo que envíe su estado al final de la jornada.
  • Hacemos Scrum, pero los dailys duran demasiado, por lo que se los agendo para el final del día y fuera de horario de trabajo.
  • Hacemos Scrum, pero no conocemos con certeza el objetivo a cumplir durante el sprint, por lo que la duración de nuestros sprints son variables.
  • Hacemos Scrum, pero siempre se debe lograr lo acordado en el sprint Planning, por lo que nos saltamos la DoD cuando sea necesario.
  • Hacemos Scrum, pero los directivos quieren saber con precisión los resultados del sprint Planning, por lo que la estimación de los ítems se lo hace en horas.
  • Hacemos Scrum, pero los managers nos exigen que seamos predictivos y no tan abiertos al cambio, por lo que realizamos planificaciones de varios sprint por adelantado.
  • Hacemos Scrum, pero es obligatorio que se cumpla todo lo acordado en el sprint Planning, por lo que el equipo tiene que trabajar, si es necesario horas extras, para cumplir con lo establecido.
  • Hacemos Scrum, pero en los Reviews solo invitamos a nuestros jefes, por lo que la ceremonia se simplifica a realizar una demo.
  • Hacemos Scrum, pero las Retrospectivas sólo generan malestar ya que siempre se busca culpables, por lo que se ha decidido suspender su realización.
  • Hacemos Scrum, pero el equipo no conoce los detalles del producto, por lo que el Product Owner siempre les dice que hacer durante el sprint.
  • Hacemos Scrum, pero no se hace una revisión frecuente de los alcances definidos en el Roadmap, por lo que se exige cumplir las fechas de la planificación inicial.
  • Hacemos Scrum, pero se generan muchas reuniones extras para que el equipo comprenda todos los detalles, por lo que decidimos agendar X reuniones adicionales de revisión de los ítems durante el sprint.
  • Hacemos Scrum, pero nuestros equipos no son autoorganizados, por lo que el Scrum Master actúa como un manager que les indica que cosas realizar.
  • Hacemos Scrum, pero el equipo no interactúa directamente con los Stakeholders, por lo que siempre se requiere la participación del Product Owner.
  • Hacemos Scrum, pero al equipo de desarrollo no está completamente enfocado en el cumplimiento del objetivo porque se le asignan otras tareas, por lo que separan X horas cada día para atender las otras asignaciones.
  • Hacemos Scrum, pero cada uno de nuestros sprints se dividen en fases: análisis, desarrollo y pruebas, por lo que los incrementos solo se entregan al final del sprint.
  • Hacemos Scrum, pero no se permite fallar ni experimentar, por lo que los resultados adversos tienen penalizaciones.
  • Hacemos Scrum, pero las complicaciones que tiene el equipo no son transparentes para evitar represalias, por lo que solo damos a conocer las cosas que salieron bien.
  • Hacemos Scrum, pero no sabemos con precisión cuándo un ítem está terminado, por lo que solicitamos al Scrum Master que se haga cargo de indicarnos esto.
  • Hacemos Scrum, pero durante el sprint no están contempladas actividades para el aprendizaje, por lo que si el equipo de desarrollo desea conocer nuevas cosas deben hacerlo en horario extra laboral.
  • Hacemos Scrum, pero no se hace Refinamiento porque el Product Owner está ocupado, por lo que la revisión de los ítems se lo tiene que hacer durante el sprint Planning.
  • Hacemos Scrum, pero nuestro equipo es muy grande y las interacciones son muy complejas, por lo que decidimos segmentar el equipo y agruparlos de acuerdo a especialidades.
  • Hacemos Scrum, pero el Product Owner no está empoderado, por lo que las funciones de este rol lo asume un comité.
  • Hacemos Scrum, pero los managers nos exigen incrementar nuestra Velocidad en cada sprint, por lo que en cada iteración nos comprometemos a realizar más cosas.
  • Hacemos Scrum, pero el equipo no es autoorganizado -nadie del equipo se auto-asigna tareas, por lo que el Scrum Master debe decirles el que hacer.
  • Hacemos Scrum, pero no se sabe que están haciendo los miembros del equipo, por lo que el Scrum Master constantemente debe solicitarles su estado.
  • Hacemos Scrum, pero durante el sprint no se considera tiempo para resolver la deuda técnica y el refactoring, por lo que se habilita un sprint exclusivo para atender este tipo de tareas.
  • Hacemos Scrum, pero una misma personas hace de Product Owner y Scrum Master a la vez, por lo que esta persona realiza ambos roles simultáneamente.

Conclusiones

La nota final de la “La Guía de Scrum” nos dice:

“Scrum es gratuito y se ofrece en esta guía. Los roles, eventos, artefactos y reglas de Scrum son inmutables y, aunque es posible implementar solo partes de Scrum, el resultado no es Scrum. Scrum solo existe como un todo y funciona bien como contenedor para otras técnicas, metodologías y prácticas.”

Por lo que debemos tratar de corregirlos a la brevedad posible para lograr los beneficios necesarios de Scrum.

Referencias

Leave a Reply

Your email address will not be published. Required fields are marked *