Combinar Scrum y CMMI (parte 1 de 2). 5 claves a tener en cuenta

Casualmente, desde que en septiembre volví de aquellos meses en los USA, allá por la Carnegie Mellon, donde estuve trabajando entre otros en integrar y combinar Scrum y CMMI, no ha habido un mes en el que no haya tenido que tratar con el tema y sus compatibilidades. El tema sale en cursos, charlas, en cafés, en proyectos de implantación de uno, otro o ambos. Últimamente hay mucha conversación sobre cómo combinar Scrum y CMMI (y viceversa).
Por ello, con esta serie de dos post he querido dejar algunas de las claves más importantes a considerar, y tener claras, a la hora de combinar Scrum y CMMI.

Cinco claves a tener en cuenta sobre combinar Scrum y CMMI

1 – CMMI es un modelo, no una metodología. CMMI trata sobre qué buenas prácticas mejoran una organización, mientras que Scrum aporta un cómo implantar esas, u otras, buenas prácticas. CMMI dice, por ejemplo, que espera encontrar que se estime, pero no cómo estimar. CMMI dice que espera encontrar un ciclo de vida, pero no cual. Scrum aporta, entre otros, un como implantar un ciclo de vida iterativo e incremental.
2 – Scrum ayuda a implantar buenas prácticas (procesos) de gestión de proyectos, pero no cubre todas las buenas prácticas que requiere CMMI. Hay otras cosas que trata CMMI y que no cubre Scrum.
3 – Implantar CMMI con Scrum (y viceversa) es posible, ya que muchas empresas lo han  hecho. Por ejemplo, en Kybele Consulting ha habido muchos proyectos de evaluación/certificación de la calidad de procesos y métodos ágiles.
4 – Una cosa es implantar CMMI, es decir, mejorar la calidad implantando sus procesos, y otra evaluarse. Implantar CMMI con Scrum (y viceversa) es posible, pero ciertas prácticas de Scrum no dejan evidencias persistentes. Es decir, que por ejemplo un Product Backlog construido un día con post-it es difícil de enseñar muchos días después a un evaluador (auditor). Este es para mí el principal problema de la unión CMMI – Scrum, el mostrar evidencias en la evaluación, y no el combinarlos para la mejora. Vamos,que el problema estaría más en la evaluación que en la implantación.
5 – Aparte de este humilde post, también los padres de CMMI y Scrum dicen que combinar Scrum y CMMI es posible. Por ejemplo, Jeff Sutherland, uno de los padres de Scrum, ya hablaba hace tiempo de “Scrum and CMMI Level 5: The Magic Potion for Code Warriors”. Y Mark Paulk, quien escribiera la primera versión de CMM (versión previa CMMI), tiene trabajos sobre Scrum y CMMI. Como tuve la suerte de trabajar con Mark meses, en la segunda parte de este post os algún resumen de dicha colaboración en combinar Scrum y CMMI.
Enlace a la segunda parte de este post.

0 comentarios en “Combinar Scrum y CMMI (parte 1 de 2). 5 claves a tener en cuenta”

  1. Pingback: Bitacoras.com

  2. Javier, creo que habría alternativas, no se si para todas las excepciones que podamos encontrar entre el modelo (el qué) y Scrum (el cómo). Por ejemplo, existen diversas herramientas software que te permiten tener el Product Back log e historias de usuario en formato digital guardando el histórico de evoluciones de estado de dichos elementos, cierto que «nos cargamos» el glamour del tablón con los postits y tal pero siempre podríamos poner un TFT de 50″ en la sala 🙂
    Por otro lado, los evaluadores no siempre necesitan evidencias físicas de haber ejecutado una buena práctica, a veces las evidencias son derivadas y otras ocasiones con afirmaciones de todos los implicados también podrían valer, es más, espero que el SEI se esté orientando en incluir en el manual del Lead Appraiser la posibilidad de estar cumpliendo las buenas prácticas del modelo utilizando metodologías Agile, de no ser así, se estarían auto-excluyendo de una buena parte del mundo del desarrollo de SW.

  3. Efectivamente, esa es la manera que utiliza mucha gente para hacer la unión. El problema, como bien comenas, es que para algunos equipos eso “rompe la esencia de lo que es un Kanban en un tablero en la pared”
    El tema de las evidencias es que en CMMI la afirmación es valida… pero siempre acompañada del artefacto directo (saluda directa del proceso), que no se obliga a que sea un papel, pero que, en mi experiencia, los evaluadores muchas veces así lo requieren (y no tanto el SEI)
    Gracias por interesante cometario!

Deja un comentario

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

Share This
Ir arriba