Cuando no debes usar Scrum en un proyecto.

Scrum es un marco de trabajo orientado al proceso de entrega de software en iteraciones cortas. Pequeños esfuerzos, pequeños cambios, pequeñas desviaciones, todo esto permite corregir el rumbo del proyecto en el menor tiempo posible. Si bien, es una herramienta excelente, como tal no puede ser aplicada en todos los escenarios. Es importante detectar cuando Scrum puede hundir un proyecto en lugar de sacarlo a flote. A continuación te explico:

Señales del peligro para Scrum.

Durante el diseño de tu solución o el levantamiento de tu proyecto puedes identificar ciertas situaciones que pueden indicarte que Scrum no es la mejor metodología a seguir para entregar el producto correcto.  ¿Has vivido alguna de las siguientes situaciones?, te las menciono:

  1. No se sabe el porcentaje de desviación de conocimiento.
  2. Las fechas de entrega no son negociables, ni pueden o deben de moverse.
  3. No se puede negociar la inclusión o no inclusión  de características.
  4. No hay dueño de producto o interesados, alguien del equipo de desarrollo debe de tomar este rol.
  5. Todo cambio de alcance se trata como bug.
  6. No hay un sistema de control de calidad por parte del equipo de desarrollo.

Si te has identificado con al menos dos de los puntos anteriores, es posible que usar Scrum no reporte beneficios a la productividad del equipo. Debes de saber cual es el objetivo de esta metodología.

¿Que busca Scrum?.

Scrum busca entregar el producto correcto al cliente, desgraciadamente no se cubre el entregar un buen producto. Comúnmente se asume que el mero hecho de usar esta metodología garantiza la calidad, lo cual es un error. Scrum también busca reducir la desviación de conocimiento producida en el levantamiento del requerimiento. Idealmente un requerimiento posee la especificación de como funciona o debe de funcionar un proyecto. En la realidad no siempre es posible producir una especificación que cubra el cien por ciento el sistema, esto produce una diferencia entre lo que sabes y lo que deberías saber. Hablamos de actividades y horas de desarrollo extra. Scrum ayuda a amortizar estas actividades extra agregándolas  en cada Sprint, no asocies esta metodología con cero desviación, eso no existe.

El conocimiento lo es todo, debes de saber que no sabes.

El porcentaje de lo que sabes y lo que no, define  el numero de horas totales que vas a estimar en tu proyecto. Un proyecto con 30% de desviación dice que vas a tardar 1.3 veces el tiempo que estimas. Si un cliente no puede estimar que no sabe, o te dice que ya todo esta definido debes tener cuidado, no existe un proyecto con margen de error cero. Si no se sabes el numero,  tendrás que trabajar  de mas.

Las fechas deben de ser adaptables o las características.

Es común que recibas un proyecto que ya tiene fecha de salida a producción, pero no tiene especificación. Esto es una invitación a no llegar a la fecha pactada, pero admitamoslo es parte de la profesión, difícilmente esto va a cambiar. Como equipo tenemos un numero de horas finitas y por lo tanto una cantidad de trabajo limitada. Para poder lidiar con esto puedes negociar fechas de entrega o la inclusión de características. No todas las funcionalidades de un sistema son criticas, algunas de estas pueden ser postergadas o recortadas. El dueño del producto debe ser consiente de este hecho y saber priorizar para sacar el mejor producto posible con los recursos disponibles y el equipo debe de saber exponer estos hechos y entregar un producto suficientemente bueno. En caso de que no se puedan llegar a acuerdos, vas a tener problemas.

Los interesados o dueños  del producto son indispensables.

El compromiso es fundamental en Scrum, la parte que va a recibir el producto debe estar interesada en recibir algo suficientemente bueno. Ellos o ellas van a dar el visto bueno, validar que funciona o no funciona, si es posible agregar mejoras al requerimiento inicial o desechar cosas que no aportan valor. Claro, todo desde su perspectiva de usuarios u operadores del sistema. El apartado técnico va a correr a cargo del equipo. Si no existe una figura fuerte que defienda el producto lo que va a suceder es que el equipo de desarrollo va a proponer soluciones que pueden o no funcionar al usuario final, con el riesgo de tener que tirar cosas a la basura. Es frustrante construir sistemas que llegan al usuario final y no logran solucionar las problemáticas ya que la visión del equipo no era la misma que la del usuario final, aunque sea pequeña. Representa desperdicio de horas de trabajo.

No todo cambio es un bug.

Los usuarios o interesados del producto pueden confundir un cambio con un error. Por ejemplo: si el sistema anterior tenia un botón de exportar a Excel, este no fue especificado en el requerimiento inicial. Durante la revisión por parte de los interesados del producto no fue reportado este faltante. Ahora en el despliegue de la solución el primer ticket que recibes  es un bug de un usuario que reporta esta falta como un error. No es un bug, ya que no es una funcionalidad que tiene un comportamiento esperado, tampoco es omisión por parte del equipo. Puede considerarse un cambio de alcance o un trabajo adicional, como sea. No debe considerarse como soporte. Si los interesados no quieren asumir la responsabilidad de los cambios va a haber problemas.

La calidad siempre es responsabilidad del equipo.

El equipo de desarrollo jamas debe de justificar cambios de características o alcance, soporte o corrección de errores como pretexto para la caída de calidad. Se trabaja en la calidad desde el día cero, no importa la situación. Scrum no va a asegurar la calidad, el equipo si. La inclusión de pruebas automatizadas, automatización de despliegues, documentación o mejora continua deben estar implícitas en todas tus actividades, sin excusa. Nuestros usuarios siempre van a esperar un mínimo de calidad. Si el equipo no esta comprometido con la calidad de la solución  va a convertir la entrega de cada sprint en una serie de happy paths que tienen como único objetivo pasar la revisión de los interesados del producto.

Conclusiones.

No existen balas de plata en esta profesión, cada solución ofrece ventajas y desventajas que deben de ser evaluadas al momento del análisis. Ten en cuenta, usar Scrum no te va hacer un programador Agile, en cambio, usar la mejor herramienta disponible para resolver un problema, si que lo hará.

Autor imagen: garycycles8

 

 

 

 

Gustavo Sánchez