Estamos acostumbrados a hablar y oír hablar de metodologías, nos son familiares los sustantivos Scrum, Agile, Kanban, XP, ITIL, Waterfall, Lean, Design Thinking, 6 Sigma, DevOps, CI/CD, OKR, Poka-Yoke, 5S y otros mil palabros y acrónimos de moda (aunque algunos tengan más años que nosotros mismos), pero no siempre tenemos claro que es cada cosa, para que se usa y como me puede ayudar, más allá de la moda o lo "chic" que pueda resultar utilizarlas en una conversación o una presentación.
No todo son metodologías, no todas nos pueden ayudar de la misma forma pero todos esos conceptos son interesantes y nos pueden aportar perspectivas de como abordar proyectos, servicios, problemas y situaciones de una forma eficiente y creativa en muchos casos.
Si indagamos un poco en cada uno de estos conceptos veremos que la mayoría tienen muchos puntos en común ya que con el paso del tiempo han ido convergiendo y adaptándose. Esto lo podemos ver por ejemplo en la evolución de ITIL v3 a ITIL4, donde se usan conceptos como Agile y DevOps y se refuerzan los conceptos de procesos iterativos, aunque ya aparecían en v3 conceptos como el Ciclo PDCA (ciclo de Deming) asociado a la mejora continua.
En cuanto a los modelos Agile y en concreto Scrum, me sorprende que siendo de los años 90, hoy en día se presenta como algo novedoso y en la práctica, con poca penetración real.
Con frecuencia oigo "yo uso Scrum en mis proyectos de desarrollo", pero cuando dices "ah! genial, cuéntame como lo haces y que tal te funciona", en muchas ocasiones la respuesta es "bueno usamos un Scrum adaptado. Scrum es muy flexible". No puedo por menos de esbozar una sonrisa y dejar que me cuenten que es lo que hacen y que llaman Scrum pero que quizá, no lo sea en realidad. "pero te funciona, ¿no?, eso es lo importante". Quizá lo más complicado de aplicar Scrum sea el cambio de mentalidad y a veces de cultura, que exige tanto a nivel de equipo de como de organización, por lo que probar diferentes configuraciones y aproximaciones es vital para llegar a sacarle provecho al máximo. No importa si al principio no es del todo Scrum.
Suelo decir que Scrum es mu fácil de aprender, pero no tanto aplicarlo y aplicarlo bien, que creo que es como se extraen todos sus beneficios. Scrum es muy poco prescriptivo, tiene pocas reglas y son sencillas, pero exige que se apliquen de forma rigurosa.
El uso de Scrum no excluye aplicar otros conceptos como Lean, Design Thinking, CI/CD (Integración Continua/Entrega Continua) y estar enmarcado en un contexto DevOps.
En el contexto de proyectos de desarrollo de software, para mi Scrum sin duda, "este es el camino" como dirían los Mandalorianos. No me atrevo a decir que es lo mejor porque habrá quien me diga por ejemplo que "Design Sprint" de Google es lo mejor del mundo mundial. Perfecto, cada uno debe elegir lo que crea conveniente y mejor se adapte a sus necesidades. También es verdad que Scrum es lo que más conozco y en lo que tengo más experiencia, pero me enamoró desde el primer día, ya hace muchos años.
Cuando hablamos de servicios, la cosa cambia. Scrum es muy bueno en situaciones de incertidumbre, en las que o bien no tenemos toda la información necesaria para construir, no tenemos claro como debe ser el resultado final o como va a ser usado/aceptado y sobre todo cuando no sabemos si las reglas de juego van a cambiar a lo largo del desarrollo del producto.
Cuando hablamos de procesos atómicos que no van encaminados a la construcción de un producto o funcionalidad, que no tienen continuidad unos con otros, donde todo es más predecible, como puede ser un servicio de soporte técnico, en esos casos veo más apropiado la utilización de ITIL, que es mucho más prescriptivo que Scrum, pero que aporta elementos, prácticas y actividades que nos ayudan y guían en el desarrollo un servicio, comenzado por la identificación de la propia necesidad hasta la retirada del mismo del catálogo.
A pesar de que en ITIL 4 hay una convergencia clara hacia los procesos "ágiles", atendiendo a la letra y el sentido del Manifiesto Ágil, podemos encontrar algunas cosas que nos pueden chirriar en ITIL respecto a Scrum por ejemplo.
Si echamos un vistazo al manifiesto:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
