¿Scrum vs ITIL o Scrum + ITIL?

Logo Scrum + ITILEn numerosos foros me han planteado este dilema: ¿Está ITIL reñido con Scrum o, por el contrario, son compatibles? Principalmente es una duda que le surge a personas del ámbito de desarrollo de software que están dando sus primeros pasos en el agilismo y que han oído hablar sobre ITIL y sus bondades, aunque todavía no lo conocen con suficiente profundidad.

Pues bien, la respuesta es simple pero compleja al mismo tiempo. ITIL y Scrum, aunque pueden guardar cierta relación, son cosas muy distintas. Están completamente enfrentados a nivel de objetivos y de filosofía subyacente pero, a pesar de ello, pueden compatibilizarse sin que necesariamente haya menoscabo de ninguno de los dos enfoques. En mi opinión, el objetivo tiene que ser obtener lo mejor de ambos mundos y, por experiencia personal, puedo asegurar que se trata de algo completamente factible.

En esta línea, ya escribí una entrada sobre lo que yo denomino Agile ITIL, en la que explico mi experiencia aplicando Scrumban + ITIL en el área de sistemas de BikoEn este post, en cambio, mi objetivo es aclarar en mayor medida cuáles son las diferencias y algunos de los nexos de unión entre Scrum e ITIL.

.

¿Qué es Scrum?

Scrum es una metodología ágil de gestión de proyectos (project management) orientada a ámbitos poco ordenados:

  • Metodología:  Scrum admite cierta flexibilidad en su implementación pero exige que se apliquen todos sus roles, procesos y artefactos. Podemos llevar a cabo un daily scrum que dure 5 o 15 minutos, llevar el product backlog en un Excel, en Jira o en ScrumWise, tener 3 o 20 columnas de estado en nuestro panel… pero si no llevamos a cabo el scrum diario, no tenemos product backlog, no tenemos panel, no existe la figura de product owner o no hacemos retrospectivas… lo que hacemos podría considerarse ‘agile’, dependiendo del caso, pero no sería Scrum. Sólo con que prescindamos de uno de estos elementos, no estaremos haciendo propiamente Scrum (en la forma en que Jeff Sutherland y Ken Schwaber lo definieron, otra cosa es el concepto de ‘campo de scrum’ de Nonaka y Takeuchi en The New Product Development Game).
  • Ágil: es acorde a los principios del manifiesto ágil, por lo que el énfasis de la gestión se traslada a las personas y las interacciones, al producto funcionando, a la colaboración con el cliente y a la respuesta ante el cambio. En consecuencia, como toda metodología ágil, Scrum es especialmente adecuado cuando lo que prima es el conocimiento tácito.
  • Gestión de proyectos: los proyectos son un esfuerzo temporal para crear un producto, un servicio o un resultado único. Tienen un principio y un final bien definidos.
  • Ámbitos poco ordenados: son aquellos entornos cambiantes, en los que además hay muchas variables que influyen en los resultados y, por ello, se hace difícil la predicción apriorista. El desarrollo de software es un ámbito poco ordenado porque, entre otras cosas, como bien sabemos, por detallado que sea el análisis de requisitos inicial, siempre surgen nuevos requerimientos a medida que avanzamos en el proyecto.

¿Qué es ITIL?

ITIL es un marco predictivo de buenas prácticas en gestión de servicios de TI, que suele aplicarse en ámbitos ordenados:

  • Marco (framework): ITIL reúne herramientas y principios de gestión generalmente aceptados como buenas prácticas. Al tratarse de un marco, no es rígido en su implantación, en el sentido de que permite implementar únicamente los procesos o grupos de procesos que nos interesen: gestión de la configuración, gestión de cambios, gestión de incidencias, etc.
  • Predictivo: a diferencia de las metodologías ágiles, ITIL pone énfasis en los procesos y las herramientas, en la documentación, en las relaciones contractuales y los SLAs y en el seguimiento de procedimientos y planes predefinidos. En consecuencia, los mejores resultados con ITIL se obtendrán cuando el conocimiento explícito tenga preponderancia sobre el tácito para la ejecución del trabajo o de una tarea concreta.
  • Buenas prácticas: las buenas prácticas son mejores prácticas cuyo uso se ha extendido y sobre las que existe un consenso generalizado de que su aplicación contribuye al éxito del servicio. En consecuencia, el cuerpo de buenas prácticas identificadas por ITIL evoluciona con el paso del tiempo, mientras que los roles, procesos y artefactos de Scrum son los que son.
  • Gestión de servicios: los servicios son operaciones, una función de la organización que se efectúa permanentemente. Por lo tanto, en comparación con los proyectos tienen un marco temporal muy distinto. En consecuencia, los principios de gestión generalmente aceptados para ambos también son diferentes.
  • Ámbitos ordenados: son aquellos en que las variables que influyen en el resultado de una acción están bien identificadas, por ello los modelos que dan mejores resultados son los predictivos.

Analogías entre Scrum e ITIL

Aunque llegados a este punto resulta sencillo identificar las diferencias entre Scrum e ITIL, anexo la siguiente tabla que resulta más gráfica:

Scrum e ITIL: Tabla comparativa

Además de los puntos ya mencionados en las definiciones, en la tabla he añadido el proceso de mejora continua. Aunque el proceso de mejora de ambas metodologías se basa en la filosofía del ciclo de Deming (PDCA), Scrum, con sus retrospectivas, hace mayor énfasis en el expertise y la percepción de los miembros del equipo (orientación a personas); mientras que ITIL se fundamenta en métricas objetivas relacionadas con el nivel de desempeño de los procesos (orientación a procesos). Obviamente, cada una tiene sus pros y sus contras.

Otro aspecto diferencial es la amplitud de miras. Mientras que el ámbito de Scrum es genuinamente el proyecto, obviando los aspectos a nivel organizacional y confiando en la auto-organización del equipo, ITIL tiene una perspectiva más holística: destaca la relevancia de alinear los proyectos y servicios con las necesidades y los objetivos de negocio, el desarrollo de los profesionales del equipo para que puedan responder a las necesidades organizativas, la gestión del conocimiento, etc. Para tal propósito, ITIL explicita diversos procesos y funciones específicos.

Como puede verse, las diferencias son múltiples y reseñables. Sin embargo, a pesar de ello, existen más nexos de unión entre ambos enfoques de lo que pueda parecer a primera vista. Saber combinar e hibridar las prácticas y herramientas de ambos enfoques de la manera adecuada, es la clave para obtener lo mejor de los dos mundos y un rendimiento extraordinario.

Nexos de unión (I): ITIL + Scrum

Vamos a poner como ejemplo que nuestro núcleo duro es la gestión de operaciones. Nuestro equipo se dedica a gestionar varios servicios de tecnologías de la información para una organización determinada: administrar y mantener una intranet, un servicio de correo electrónico, un ERP, etc. En este caso, ITIL debería tener un gran peso en la gestión de nuestro día a día.

Sin embargo, llega el momento de implantar un nuevo servicio. Esto se trata de un proyecto en toda regla.

ITIL nos indica aspectos que debemos tener en cuenta en el diseño de dicho servicio: gestión del nivel de servicio, gestión de la disponibilidad del servicio, gestión de la capacidad del servicio, gestión de la seguridad del servicio…

Sin embargo, ITIL no entra en el detalle de cómo debe gestionarse el proyecto de implementación en sí mismo. No habla sobre si el equipo debe ser multidisciplinar o no, ni de los roles que debe haber dentro del equipo, ni cómo deben gestionarse el alcance, el cronograma, la calidad, la comunicación con los interesados o el riesgo.

En este punto es donde fácilmente pueden entrar en juego diversas metodologías y marcos de gestión de proyectos, es más, es más que recomendable incorporarlos. Entre las distintas metodologías, obviamente podemos optar por Scrum. Además, por tratarse de una metodología iterativa, personalmente, la recomiendo con especial profusión. En este punto, Scrum e ITIL tienen una elevada afinidad porque comparten el enfoque PDCA, como ya hemos comentado.

Tomando en cuenta esta perspectiva, parece muy adecuado realizar pruebas piloto (podríamos considerarlas el símil de los prototipos) a usuarios clave durante la fase de transición del servicio y, obviamente, implantar el servicio siguiendo una filosofía incremental; poniendo en vivo primero aquellos aspectos más prioritarios del servicio y desarrollando posteriormente aquellos más accesorios, a medida que se obtiene feedback y fruto de ello se introducen otros cambios. Es más, esta forma de implementar un servicio, que se percibe tan afín a Scrum, sigue al 100% el ciclo de vida de los servicios planteado por ITIL.

Por otra parte, mencionar que dos mecanismos de coordinación de Scrum que son muy valiosos y que pueden incorporarse fácilmente en una organización que ya esté realizando  ITIL son el scrum diario o reunión de seguimiento y las reuniones de retrospectiva.

Nexos de unión (II): Scrum + ITIL

Ahora vamos al caso contrario. Una organización orientada a proyectos, como suele ser la clásica consultora de comunicación online especializada en portales corporativos.

En este entorno, lo que debe predominar es Scrum. No hay dos proyectos iguales y, quienes conozcan bien este ámbito, sabrán que los requerimientos cambian frecuentemente a lo largo del proyecto y que la pericia del equipo de desarrolladores, consultores, etc. juega un papel fundamental en el éxito del proyecto (muy por encima de trazar un buen plan al inicio del proyecto).

Este es un buen ejemplo de cómo podemos enriquecer Scrum con prácticas procedentes de otros enfoques y marcos, ya sean o no ágiles. Por ejemplo: podemos crear un híbrido con Kanban (Scrumban) para gestionar todas esas pequeñas peticiones que nos llegan durante el transcurso de una iteración, podemos incorporar prácticas como TDD (que viene de XP) para enriquecer nuestro sistema de gestión de la calidad… y también podemos incorporar procesos y funciones de ITIL. Por ejemplo:

  • Los procesos de diseño del servicio, aunque sea ejecutándolos a alto nivel, sin entrar en demasiado detalle, pueden ser muy prácticos de cara a valorar aspectos que lamentable y frecuentemente suelen quedar descuidados en equipos excesivamente orientados a desarrollo, como es el dimensionamiento de las infraestructuras, la disponibilidad de personal capaz de resolver incidencias del producto en producción en ciertos periodos estacionales, la formación a usuarios, etc.
  • Que el cambio sea bienvenido en las metodologías ágiles, no significa que puedan llevarse a cabo de forma alegre. Aparte de la consecuente gestión del alcance, si nuestro producto ya está en producción, implantando los procesos y las políticas de transición del servicio de ITIL rellenaremos un vacío de Scrum y nos curaremos en salud de más de un posible susto.
  • No conozco a ninguna compañía orientada a proyectos que no realice operaciones, aunque a veces pasen desapercibidas. En ocasiones, en una empresa como la ejemplificada, los últimos flecos de un proyecto o la resolución de bugs en el periodo de garantía se gestionan mediante un equipo de postventa. Igualmente, tengamos un equipo concreto o no para estos temas, implementar la función de service desk e incorporar los procesos de gestión de incidencias y de gestión de problemas puede reportar mejoras de productividad sustanciales, además de mayor visibilidad en este proceso. Obviamente en este punto podemos aplicar también Kanban para beneficiarnos de sus bondades.
  • Otras funciones de ITIL como la gestión técnica o la gestión de aplicaciones también son fundamentales para el desempeño de un equipo en el largo plazo. Scrum no hace referencia a estos aspectos, sin embargo, en ITIL encontramos un marco de referencia.

Aunque las posibilidades son múltiples y sé que se me quedan muchas en el tintero, por no hablar de profundizar en mayor medida y con mayor detalle en las ya expuestas, espero haber cumplido con mi objetivo y haber resuelto las principales dudas que tenían en mente aquellos que alguna vez me han preguntado por el tema.

Obviamente estoy abierto a responder a todas las dudas que me dejéis en la forma de comentarios, así como a entablar un constructivo debate con aquellos que no compartan mi visión sobre la compatibilidad entre Scrum e ITIL. ;-)

Related Posts Plugin for WordPress, Blogger...
Alfons Corrales
About Alfons Corrales 28 Articles
Interesado en Management, Innovación, Implantación estratégica, Gestión del cambio, Balanced Scorecard, Project Management, Scrum & Agile, ITIL y Tecnología.

8 Comments on ¿Scrum vs ITIL o Scrum + ITIL?

  1. Excelente artículo Alfons!, realmente me has aportado ideas claras y prácticas, los dos ejemplos que has puesto ITIL+SCRUM y al revés, muy útiles.

    Por mi experiencia y necesidad profesional reforzaría en el caso SCRUM+ITIL:
    1. el proceso Itil de Gestión de Proveedores (UCs, contratos de soporte), ya que las empresas de servicios trabajamos en red, subcontratando tareas o partes de proyectos (web, CRM,etc) a profesionales externos. Sin una excelente gestión de nivel de servicio por parte de proveedores, los proyectos se pueden ver comprometidos en tiempo y recursos, lo que afecta a tu imagen de marca y relación con el cliente.
    2. Lo anterior va relacionado también con una buena implementación del proceso de Gestión de peticiones, para priorizar y dar el valor adecuado a cambios que el cliente solicita.
    3. Gestión financiera, que sobretodo las pequeñas y medianas organizaciones necesitan para llevar un buen control del proyecto y servicio al cliente. Muchos Project Managers no saben si ganan o pierden dinero con cada proyecto, y eso desajusta el equilibrio dentro de la propia organización.

    ¿Puedes darme algún consejo para ayudar a cristalizar la necesidad de implementar ITIL+SCRUM en un cliente?, han reajustado la plantilla de personal en el Departamento TIC y hay poner orden y metodología en procesos y personas.

    • ¡Muchas gracias David!

      Me siento muy satisfecho con la calidad del artículo, principalmente, porque considero que debe ser muy interesante, dado que los temas que me planteas son realmente controvertidos y ahondan en lo que yo creo que suelen considerarse las principales debilidades de las metodologías ágiles. :-)

      Agradezco enormemente tu participación porque, como ya digo, planteas preguntas muy adecuadas, cuestiones que considero de relevancia capital.

      Espero que mi respuesta sea más corta que mi post, porque si me planteas un par de preguntas más de este calibre, podemos ir planteándonos editar un libro. ;-)

      1. Gestión de proveedores o de adquisiciones

      En primer lugar, además de lo que ITIL plantea, te recomiendo profundizar en el PMBOK 4 (capítulo de gestión de adquisiciones o procurement management).

      En segundo lugar, has dado en un punto clave: hasta la fecha, no conozco ninguna metodología ágil que profundice en la gestión de proovedores.
      Lo que me dice la experiencia, es que, al final, en este punto, la aplicación de ITIL parece centrarse casi exclusivamente en la elección del tipo de contrato adecuado y en la gestión del SLA de tu proveedor. Este enfoque tiene mucho valor cuando hablamos de contratar un servicio que medianamente pueda considerarse commodity, como por ejemplo, servicios IAAS, PAAS o SAAS (como la línea ADSL, el alojamiento de una página web, un CRM como servicio, etc.).

      Sin embargo, ¿qué sucede con servicios de mayor valor añadido, en los que la implicación del proveedor es clave? ¿Debemos hacer prevalecer un contrato o, por el contrario, tiene más valor el tipo de relación que mantengamos con el proveedor?

      Entiendo que este debe ser tu caso, al trabajar en red, y por eso quiero ser un poco disruptivo en mi enfoque: ¿Por qué apuestas por Scrum en tu organización? ¿Por qué apuestas por las metodologías ágiles en la gestión de proyectos? Probablemente la respuesta sea que, para el tipo de proyectos que llevas a cabo, está comprobado que las metodologías ágiles tienen una mayor tasa de éxito.

      En consecuencia, mi respuesta es: para servicios de alto valor añadido, en entornos cambiantes o poco ordenados, en que prevalezca el conocimiento tácito de los miembros del equipo, contrata a un proveedor ágil (o trabaja con partners ágiles, como tú). Pero ágiles de verdad.

      Este hecho implica que tendrás mayor flexibilidad y visibilidad sobre el trabajo desempeñado y, muy probablemente, mayor nivel de cooperación. La contrapartida es que este enfoque entraña a su vez un mayor esfuerzo por tu parte (el cual debes valorar adecuadamente como coste). No obstante, si por ejemplo se trata de un servicio tipo consultoría o desarrollo de software estoy convencido de que apreciarás enormemente el incremento de valor aportado.

      Así, el mayor extremo al que puedes llegar es convertirte en el product owner del equipo del proveedor. Es una apuesta que conlleva mucho más trabajo: SÍ, sin lugar a dudas. Sin embargo, el rendimiento posiblemente valga la pena y resulte rentable.

      2. Gestión de peticiones

      La gestión de solicitudes de servicio (service request), incidentes y solicitudes de cambio suele generar mucho ruido y rompe con el foco del equipo, disminuyendo consecuentemente la productividad.

      En este punto, no he encontrado mejores políticas de las que ITIL te brinda (incluidos los principios que te da para priorizar las peticiones, los cuales deben detallarse de forma muy concreta para cualquier contexto concreto). Asimismo, considero que combinarlo con la implementación de Kanban es fundamental para obtener un rendimiento superlativo.

      Ojo. No hay que desmerecer en ningún caso a otros procesos de ITIL que apoyan inherentemente a la gestión de peticiones o incidentes (me refiero especialmente a la gestión de problemas y a la gestión de la configuración).

      3. Gestión financiera

      Scrum parece reducirlo todo a una sola métrica: la velocidad. Este hecho tiene mucho valor, puesto que, en una sola variable, fácil de conseguir, aglutinamos el nivel de cumplimiento del proyecto en su baseline (su línea de base: coste, alcance y tiempo). Con un burndown por iteración y un burnup del proyecto, tenemos dos herramientas sencillas pero muy, muy potentes.

      Si la velocidad es buena, fenomenal. El problema surge cuando nuestra velocidad no es la adecuada. Aunque sin salirnos del agilismo existen medios para valorar el coste estimado que tendrá un proyecto y compararlo con el presupuestado, que es lo que generalmente queremos medir, en ocasiones puede ser extremadamente complejo llevarlos a cabo, dado que suelen requerir de cierto histórico (datos sobre el desempeño de un equipo en condiciones similares).

      En esa situación, más que remitirte a ITIL, siempre que estemos hablando de proyectos, te recomiendo profundizar en el PMBOK 4, en concreto en el capítulo de gestión de los costes. Ahí encontrarás otra preciosa herramienta, el EVM (Earned Value Management). Espero que te sea de provecho ;-)

      En cuanto a lo que me comentas de vuestro cliente, es complejo. Hay que analizar de forma individualizada cada caso para poder realizar un diagnóstico fundamentado. Mi opinión personal es que la mejor forma de justificar cualquier sistema de gestión es mediante la obtención de resultados, ya sabes, PDCA y quick-wins.

      Asimismo, quiero poner de manifiesto que, en ocasiones, hablar de ciertas metodologías provoca pánico. Podemos encontrar casos de cualquier metodología mal implementada que ha causado estragos. En consecuencia, mi experiencia me lleva a pensar a que suele ser más práctico rehuir de nomenclaturas y demostrar el valor de un sistema de gestión en el “campo de juego” (o Gemba, si queremos ser más Lean).

  2. Muy buen artículo, felicitaciones. Solamente que Scrum no es una metodología, sus creadores lo definen igualmente como un Framework, es muy importante para todos los que lo practicamos que Scrum se defina como un marco de trabajo. Saludos!

    • Muchas gracias Eduardo. Lo mejor para responderte es remitirse a la fuente original, la Scrum Guide en inglés, la cual ha sido recientemente revisada (http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%202011.pdf).

      En la misma se define a Scrum como un marco de trabajo (“a framework for developing and sustaining complex products”), sin embargo insiste en que es normativo aplicar todos sus roles, eventos y artefactos. Es decir, si nadie desempeña el rol de Scrum Master o el de Product Owner tal cual se definen, no estaremos haciendo Scrum; si no trabajamos con sprints de menos de un mes, no estaremos haciendo Scrum; si no llevamos a cabo reuniones diarias, reuniones de planificación o reuniones de retrospectiva en la forma como se describen, no estaremos haciendo Scrum; etc.

      Es por eso, debido a este carácter normativo, que considero que Scrum es una metodología (y no soy el único que la enmarca de esta forma). La diferencia con respecto a un marco de buenas prácticas como ITIL, es que en el segundo puedes implantar únicamente los procesos que te interesen sin desvirtuar lo establecido en la fuente que lo define. Es decir, por ejemplo, puedes implantar únicamente los procesos de operación de servicio y decir que estás haciendo ITIL. Estas implementaciones parciales no existen en Scrum: o lo aplicas a rajatabla o no lo estás aplicando.

      Otra tema aparte, es la flexibilidad que existe en la implantación efectiva de los eventos y los artefactos de Scrum; que es a lo que creo que los autores se refieren al definir esta metodología como “framework”.

  3. Hola,

    Lo primero felicitar al autor de este artículo por su rigor y valor didáctico.

    Quería transmitir una duda sobre este tema. Tengo que decidir si recibir formación en Gestión Agil de proyectos o en ITIL y sería de grgan ayuda que me comentaras tu opinion al respecto. Adjunto unas pinceladas sobre mi perfil y el objetivo que persigo:

    – He trabajado como consultor funcional de sistemas de información (SAP, Agresso, Navision) y quiero reforzar mi CV para seguir trabajando en consultoría.

    – No descarto trabajar en una empresa cliente que ya tenga implantadas aplicaciones de gestión o BI (ERP, CRM, MicroStrategy…) y necesiten mantenerlo, ampliarlo, etc.

    Muchísimas gracias por adelantado y felicidades.

    • Hola Sergio,

      Mis disculpas porque hasta ahora no vi tu comentario y por eso no respondí. Creo que optaste por la opción más acertada. Teniendo un background de consultoría, reforzará en mayor medida tu CV un postgrado en gestión ágil de proyectos porque es un ámbito en el que ya tienes experiencia.

      Muchas gracias por tu comentario.

      Saludos.

  4. Hola ! Una consulta rapida , podria usar Scrumpuro , sin agregarle El Itil , a servicios post-venta , ya lo usamos en el desarrollo de proyectos , sera que sea correcto o mas bien optimo utilizarlo ahora en el servicio post-venta?

    • Hola Alejandra. En lo que propiamente sería servicio postventa, lo ideal es ITIL (en concreto su función de service desk). Si ofreciendo el servicio postventa surge la necesidad de acometer un proyecto, lo ideal es gestionar ese proyecto con una metodología de gestión de proyectos (como SCRUM).

2 Trackbacks & Pingbacks

  1. ¿Scrum vs ITIL o Scrum + ITIL? | José Luis Pérez Díaz
  2. Scrum vs Itil | Proyectos y software

Leave a Reply

Your email address will not be published.


*



*