CategoriasAgile

Scrum en operaciones, es cool pero no funciona

Scrum tiene un factor cool, a riesgo de elevar el número de haters, diré que hasta tiene un toque «populista». Me explico: es fácil de entender, las ideas que expone parecen resolver muchos problemas de forma sencilla.

Lo anterior es una idea que se aleja de la realidad, por mucho que Scrum sea un framework fácil de asimilar es muy complejo ponerlo en práctica.

Y aquí viene mi historia: es imposible aplicarlo en un entorno de operaciones de TI.

Motivo 1: no hay producto

En entornos de operación es muy difícil entender el concepto producto y por tanto muchas ideas de Scrum no son aplicables.

En operaciones hablamos de servicio y lo importante es su continuidad (y sí, el fine tunning, y el parcheo, y todo eso). De normal el producto va por encima, es la capa de aplicación que evoluciona, pero los elementos de la infraestructura.

Pongamos el ejemplo más radical de un entorno de operaciones, ¿qué producto es la monitorización de la infraestructura? (Event management en ITIL) ¿qué producto es el service desk?

Y por lo tanto si no hay producto, no hay incremento de producto.

Motivo 2: operaciones es slack, casi del todo

¿Qué vas a hacer hoy? Es la pregunta del manual del daily del principiante (y que malo es si se convierte en la pregunta del daily de todos los santos días). En un entorno de operaciones responder a esta pregunta a un técnico le llevaría quizás de 20 minutos: incrementé el disco duro de la máquina X en 20GB porque se estaba llenando, tuve que investigar un pico de CPU en la máquina Y, me tocó compilar una golden template para el proyecto Z… y a todo esto: estuve resolviendo una caida de servicio de 1 hora en el portal público…

Un equipo de operaciones no puede tener compromiso de hacer algo. Su objetivo será asegurar que las cosas funcionan, que están parcheadas, que son seguras.

Forzar a un equipo de operaciones a adquirir compromisos de ejecución diaria podría llevar al equipo a la depresión por fallar constantemente sus compromisos. El objetivo será resolver el slack, antes que las tareas planificadas.

Ojo: que no digo que no se pueden planificar tareas, solo digo que las tareas no planificadas consumirán la mayor parte del tiempo.

Motivo 3: ¿entrega a final del sprint?

Imagina, aplicamos Scrum a un entorno como service desk, tienes a usuarios pidiendo un password reset, pero les dices que tienen que esperar a final del sprint. ¿Verdad que no?

La entrega en operaciones debe ser lo más inmediata posible.

Motivo 4: ordéname ese backlog

Que en operaciones hay backlog no lo discute nadie. Pero el orden no es por valor, sino por urgencia (impacto x criticidad). Imagina priorizar un backlog que cambia cada hora, en unos 60 a 100 elementos, a toda hora.

Es más prioriza un backlog de un servicio de infraestructuras compartidas… con multiples clientes (¿product owners?) sobre un mismo equipo.

Por eso no hay orden por valor, sino por criticidad, y esto va muy unido con el motivo 2.

Pero… el manifiesto agile…

Y aquí viene mi cabreo: el agilismo no se limita a Scrum. Ni Scrum es aplicable a todo.

Se pueden usar algunas de las herramientas que Scrum propone en entornos de operaciones para aportar un toque ágil y facilitar la vida a los equipos de operación, por ejemplo:

  • Se pueden hacer retrospectivas para analizar fallos y puntos de mejora. De hecho es muy recomendable hacer análisis post-mortem de las incidencias críticas
  • Se pueden usar tableros kanban para ver el estado de las colas de los equipos.
  • Se pueden hacer dailies de sincronización del equipo para tratar solo aquellos casos que su complejidad lo requiera (o los bloqueos)
  • Se pueden tener tareas planificadas, incluso acciones de mejora planificada.