domingo, septiembre 08, 2013

CMMi y SCRUM: Mi punto de vista

Hola a todos:

Hace algunos días venia pensando en este post, pues sé que puede herir susceptibilidades y generar controversia, pero la reflexión y la sensatez me ha llevado ha escribirlo. Comenzaré entonces el post con las dos conclusiones con las que quiero terminar:
  • CMMi es un modelo  prescriptivo que incluye muchas componentes y elementos,  su adopción es lenta y bastante costosa para los equipos y organizaciones, e incluso adoptándolo no se garantiza que "todo vaya a ir bien"
  • SCRUM es un marco poco prescriptivo que tiene excelentes prácticas de gerencia de proyectos, gestión de requisitos y habilita de una forma rápida la mejora continua, su adopción es simple y poco costosa, adicionalmente su correcta implementación hará que pronto "todo vaya bien".
Ya que saben mi conclusiones, espero estén interesados en conocer mis argumentos. Voy a manejarlos en forma de cuadro comparativo:

Característica
CMMi (Capability Maturity Model Integration)
SCRUM
Tiempo de adopción
·         Lo normal es que la adopción de cada nivel toma aproximadamente entre 12 a 18 meses [1]

·         La adopción completa de CMMi nivel 5 toma entre 3 a 5 años empleando técnicas de Six Sigma [1]
·         Aplicar Scrum y toma poco tiempo, aproximadamente 3 a 4 sprints de 2 semanas para estar ejecutando bien el framework. Se sugiere acompañamiento (coach) o mucha lectura para hacerlo bien [4]
Costo
Mínimo 100.000 dólares por cada nivel, compartido entre consultorías, adopción y adaptación del modelo dentro de la organización[12]
Sin información.

Nota: Se puede adoptar el framework y las prácticas técnicas a muy bajo costo para los equipos.
Capacidad
La "capacidad certificada" de hacer software solo se demostrará después del primer nivel (nivel 2) certificado (he concluido,  que seguirás fallando en proyectos)
La capacidad es dada por el software funcionando cumpliendo la Definición de Hecho/Realizado (Definition of Done - DoD), disponible desde el primer sprint.

Aunque es cierto, también se puede fallar en Agile [7][8][9], pero un equipo con coraje y el poder de las retrospectivas pueden cambiar favorable y rápidamente esta situación.
Complejidad del modelo
Entender CMMi requiere de entrenamiento y es un documento de 482 páginas (esta es la hora que nó me lo termino de leer)[2]
Para entender Scrum requiere de máximo una tarde leer la guía oficial que tiene 16 páginas [3]. ( y bueno, mucha reflexión y lecturas complementarias [4] para comprender este marco que te da límites y libertad.)
Universalidad del entendimiento del modelo
Muchas cosas dependen de la interpretación del consultor y de quien haga la evaluación (frase que se escucha con frecuencia mucho en el mundo CMMi).
He observado que entender el marco a pesar de ser simple, requiere de acompañamiento y mucha lectura. 

El framework te proporciona unos límites claros y mucha libertad para moverte dentro de ellos.

La recomendación en este caso es:
·        cumpla las reglas,
·         haga todas las reuniones
·         no fusione roles
·         no alargue el sprint
·         Lea a los líderes
Áreas de interés
CMMi se involucra con muchas áreas dentro de la organización, los proyectos y la ingeniería [5][2]:
·         Administración de procesos
o   Entrenamiento
o   Innovación
·         Ingeniería
o   Requisitos
o   Verificación
o   Validación
o   Solución técnica
·         Gestión de proyectos
o   Gestión
o   Administración de proveedores
·         Soporte
o   Medición
o   Auditorías al proceso y producto
o   Gestión de la configuración
o   Análisis de causas
o   Análisis de decisiones

Scrum con respecto a  CMMi solo se encuentra fuertemente asociado a la gestión de proyectos y a la gestión de requerimientos [6]

Respecto a la Ingeniería esta no se encuentra definida en Scrum, la responsabilidad es delegada al equipo auto-organizado que sabe y conoce como lograr el producto:"el equipo decide como pasar de una lista de requerimientos a un producto potencialmente entregable durante el sprint".

Por lo tanto, los equipos SCRUM se apoyan fuertemente en las prácticas técnicas (para cumplir el manifiesto ágil el cual hace el llamado a la excelencia técnica) y así lograr la DoD (Definition of Done).

Dentro de las prácticas técnicas se encuentran [10]:
  • TDD
  • BDD
  • ATDD
  • Continuous deployment
  • Pair Programming
  • Refactoring
  • Gestión de la configuración
  • Métricas
  • Entre otros


Es de observar que estas prácticas técnicas dan soporte a las diferentes áreas de CMMi, dejando por fuera a:
  • Entrenamiento
  • Administración de proveedores
Ciclos de mejora
Aunque se realizan auditorías tanto  a los proyectos como a la organización  y se recolectan y aplican las lecciones aprendidas, los ciclos de mejora toman tiempo y dependiendo de la organización se realizarán entre 2 a 4 en el año.

Y la aplicación de las mejoras depende de las políticas de la organización
Se realizan mejoras cada sprint (el cual finaliza entre 2 a 4 semanas), habilitando el PHVA en ciclos cortos y potencializando inmediatamente la mejora continua de los equipos de desarrollo.

Scrum no está orientado a la organización,  sino a  los equipos y estos son los directamente beneficiados con el framework .

Es natural el compromiso del equipo con la mejora (kaizen)

 Bajo lo expuesto anteriormente, concluyo:

Es más fácil lograr CAPACIDAD* con Scrum que con CMMi, en términos de costo y tiempo. 

-
-

"Con Scrum el proceso de alcanzar capacidad es más rápido, barato, natural y convergente que con CMMi."[14]

-
* Hablo de capacidad pues la "C" de CMMi es de Capacidad que es el argumento de venta del modelo y considerando dicha capacidad como la facultad de hacer software de alta calidad funcional y técnica que cumpla con las expectativas de los clientes y usuarios, por parte de la organización y sus equipos de trabajo.




Ahora resulta que todos son ágiles

Es frecuente encontrar artículos del SEI y al PMI y otros de corrientes de la ingeniería de software clásica, apegados a modelos rígidos diciendo:
-
"si, si, y además nosotros también somos ágiles. Miren pueden pagarnos estos cientos o miles de dólares para que yo lo certifique o certifiquemos su empresa en agilidad bajo nuestro modelo"


Observo que se les esta yendo el negocio de las certificaciones y las consultorías de las manos, pues cada vez las empresas y los equipos de software están encontrando más pronto la EXCELENCIA y CAPACIDAD de hacer software con altísima CALIDAD en el agilismo, que bajo los esquemas tradicionales y rígidos como son CMMi, PMBoK, RUP, entre otros.


En la misma línea del párrafo anterior, es una moda el uso la palabra ÁGIL / AGILE (o en su defecto SCRUM), y muchos quieren ponerla de prefijo o de apellido a su negocio, framework, título, etc., cosa buena pues apunta a que los agilistas tienen la razón y cosa mala pues habrán muchos diciendo que son ágiles sin serlo. Más temprano que tarde el mercado y los hechos demostrarán quienes son o no del mundo agile, y esto será dictado por el cumplimiento del Manifiesto Ágil  y sus Principios [11], y el éxito en la forma de ejecutar lo que se comprometen en un entorno complejo.

¿Además qué grande (léase: google, facebook, yahoo, microsfot, etc) del software tiene CMMi nivel 5?



Volviendo al inicio

Termino entonces este post con las conclusiones prometidas:
  • CMMi es un modelo  prescriptivo que incluye muchas componentes y elementos,  su adopción es lenta y bastante costosa para los equipos y organizaciones, e incluso adoptándolo no se garantiza que "todo vaya a ir bien"
  • SCRUM es un marco poco prescriptivo que tiene excelentes prácticas de gerencia de proyectos, gestión de requisitos y habilita de una forma rápida la mejora continua, su adopción es simple y poco costosa, adicionalmente su correcta implementación hará que pronto "todo vaya bien".
Queda abierta la discusión


Saludos y un abrazo ágil a todos





Referencias:

[1] http://www.sei.cmu.edu/library/assets/bridging-gap.pdf
[2] CMMI for Development, Version 1.3. http://www.sei.cmu.edu/reports/10tr033.pdf
[3] The Scrum Guide -https://www.scrum.org/Scrum-Guides
[4] Por dónde comenzar a leer y a estudiar de Scrum http://lecciones-aprendidas.blogspot.com/2013/05/por-donde-comenzar-leer-de-scrum.html
[5] Framework para el Desarrollo De Software En Entornos Académicos - https://docs.google.com/file/d/0B5JZ11Z2PoWWWDlheXY2SnhUc2M/edit?pli=1
[6] Can Scrum help to improve the project management process?  A study of the relationships between Scrum and Project Management process areas of CMMI-DEV 1.3. http://www.javiergarzas.com/2013/03/cmmi-scrum.html
[7] Ways to Fail with Scrum!- Jeff Sutherland  http://www.gbcacm.org/sites/www.gbcacm.org/files/slides/3B%20-%207%20Ways%20to%20Fail%20with%20Scrum!.pdf
[8] How to Make Scrum Fail - http://agile.dzone.com/articles/how-make-scrum-fail
[9] Scrum Fails? -Ken Schwaber http://kenschwaber.wordpress.com/2011/04/07/scrum-fails/
[10] What are the Most Important and Adoption-Ready Agile Practices?  http://www.infoq.com/research/agile-practises?utm_source=infoqresearch&utm_campaign=rr-content#.UUmgOcTIFVw.twitter
[11] Manifiesto Ágil  -http://agilemanifesto.org/
[12]Profiles of Level 5 CMMI Organizations - http://www.compaid.com/caiinternet/ezine/reifer-profiles.pdf
[13]Jeff Sutherland. Scrum and CMMI Level 5: The Magic Potion for Code Warriors "http://systematic.com/media/282221/Scrum_and_CMMI_Level_5___The_Magic_Potion_for_Code_Warriors.pdf
[14] Texto de mi autoría adicionado el 15 de septiembre de 2013

8 comentarios:

  1. Hola,

    Creo que se estan comparando peras con manzanas. Scrum es un enfoque agil no predictivo (adaptativo) para la gestion de proyectos. Nada mas.

    CMMi, tiene un alcance mucho mayor, en donde la gestion de proyectos es solo una partecita.

    En si, Scrum es manejado por el equipo de proyectos.... aquellos dolientes directos del proyecto: desarrolladores, testers, stakeholder etc (ojo menciono roles genericos, no los propios de scrum).

    CMMi, es manejado por los jefes de los equipos de proyectos.

    ResponderBorrar
  2. Hola,

    Excelente post!!.

    De pronto es cierto lo que dice Guido frente a que son dos cosas muy distintas y que CMMI tiene un alcance mucho mayor que Scrum; pero creo que el fin último de quien acoge uno u otro es lograr lo mismo: software bien hecho, clientes y proveedores felices y bolsillo lleno. En este sentido estoy de acuerdo con Jorge en que es mucho más fácil, rápido y económico adoptar Scrum para lograr dicho objetivo.
    Adicionalmente, es necesario pensar en el principio Lean de evitar el desperdicio, lo cual se complica con un modelo tan robusto como CMMI.

    Saludos y que siga el debate!

    ResponderBorrar
  3. Guido..

    El tema es de discusión..y no la estoy evitando..

    pero me cuestiona mucho que el argumento de venta de cmmi (Capability Maturity Model Integration) es la "capacidad", o mejor, un modelo para mejorar y/o evaluar la capacidad.

    Te confieso, fui por muchos años defensor y evangelista de CMMi, RUP, PMBoK...pero al ver los equipos de trabajo:

    -creando software de calidad,
    -cumpliendo los compromisos,
    - mejorando continuamente
    -y trabajando felices...

    dice uno .. wow... el proceso con SCRUM hacia el ideario de capacidad es mucho más convergente y rápido que el de CMMi... y ese es el punto que yo quiero resaltar.

    saludos y gracias por tu comentario.

    ResponderBorrar
  4. Jorge,

    Como siempre, muy buen artículo. Estamos en pleno acuerdo sobre lo costoso de implantar CMMI y de la lentitud del proceso de implantación. Excelente cuando dices que estos modelos del corte de CMMI, PMI y similares, ahora están promulgando a los cuatro viento que “son ágiles” o que “soportan la filosofía ágil”. Es el punto de inflexión, pienso yo, y muy cierto lo de que “se les está yendo el negocio de las certificaciones y las consultorías de las manos”.

    Sin embargo, te confieso que no soy muy amigo de hacer comparativos entre CMMI con Scrum o con cualquier otro método de desarrollo, ágil o no, ya que están en dos niveles diferentes. Scrum es un medio (normalmente con otras prácticas, ojalá ágiles), como lo es RUP u otro proceso de estos, para ser CMMI en alguno de sus niveles (2, 3, 4 o 5). Nosotros hoy somos CMMI 5 con un proceso basado en RUP, pero esperamos en la próxima evaluación seguir siendo CMMI 5 con un proceso basado en Scrum y otras prácticas ágiles. Yo pienso que es posible. El proceso de transformación hacia lo ágil y Scrum es gradual, pero viable.

    Finalmente, muy a lugar la reflexión de los grandes que no son “CMMI nivel algo”. Para tener en cuenta. Mi pregunta siempre ha sido “¿y quién certifica al certificador?”. Esto, por supuesto, aplica también a los mismas certificaciones Scrum (léase Scrum Alliance, Scrum.org, etc.).

    Salud@s,

    Lucho

    ResponderBorrar
  5. Opino que afirmar que la adopción de Scrum es simple y poco costosa va un poco en contravía con lo expuesto por los mismos gurús de Scrum... "Conocer Scrum es fácil, pero llevarlo a la práctica exitosamente es difícil" [1].
    Y teniendo en cuenta que los miembros del equipo deben ser personas con alta excelencia tecnica y capaces de ser parte de un equipo auto-organizado... umhhh creo que los salarios de estas personas no van a ser de los más bajos...

    Y bueno como en cualquier otro modelo o practica, buenas y malas implementaciones existen y existirán. Y como con cualquier otro modelo o practica se generará negocio por la transferencia de conocimiento a su alrededor.

    Por otro lado, estoy de acuerdo con Guido, comparar Scrum y CMMI es como comparar peras y manzanas... yo pensaría que hasta se podrían complementar.


    [1]http://www.scrumalliance.org/courses-events/courses/csm/peru/lima/2013/august/20132934-certified-scrummaster

    ResponderBorrar
  6. Jorge Hernán, creo que tu análisis es muy válido y aunque no concuerdo en un 100% felicito la claridad y franqueza con la que expones el tema.

    También he desarrollado usando RUP, y he visto los "beneficios" de usar frameworks como CMMI, y por las evidencias me queda muy claro que a veces se pierde de vista que el propósito final de los frameworks es casi siempre hacer dinero mediante un modelo de certificación.

    Creo que la práctica de una sana y eficaz Ingeniería Empresarial (lo cual podría incluir la práctica de Arquitectura Empresarial) no requiere la implementación intensiva de frameworks heavy weight como CMMI, ITIL, COBIT, etc., lo que se requiere generalmente es hacer uso de conceptos y herramientas útiles según el contexto.

    Y con el debido respeto a las anteriores opiniones de los estimados colegas, creo que Scrum y CMMI se pueden comparar muy bien en el ámbito del desarrollo de software, pues han de recordar que CMMI es una versión "mejorada" de SCMM.

    Muy buen artículo en todo caso.

    Un abrazo desde Ecuador.

    ResponderBorrar
  7. Dustin... gracias por tu comentario..

    respecto a lo que mencionas de "hacer uso de conceptos y herramientas útiles según el contexto." es cierto y ahí pecan muchos consultores o las empresas que los están implantando... pensando que el fwrk es una bala de plata... y la verdad, los framework en sí no son la solución es la combinación de muchos elementos lo que hacen que se logre el camino hacia la excelencia.

    Ahora mi argumento como lo he expresado es "la convergencia pronta y rápida hacia la capacidad en Scrum", situación que no se da tan rápidamente con cmmi.

    y como alguien lo expuso se complementan, concepto en el que coincido complentamente.

    Te/Les comparto este artículo de Sutterland, sobre scrum y cmmi para alcanzar el nivel 5 - "Scrum and CMMI Level 5: The Magic Potion for Code Warriors" http://systematic.com/media/282221/Scrum_and_CMMI_Level_5___The_Magic_Potion_for_Code_Warriors.pdf

    ResponderBorrar
  8. Muy buen articulo, porque fomenta la polemica.
    Yo diria que el CMMi tiene que hacerse ligero, para adaptarse al mundo actual, y en un momento dado pueda complementar cualquier metodologia o framework de desarrollo, sea agil o no.

    ResponderBorrar