vendidoLos "CMMI's" cada vez se llevan menos. Tras 20 años de ayudar a las empresas de programación, no se sabe si a mejorar el software, o a licitar con ventaja en los concursos públicos, han perdido fuelle y terreno frente a la agilidad.

Así que ahora le toca al negocio de la consultoría renovarse, porque el asesorar con "CMMI's" se vende cada vez peor, y la agilidad es sin duda la nueva tendencia. Lo malo es que algunos, o bien no entienden lo que venden, o sólo les preocupa hacer el dibujo de un marco lo suficientemente creíble para engatusar a los clientes que se conforman con aparentar e ir a la moda.

 

agile for phbs

 

Así que van a convertir a la agilidad en otro modelo de procesos, porque gracias a su capacidad de marketing, van a ser muchas las empresas a las que les van a enseñar cómo deben organizar a los equipos autoorganizados, o a las que convencerán de que Scrum tan sólo es un ciclo iterativo que pueden implementar sin dejar de "embau-contratar" con clientes y administraciones como hasta ahora, porque su marco ágil funciona sin esa bobada de la colaboración estrecha entre cliente y desarrolladores, que sólo serviría para destapar información inconveniente, como que le están facturando 7 "recursos senior" y en su proyecto sólo hay dos becarios desmotivados.

Y de cosas como la autonomía y "empowerment" de los equipos, cultura ágil de la organización... mejor ni hablar.

 

 

Comentarios   

0 #9 Juan Ramón García 23-05-2015 05:43
Muy buenos días,
En primer lugar gracias por el artículo y por la interesante conversación generada.
Tan solo quería aportar mi opinión personal en cuanto a la adopción de metodologías ágiles. Me gusta lo de adopción ya que toma a la agilidad como una ampliación de la familia.
Al grano, creo que en agilidad lo importante tal y como comenta Juan Palacio son los principios y si estos se adoptan correctamente el resto es completamente adaptable.
En mi experiencia personal de adopción, en nuestro departamento dentro de una pequeña entidad financiera, aplicar correctamente los principios ya es todo un reto. Sin embargo es nuestra meta y la tenemos muy clara.

Nos gusta la agilidad y ahora nos toca demostrar que con ella se mejoran los resultados.

Gracias y buen día,
Citar
0 #8 Juan Palacio 13-05-2015 07:13
CMMI no es lo opuesto a la agilidad, sino al revés: la agilidad es lo que surge como oposición o antítesis a CMMI.

La calidad tradicional no es mala, completamente de acuerdo contigo, por eso los que se sienten incómodos y como avergonzados al defender CMMI al surgir la agilidad, caen en un complejo que en nada ayuda a marcar bien las fortalezas y ámbito de CMMI, y acaban embarrando el mapa y liándonos a todos, llamando agilidad a lo que no lo es.

También de acuerdo en que CMMI marca qués y no cómos, pero a la agilidad le pasa lo mismo, marca qués y no cómos o prácticas concretas. Aplicar prácticas concretas ágiles no da agilidad (error de muchas adopciones pseudo-ágiles y talibanismos), la agilidad está en los principios, en los qués.

Al igual que en CMMI podríamos considerar que las prácticas son prácticas recomendadas, y que si se alcanza la meta específica o global con otras prácticas, es lo mismo ;-)

Un saludo :)
Citar
0 #7 Alex Ballarin 13-05-2015 06:51
Un buen repaso a la historia de calidad y a su aplicación al SW. :-)

Yo no estoy de acuerdo en que CMMI sea "opuesto" a agilidad (son ciertamente diferentes, pero opuesto significa además incompatibles). La agilidad si es opuesta a la cultura jerárquica y planificación definida, clasicas de los proyectos tradicionales.

Tampoco en que CMMI se avergüence (eso sería como reconocer que la calidad tradicional es mala). En 2010 leí este libro donde se trataba el tema, y fue uno de los que me hizo dedicarme más a la agilidad.

Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement - http://www.amazon.com/Integrating-CMMI-Agile-Development-Performance/dp/0321714105

CMMI siempre ha sido de QUEs y no de COMOs. Los QUEs pueden ser ágiles, aunque en los inicios de CMMI fueran más populares los procesos basados en la cascada.

La agilidad "pura", sin procesos ni restricciones para los equipos, está muy bien para ciertos equipos y contextos privilegiados, para otros sigue siendo recomendable la cascada y para otros los enfoques híbridos.

Me parece interesante este esquema basado en el Diagrama de Stacey. http://www.brilligence.net/wp-content/uploads/2013/04/stacey-matrix-agile.png

En fin, seguimos. :-)
Citar
0 #6 Juan Palacio 12-05-2015 13:37
Hola Alex,
Que un modelo de producción sea "industriarizable" para mi no es peyorativo en absoluto, y si se puede garantizar la calidad del resultado a través de los procesos y la tecnología empleada en la producción, es un error garantizarlo a través de las personas.

La manufactura industrial ha puesto de manifiesto la importancia de la producción basada en procesos.

El error (para mi) de Watts Humphrey (fundador y director de los marcos CMM, además de TSP y PSP) es aplicar al desarrollo de software, el principio de calidad que tan buenos resultados da en la manufactura industrial y en la producción industrial: "La calidad del resultado depende de la calidad de los procesos empleados". Sobre este principio asentó en 1987 el desarrollo de modelos de madurez de las capacidades para garantizar que la organización produciría software de calidad.

La siguiente es una cita textual de CMMI DEV 1.2, (pág 16)

"La industria manufacturera ha reconocido la importancia de la efectividad de los procesos y la eficiencia. Hoy en día, muchas organizaciones en el sector manufacturero y de servicios a reconocer la importancia de los procesos de calidad"...

En la década de 1930, Walter Shewhart comenzó a trabajar en la mejora de procesos con sus principios de control estadístico de calidad [Shewhart 1931]. Estos principios fueron refinados por W. Edwards Deming [Deming 1986], Philip Crosby [Crosby 1979], y Joseph Juran [Juran, 1988]. Watts Humphrey, Ron Radice, y otros extendido estos principios aún más y comenzó a aplicar a software en su trabajo en IBM y el SEI [Humphrey, 1989].
SEI ha tomado la premisa de la gestión sobre procesos, "la calidad de un sistema o producto es sobre todo consecuencia de de la calidad del proceso utilizado para su desarrollo y mantenimiento", y CMM se desarrolla sobre esta premisa. La creencia en esta premisa es compartida en todo el mundo por los movimientos de calidad, como lo demuestra la Comisión Electrotécnica Internacional (ISO / IEC) de la Organización Internacional de Normalización ISO..."

Yo sí que considero que CMMI lleva la etiqueta de "industrializable". Se la ponen ellos mismos, y ahora lo peor que pueden hacer es avergonzarse de ella y querer convencernos de que no, y llamar agilidad a lo que debería ser su evolución: aplicación de marcos de procesos ágiles y desarrollo de ingeniería concurrente (lo que para mi es Safe), reconociendo que para muchas empresas eso es lo que necesitan, e incorporando así los patrones de desarrollo continuo o incremental que ha aportado la agilidad, a su esencia y principios de producción industrial.

Por eso si una empresa realiza cometidos con sistemas de software que puede procedimentar y delegar en los procesos y la tecnología el protagonismo de la calidad... adelante, un CMMI es para ella, y se trata de un proceso "industrializable".

Y totalmente de acuerdo contigo con "agilidad híbrida", creo que es lo que yo llamo síntesis. Bueno yo no: Nonaka y Takeuchi en su descripción de la evolución dialéctica del conocimiento: entre CMMI y la Agilidad su síntesis es el aprendizaje de lo bueno de ambas, pero el hecho de que sea una síntesis es porque ambas son opuestas, y no consiste en sumar las dos tal cual ;-)

Saludos!
Citar
0 #5 Alex Ballarin 12-05-2015 08:14
Hola Juan,

esta respuesta la entiendo más.

No estoy de acuerdo en añadir la etiqueta "industrializable" a CMMi, porque está claro que el nivel 2 no lo dice, y el nivel 3 deja claro que deben adaptarse las prácticas a cada proyecto. Lo que pasa es que:
1) Se ha quedado el sanbenito de industrialización de las SW factory a CMMi porque estas lo hicieron bastante famoso como criterio de calidad. :-(
2) Hay mucha gente que ha ido "a piñón" sin entender el modelo, y ha hecho implementaciones facilonas e inflexibles.

Aunque estoy de acuerdo que hay empresas cuyas culturas no son propensas a la agilidad y se meten por moda (o impulsadas por proveedores, que atención, no tienen que ser grandes consultoras sinó también "gurús" del agilismo), hay otras que creo que sí hacen una apuesta tradicionales por la agilidad y precisamente a estas son las que les aplica modelos "no fractales" como DAD o SAFe. Es una entrada a la agilidad más viable a su caso.

Para mi la agilidad no es sólo XP, Scrum y compañía, sinó que prefiero abrir el concepto a la "agilidad híbrida" que incorpora organización o fases del proyecto tradicionales. Para mi la gestión del portafolio puede combinarse con el PULL de modelos y prácticas como las que mencionan. Los equipos pueden autogestionarse y no se les hace PUSH. No se trata de una elección binaria ingeniería tradicional o agilismo, creo que es un contínuo y por lo tanto puedes situarte en el 100% de agilidad, en el 0% o en cualquier punto intermedio mientras sepas a lo que juegas.

Creo que hay que ser pragmático y admitir la agilidad híbrida. No supone cargarse nada (si se sabe que se está haciendo), y una opción "agilista core" para mi es inviable en muchos tipos de empresas. Digamos que prefiero ver botella medio llena, y que es una oportunidad de darles una agilidad.

Prefiero abstraerme del debate de quien gana dinero más o menos fácil, porque nos desviamos del beneficio que pueden obtener las empresas de la agilidad (lo que a mi me importa al final de todo). La agiidad es como otros nichos, hacen dinero las consultoras, los freelances y organizaciones que se dedican a la formación y certificación. :-)

¡Saludos!
Citar
0 #4 Juan Palacio 11-05-2015 16:11
Hola Alex,

Muchas gracias por enriquecer el artículo con más puntos de vista y hacer que no sea un monólogo de una sola opinión ;-)

Yendo a lo que comentas:
De acuerdo que ha habido empresas que se acercaron a CMMI buscando sólo la apariencia, y otras que por el contrario que se acercaron buscando un modelo de mejora. Yo soy un ejemplo de estas segundas cuando decidí implantarlo en el departamento de programación que dirigía hace 13 años.

Como dices, los procesos mejoran la organización y la madurez y para mi aquí hay un punto clave de la cuestión: la organización y la madurez organizativa ayudan a mejorar aspectos importantes si el modelo de producción es "industrializable"; algunas empresas de software realizan: desplieges, integraciones, operación o mantenimiento de sistemas, que pueden mejorar industrializando el proceso, luego un CMMI les puede ayudar. Pero otras empresas de software tienen que desarrollar sistemas en escenarios de negocio inciertos o de evolución muy rápida y que requieren un componente de innovación muy alto y ahí CMMI sólo aporta rozamiento.

En esta realidad, se combinaron:
- Empresas a las que sí convenía un modelo de procesos y lo aplicaron => les fue bien.
- Empresas a las que no convenía pero les vendieron que era bueno y lo aplicaron (mi caso) => no nos fue bien, pero aprendimos ;-)
- Empresas que ni sabían si les convenía o no pero querían la etiqueta CMMI => lo liaron todo.


Y, también desde mi punto de vista, lo que está ocurriendo ahora es un poco lo contrario:

Si antes a empresas que no necesitaban procesos les entraba complejo por no tener procesos... ahora a empresas que no necesitan la agilidad les pasa lo mismo. Pero éstas son empresas grandes con estructuras y culturas rígidas por lo que no van a "comprar" modelos fractales de culturas planas y abiertas tipo google o spotify, así que la consultoría para no arriesgar su venta, está construyendo modelos de procesos de ingeniería concurrente con las prácticas que usan lo equipos ágiles (sprints y gestión visual kanban) y les convencen (nos acabarán convenciendo a todos) de que eso es agilidad.

Son marcos de procesos para desarrollar de forma iterativa o incremental (con sprints o con flujo continuo monitorizado con gestión visual kanban). Y posiblemente sea eso lo que quieran, pero si creemos que eso es agilidad, nos acabaremos cargando la agilidad.

Lo que planteo es que es un error creer que la agilidad consiste en hacer determinadas prácticas.
Se puede ser ágil sin tener institucionalizado un marco de prácticas ágiles (para mi es la mejor forma de ser ágil) y se puede ser "factory" institucionalizando prácticas para producir de forma incremental o continua, pero sin ser ágil, sino habiendo sabido hacer una una síntesis de conocimiento útil de procesos y agilidad.

De nuevo gracias por tu comentario.
Un saludo!
Citar
0 #3 Alex Ballarin 11-05-2015 13:00
Hola Juan,

tengo que mostrar mi disconformidad con varios puntos de tu artículo. Creo que es sano cruzar puntos de vista diferentes, es algo que genera innovación.

Es verdad que CMMi ha bajado. Un motivo es que ha llegado la agilidad (¡bien!) pero otro es que vivió una burbuja con el Plan Avanza (en el ITA y en otros muchos sitios lo saben bien). Yo participé en muchos proyectos CMMi y algunas empresas efectivamente lo querían como ventaja competitiva. Creo que es injusto decir que "sólo lo querían por la etiqueta", es mi experiencia de las empresas donde trabajé. En general mejoraron su organización y su madurez, que era el objetivo principal.

Tampoco estoy de acuerdo en la cruzada de los "agilistas core" (como les llama Scott Ambler) contra SAFe. Creo que las razones de este desprecio están en el fundamentalistmo ágil y en el desconocimiento. Claro que hay grandes integradoras que van a los bancos a implantar SAFe, y claro que se repiten prácticas comerciales mejorables, pero ni SAFe es tan malo, ni otras opciones puramente ágiles son viables. En un entorno tan complejo como el del famoso banco donde se está implantando SAFe (empieza por B y acaba por A, tiene 4 letras) no es viable modelos ágiles como spotify, ni siquiera LeSS, a la escala en que se plantea. Es necesario por su cultura y por la enorme complejidad del portfolio de proyectos y tecnologías mantener una jerarquía. La autoorganización no escala tanto, y menos en un escenario no favorable. Además, SAFe cuenta con Scrum en los equipos y con Kanban en los niveles tácticos y ejecutivos. Es PULL, y eso creo que no se tiene en cuenta. Luego se implementará como sea, bien o mal, pero me parece injusto descalificar por lo general a SAFe.

La autoorganización es buena. Pero no es el fin último. Me gusta el enfoque de Management 3.0 donde se habla de ello.

En fin, espero que mi comentario no sea visto como un "ataque", sinó como una aportación diferente para enriquecer el debate.
Citar
0 #2 Juan Palacio 07-05-2015 19:01
Posiblemente la cuestión es tener claro qué quieren.
Si quieren un "scrum-waterfall" o una forma de trabajar ágil escalable.

Un scrum-waterfall no es ágil, y no va más allá de un conjunto de prácticas de ingeniería concurrente institucionalizadas.
Decir que eso es agilidad, es destruir la agilidad.

Si lo que quieren es un marco propio de agilidad escalable, eso es otra cosa. Se puede hacer pero no institucionalizando prácticas. La agilidad no está en prácticas, sino en principios.

Flexibilidad y globalidad son claves para que la agilidad sea agilidad, y organización fractal para darle escalabilidad.

En fin. En cualquier caso, soy pesimista. Creo que en estos modelos pseudo-ágiles acabarán siendo habituales.

Un saludo tocayo!
Citar
0 #1 Juan Quijano 07-05-2015 14:26
Acabo de renunciar a una formación para un gran banco que iba de eso, de enseñar un scrum waterfall... :cry:
Citar

Escribir un comentario


Código de seguridad
Refescar