Equipos de Soporte y Agilidad, ¿incompatibles?

0
(0)

“Llegar juntos es el principio. Mantenerse juntos, es el progreso. Trabajar juntos es el éxito”

Henry Ford

Desde que entré en el nuevo trabajo, me he visto involucrada en un reto para mí. Uno de los equipos que llevo como Scrum Master se dedica a desarrollo propio y soporte a otros equipos.

Siempre he tenido equipos de desarrollo puramente en mi carrera como Scrum Master, por eso digo que para mí es un reto, y de ahí es el post de hoy.

En primer lugar, intenté organizar gracias a mis conocimientos y mi sentido común y posteriormente busqué información, experiencia, otros casos de otras personas que están o han estado en mi situación.

Realmente, lo que he leído y lo que yo he creído conveniente, el sentido común en estos casos, coincidía bastante. Creo sin duda, que en estos casos no se pueden seguir reglas como tal, una metodología como tal.

A continuación, os cuento mi versión de la situación y una posible solución, que no definitiva y seguro habrá que ir mejorando:

He vivido en mis propias “carnes” que seguir la metodología Scrum no es viable, porque cada poco o nada tiempo, tenían diversas peticiones, de equipos diferentes, lo que hacía cambiar el alcance del Sprint continuamente.

No hay un método universalmente aceptado de abordar este problema, de manera que en los últimos días no he parado de buscar y aplicar distintas formas de tratar este asunto.

Tras mucho y mucho pensar e investigar, al final he llegado a la siguiente conclusión:

Utilizar Scrumban, ¿por qué? Esta metodología combina las buenas prácticas de Scrum y Kanban, pero también he de decir que no sigue un estándar universal, creo que es adaptable y coger lo que más te convenga de cada una de ellas.

Me he decidido por Scrumban porque hay una parte de desarrollo propio y otra parte de soporte, para ello, una variación fue crear unas historias de soporte, estimada en X puntos de historia por el equipo o estimar a posteriori (esta duda la tengo o directamente no estimar, porque podemos usar el cycle time y lead time de kanban, a esto me podéis ayudar =)).

Estas tareas (de soporte) son por definición imprevisibles. Se puede jugar a prever la carga que supondrán, pero va a ser difícil. El equipo percibe estas tareas imprevistas como obstáculos que le impiden alcanzar su compromiso para el sprint, provocando:

  • Cambios de contexto.Hacen caer en picado la productividad, y precisamente Scrum trata de eliminarlos con las planificaciones y los sprints con objetivos cerrados.
  • Pobre dedicación a las tareas de soporte. Las incidencias, al ser percibidas como molestas interrupciones que te alejan de tu objetivo principal (acabar las historias del sprint backlog), se intentan cerrar de la forma más rápida posible, descuidando la calidad.
  • Pérdida de polivalencia de los miembros del equipo. En el intento de optimizar el tiempo a dedicar al soporte, se pierda la cross-funcionalidad. En mi experiencia, las personas que desarrollaron una historia, a la larga, quedan atadas a solucionar las incidencias que se deriven de ella, porque suponemos que serán más eficientes al conocer a fondo el asunto.

Cabe destacar otro problema común de estas tareas: su invisibilidad. Las tareas de soporte son invisibles salvo para quien las lleva a cabo. Estas tareas no se demuestran en la demo de fin de sprint. Se asume que lo normal es que todo vaya bien, de manera que si algo que va mal se arregla carece de importancia. Añade este aspecto a los problemas anteriores y obtienes aún más desmotivación.

Hay explicaciones muy diversas sobre qué hace subir y bajar la motivación de un equipo. Pero si en algo hay consenso es en que los objetivos confusos y cambiantes, así como las continuas interrupciones, la hacen bajar en picado. Que cualquiera en el equipo esté temiendo cuándo le va a llegar la siguiente interrupción le va a hacer sentir profundamente desmotivado. Y aún más cuando ese trabajo es aburrido e invisible para los demás.

La parte buena de esta aproximación comentada antes, es que damos solución a estos problemas:

  • Fuera cambios de contexto.Sólo quienes están con la historia de soporte tienen que correr a apagar los incendios y peticiones imprevistas. El resto del equipo puede estar concentrado en el objetivo del sprint, sin interrupciones. Para esto, matizo, un porcentaje del equipo estar en esas tareas de soporte, y otra parte del equipo a desarrollo. Y cada x tiempo, rotar estas tareas para no desmotivar a aquellos quienes están con estas tareas, y además fomentamos la multifuncionalidad, al rotar estas tareas, cada miembro del equipo profundiza en todos los temas.
  • Dedicación exclusiva a estas tareas. Las personas de soporte no han de cerrar en falso las incidencias para seguir con lo suyo. Mientras esté en soporte, eso es lo que ha de hacer, no hay otras historias.
  • Ganamos en cross-funcionalidad. Sea cual sea la incidencia, la han de solucionar los encargados de la historia de soporte y asi como decia antes, se gana en multifuncionalidad.

Respecto a la motivación, las tareas de soporte siguen sin ser las más agradables, pero al menos ahora sabes que ese es tu objetivo y te puedes concentrar en él. No estás dejando algo más importante para atender imprevistos. Hay un objetivo claro y te ciñes a él.

La parte mala es que hacer esto es hacer trampa. La historia de soporte no es una historia. No es más que un contenedor que permite asignar a X personas a hacer algo durante todo el sprint. La historia de soporte no es una historia porque el soporte, por definición, nunca está finalizado.

En mi opinión, seguramente Scrum no ofrece una solución estándar a este problema porque no la hay. Depende de factores como el tipo de proyecto o su fase de madurez, del tamaño, habilidades y motivaciones del equipo o incluso de la cultura corporativa el encontrar una solución satisfactoria. Y, de forma iterativa, intentar mejorarla cuando no nos funcione tan bien como desearíamos.

Terminando…

¿Alguna vez has estado en esta situación? ¿Has sido Scrum Master de un equipo de soporte? ¿Y no solo de soporte, sino que, además, también hacen desarrollo propio?

Estoy muy interesada en seguir aprendiendo, probando cosas nuevas, esto seguramente no sea blanco o negro, algunas veces será banco, otras veces negro y otras una combinación.

Para mí, mejora continua, como con todo, vamos probando cosas que creemos que nos aportan valor, si es así seguir y mejorar si no, probar otras cosas, mejora continua hasta llegar a la mejor manera.

Ahora, si me gustaría aportaciones, comentarios, recomendaciones, experiencias…

También os quiero soltar una pregunta, a ver que me decís… ¿creéis más viable dividir el equipo en 2?… Porque la multifuncionalidad y motivación podrían decaer…

Bueno… ¡Ya os contaré cómo continnua este reto para mí!

Muchísimas gracias

¡Feliz miércoles!

¿Cómo de útil ha sido esta publicación?

¡Haz clic en una estrella para calificarla!

Puntuación media 0 / 5. Recuento de votos: 0

No hay votos hasta ahora! Sé el primero en calificar esta publicación.

Cómo encontraste de útil esta publicación...

¡Sígueme en las redes sociales!

¡Lamento que esta publicación no te haya sido útil!

¡Permíteme mejorar esta publicación!

¿Cuéntame cómo puedo mejorar esta publicación?

Un comentario sobre “Equipos de Soporte y Agilidad, ¿incompatibles?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.