Los hippies se ponen la corbata

Desde ya hace unos años veníamos viendo cómo los agilistas de pro se burlaban de los procesos formales, a la vez que los señores consultores encorbatados de CMMI miraban con cara de póker a esos locos de la agilidad. Dos mundos, dos filosofías, dos enfoques antagónicos, dos formas radicalmente distintas de plantear soluciones, a veces a problemas distintos.

Pero algo me dice que esto está cambiando.

• Casualmente un amigo está pasando el verano en un intership en el SEI. El caso es que allí está trabajando con Mark Paulk, uno de los históricos del lugar, y en un correo me comentaba su acercamiento e interés por las metodologías ágiles. De hecho, ya lleva tiempo muy volcado en ellas. Y casualmente, la última versión de CMMI (1.3) da un paso de gigante hacia la agilidad, adaptando prácticas para hacerlas más compatibles con metodologías como Scrum (no conozco en profundidad en qué puntos concretos se han producido estos acercamientos, así que si alguien nos pone un comentario sobre este tema, será estupendo)
• Por otro lado, llevo unos días leyendo comentarios sobre la nueva versión de The Scrum Guide (por así decirlo, la guía oficial). Y me llama la atención algo que podría ser anecdótico: la desaparición de cerdos, gallinas y demás fauna (como comenta muy acertadamente José Vázquez en su blog). Y es que para mi, hay un fondo que va más allá de la anécdota: lo que yo leo entre líneas es que le están poniendo el traje y la corbata a Scrum. Y esto no tiene ninguna connotación negativa (hippies del mundo: el hábito no hace al monje), sino que, simplemente, para entrar en ciertos ambientes corporativos, es necesaria cierta parafernalia. Algo así como la media etiqueta de los casinos. Scrum quiere dejar de ser algo de freaks y empezar a verse como algo serio y riguroso (bueno, lleva siéndolo desde el principio, pero algunos confunden el fondo con las formas).

Y es que yo veo la tendencia clara: la tesis (procesos formales) y la antítesis (agilidad) empiezan a converger en una síntesis, tal y como venimos vaticinando desde hace tiempo en Scrum Manager.

Y como en todo, habrá gente a la que esto no le haga ninguna gracia, además de que la agilidad ya es mainstream y ha dejado de tener “su aquel”: que si ya no es lo mismo, que si se está burocratizando, que si la abuela fuma, bla bla bla. Para ellos, es el momento de buscarse otra cosa que luzca mejor en el currículum (;

Tengo un jardín Zen. Ya soy monje budista

Nota preliminar: este post es un post-respuesta de este otro de mi amigo Juan.

Hace unos días me topé con unos de esos “kit zen” que tan de moda están. De esos que se ponen en la mesa de la oficina: con su bolsita de arena fina, su rastrillo, piedritas… y que se supone que te salvarán durante tu próxima crisis de ansiedad.

El caso es que lo primero que me vino a la mente, es por qué tenemos la manía de copiar las formas, esperando que, gracias a ello, nos llegue la esencia que ese signo representan. Así, como por arte de magia.

¿Hay alguien que se crea que por montar un jardín zen, vamos a sentir las sensaciones (y beneficios) de un monje budista, que lleva toda su vida interiorizando los principios básicos de su filosofía de vida? ¿Nadie ha caído en la cuenta de que “las formas”, muchas veces, son meros rituales que tienen su utilidad para el que entiende y vive los principios, pero están vacías para el resto?

Pues eso, que por tener post-its y burndowns colgados de la pared, haber pagado a un consultor ágil “de los conocidos” para aleccionar a nuestros equipos, por tener un hudson compilando como un loco a todas horas… no presumas de ser ágil, quizá solamente lo parezcas, y hasta tú mismo te lo crees.

Y lo mismo en procesos formales: tener un bonito Gantt, con evidencias de su seguimiento, o una hoja de riesgos del proyecto, con sus planes de mitigación y contingencia, quizá te sirvió para tranquilizar a tu evaluador CMMI (doy fé) pero no significa que tengas control sobre tu proyecto.

Agilizando CMMI en el CITIC de A Coruña

Hace unos días, estuve dando una charla en el CITIC, en la A Coruña, gracias a la invitación de Mario.

Sí, ya lo sé, es la charla de siempre, que soy muy pesao, pero que conste que siempre la adapto al contenido que me piden y el tipo de audiencia que va a asistir. Básicamente reutilizo fotos y diapos, pero el flujo, la cadencia y la trama cambia mucho de una a otra.

Si algo tuvo de especial esta ocasión fue el lugar (Galicia… me encanta… y menudo pulpo que me zampé) y sobre todo, la persona que me invitó: ya tenía ganas de tomar una caña con alguien como Mario, una persona que destila experiencia a raudales y con quien aprendes un montón simplemente en una charla de una hora.

A continuación las slides, que como otras veces, no dicen mucho si no se escuchan en directo.

Eme de Madurez

Llevo tiempo sin escribir nada, mil perdones, pero es que un pequeño mocoso a llegado a casa y mi tiempo disponible tiende a cero. Vamos, que he sido padre por segunda vez y el blog, las actividades extra y mis ojeras han pagado las consecuencias.

Y aprovechando las circunstancias, voy a comentar algo de lo que me estoy dando cuenta, ahora que soy padre “segundizo”, pero que puede resultar obvio: Cuando tienes tu primer hijo, la improvisación y la adaptación reinan en tu vida: no hay planificación ni horarios y las tareas más triviales se vuelven una aventura.

Situación típica: vas a cambiar un pañal, ya tienes al niño preparado y “en bolas”, y de repente te das cuenta que te has dejado el pañal limpio en la otra habitación. No puedes dejarle solo porque se cae, así que le agarras en volandas (culo al aire) y le llevas a la otra habitación para coger el pañal limpio. Lo más normal es que entre el tiempo que tardas, el cambio de temperatura, y la postura, al niño le entren ganas de mear, así que ya tienes tres problemas: 1) limpiar al niño y ponerle el pañal (problema original), 2) cambiarte tú porque a tu hijo le ha dado por regarte 3) limpiar el suelo y/o pared. Aunque pueda parecer cómico, los que seáis padres entenderéis que cuando te pasa, te entra de todo menos risa.

Sin embargo, la experiencia sirven para algo, así que pasados unos meses (o cuando tienes otro hijo), estas cosas están más que planificadas y la ejecución es perfecta: preparas todos los enseres, te aseguras que no falta nada, coges al niño, le cambias rápidamente, colocas al niño otra vez en la cuna y recoges todo. Perfecto.

Está claro que la diferencia entre uno y otro es la madurez como padre. El padre inmaduro improvisa y se adapta a las circunstancias, y el padre maduro planifica y ejecuta sin salirse del plan.

Si extrapolamos la vida como padre al mundo de la empresa, veremos que es muy parecido. Una empresa inmadura (lo que se suele conocer por startup), tiene que improvisar y adaptarse para sobrevivir: se adaptan al mercado (porque no consiguen vender lo que esperaban), adaptan su tecnología (porque no es tan últil como se pensó), adaptan el modelo de negocio, en definitiva: se mueven rápido para sobreponerse a los imprevistos.

Sin embargo, una empresa madura, no tiene esa necesidad de adaptación continua: tienen claro el modelo de negocio, tienen claro el mercado en el que operan, tienen claros sus procesos de trabajo… en definitiva, planifican su trabajo y después lo ejecutan (siempre con matices, porque una empresa, por muy madura que sea, tiene que adaptarse continuamente a los cambios del mercado, y si no, que se lo digan a algunas en tiempos de crisis).

Llegados a este punto, creo que se ve claramente a donde quiero llegar: no construyas el edificio antes de tener claro dónde lo quieres. No tiene sentido construir un montón de procesos definiendo la forma de trabajar en la empresa (estilo CMMI), cuando todavía posiblemente no sabes cuanto tiempo seguirás haciendo ese tipo de trabajo. Lo más probable es que pasados unos meses, tengas procesos para hacer X, cuando en realidad has acabado haciendo Y. Es mejor establecer lo mínimo, introducir prácticas concretas y sencillas, e ir modificándolo y asentándolo conforme la empresa vaya madurando. Es decir: partir de la agilidad, para llegar a cierto nivel de procesos, y no al revés.

Motivación extrínseca vs intrínseca

Me encuentro hoy con este post de mi amigo Juan y la verdad es que después de disfrutar del video, no puedo decir más que ¡revelador!

Si tienes 20 minutos libres, escucha esta charla, y si no los tienes guarda este post y vuelve cuando los tengas. ¡En serio!

Se tuviese que elegir una cualidad de la gente con la que trabajo, no lo dudaría ni un segundo: auto-motivación. Me daría igual que sean ingenieros de pro, que tengan 25 años de experiencia en multinacionales de prestigio, que dominen tal o cual tecnología, o que siempre lleguen a las fechas de fin de proyecto… un profesional desmotivado es como un diploma colgado de la pared: sirve para lucirlo, pero no es garantía de nada.

Lo realmente revelador del video no es eso (que más o menos todos sabíamos o intuíamos), sino que la motivación no se puede forzar, tiene que surgir espontáneamente, y sólo surgirá en un caldo de cultivo que cumpla con ciertas premisas:

1. Autonomía: puedo elegir mi propio camino
2. Maestría: quiero ser cada día un poco mejor en aquello que me importa
3. Propósito: aquello que hago se engloba en un gran proyecto, más allá de mis propio intereses

Está claro que los ambientes ágiles están mucho más alineados con esta filosofía (de hecho, yo creo que son una implementación práctica de esta filosofía) y los procesos formales suelen ser la antítesis: falta e autonomía (el proceso dice lo que tienes que hacer), falta de maestría (lo importante es cumplir con la planificación, y no sentir que estás produciendo algo de calidad) y propósito (en grandes procesos/empresas, ni siquiera sabes qué papel juegas tú dentro del todo, ni siquiera sabes si eres peón o alfil).

Presentación URJC

Como ya os comenté, la semana pasada estuve en una de las clases de @jgarzas, en la Universidad Rey Juan Carlos de Madrid, comentando la experiencia que tuvimos en Unkasoft de “agilizar CMMI”.

La charla fue muy bien, los alumnos bastante interesados en el tema, incluso más que en otras universidades en las que he estado.

La pena es que nos faltó algo de tiempo para más preguntas y alargar el debate.

A continuación podéis ver la presentación. Por el modo que tengo de hacer presentaciones, las diapositivas por si solas no dicen gran cosa (lo siento), así que si alguien tiene alguna duda, puede preguntarlo sin problemas.

“Agilizando CMMI” en la Universidad Rey Juan Carlos

Gracias al compañero Jarvier Garzás, el próximo día 14/12/2009 estaré por la URJC (Madrid) charlando sobre los temas que solemos tratar en este blog: procesos CMMI, agilidad y cómo combinar lo mejor de ambos mundos.

Será una charla con doble personalidad: por un lado como colaborador de Scrum Manager, explicando los conceptos de procesos, agilidad y “scrum management”, y por el otro contando algunos “trucos” prácticos de la implantación que hicimos durante el año pasado en Unkasoft.

En principio, está orientada a estudiantes y profesores de la universidad, pero si alguien está especialmente interesado, que me lo comente (en los comentarios, por twitter, por mail a jm[ARROBA]scrummanager.net o con señales de humo), y veremos que podemos hacer.

SCRUM en la alta dirección de Dell

Hace algunas semanas me enteré (tarde, como siempre) de que Gabriel Cerrada, director de Dell para España, dejaba la compañía.

Esto me ha recordado una anécdota que me ocurrió con él y que está muy relacionada con la temática de este blog.

Hace más o menos un año, tuve la suerte de asistir a la entrega de premios que ganó la empresa en la que trabajo. En la comitiva española íbamos dos personas de mi empresa y dos directivos de Dell: Pedro Fernández de Córdoba director de márketing para España, y Gabriel Cerrada, director general y consejero delegado para España y Portugal. Gabriel es (bueno, ahora tengo que decir que “era”) un peso pesado en Dell: además de dirigir todas las operaciones de Dell en España y Portugal, tenía responsabilidades en otras plantas (Marruecos, Italia, etc, si no recuerdo mal).

El caso es que en medio de una conversación, llamaron a Gabriel al teléfono y se tuvo que ir a atender la llamada. Después de un buen rato volvió y disculpándose dijo: “Perdonad, pero es que tenía la reunión semanal de dirección. Ya sabéis, lo típico: qué hemos hecho esta semana, qué vamos a hacer la próxima, problemas han surgido…”

Creo que yo no pude disimular la sorpresa, porque la verdad es que de la última persona de la que me esperaba una frase así es de un alto directivo de una mega-empresa como Dell.

Madurándolo durante los días siguientes, la moraleja que saqué es que las prácticas que proponen las metodologías ágiles (y SCRUM en particular) no son tan innovadoras como solemos (o queremos) creer: vienen de años de experiencia en otras empresas y éxitos en la gestión de muchos tipos de proyectos. Algunas se han ido adaptando a las peculiaridades de la gestión de proyectos de software, y otras se han tomado tal cual y así permanecen.

Así que la próxima vez que te sientas un innovador por utilizar SCRUM, piensa que no estás usando más que un compendio de buenas prácticas que otros muchos ya han usado y probado ante que tú.

Podcast sobre agilidad y CMMI

Desde hace algún tiempo vengo colaborando con mi amigo Juan Palacio, en la comunidad Scrum Manager.

Una de las actividades que realizamos es publicar una serie de podcasts que trata de diversos temas relacionados con el mundo de las metodologías ágiles: equipos ágiles, gestión ágil, etc.

En esta ocasión he participado dando mi visión y experiencia sobre el tema de CMMI combinado con agilidad.

Espero que sea útil y cualquier crítica constructiva es bienvenida!

Para escuchar el podcast, puedes hacerlo desde esta página.

La agilidad sin control no vale para nada

Hace unos años en España, se puso de moda un anuncio de una marca de neumáticos que decía que “la potencia sin control no sirve de nada”. Y hoy, leyendo este post de alguien que trabaja en una empresa “tradicional”, me viene a la mente de algo que vengo pensando hace ya mucho tiempo: que la agilidad sin control no sirve de nada.

Cualquiera que haya leído sobre el agilismo, se habrá empapado de sus principios básicos: colaboración de todos con todos, motivación del equipo, adaptación al cambio, buenrrollismo institucionalizado, oficinas cool, etc. Todo esto está muy bien, pero podrás llevarlo a cabo si se cumple una premisa: que exista confianza. Sólo si confías hasta las últimas consecuencias en tu equipo, en tus clientes, en la dirección de tu empresa, etc., puedes aplicar el agilismo puro sin riesgo a que ocurra una catástrofe.
Pero ¿qué ocurre si no puedo confiar en todos al 100%? ¿Y si tengo clientes que no respetan lo pactado? ¿Y si la dirección presiona de forma insostenible hasta abortar los sprints? ¿Y si tengo un equipo que no está motivado y/o no cumple con aquello a lo que se compromete? Entonces entra en juego el lado oscuro de la fuerza: el control.

¿Cómo se puede compatibilizar el control con una filosofía tan abierta y libre como el agilismo? Las propias metodologías ágiles establecen mecanismos de control, aunque muy sutiles, y a veces disfrazadas para que nadie se sienta controlado: por ejemplo el scrum diario, donde el scrum master vigila el cumplimiento de la metodología, revisa la desviación respecto a las estimaciones, hace seguimiento de los impedimentos, etc. O la demostración de fin de sprint, donde el product owner verifica si se han cumplido los hitos con los que el equipo se había comprometido al inicio del sprint. O un proceso de integración continua, que no es más que un mecanismo de control del código a través de test unitarios, análisis estático del código, pruebas de rendimiento, etc.

Además, es típico pensar que el control es un concepto de dos estados: control ferreo (procesos clásicos como CMMI, SPICE, etc). o libertad absoluta (metodologías ágiles, ambientes googleros, etc.) y esto no es del todo cierto. Es verdad que procesos formales como CMMI tienen el control metido en su propia esencia, y metodologías ágiles hacen los mismo con la confianza, pero eso no significa que no se pueda modular tu proceso para acercarlo más a tus necesidades. Por eso, una de las responsabilidades del project manager, o del responsable de mantener y establecer los procesos, es decidir qué nivel de control es necesario para llegar a buen puerto e ir adaptándolo conforme evoluciona el proyecto, el cliente, el equipo, la empresa, etc.

Más de una vez y de dos me ha ocurrido que un programador, firme defensor de los modelos ágiles, se ha ofendido cuando el scrum master ha ido a pedirle explicaciones sobre algún tema. ¡Me estás microgestionando! ¡Esto no es ser ágiles! Pues perdona pero no, ser ágiles no es sinónimo de “hago lo que me da la gana y no doy explicaciones a nadie”, sino ser un buen profesional en el que poder confiar, asumir que el objetivo último del agilismo es ofrecer mejores resultados (y no tener lámparas de lava en la oficina) y entender que el desarrollo de software es un juego de equipo y por lo tanto los aciertos y errores de cada uno afectan y deben ser conocidos por los demás.

Me encantaría que existiesen más proyectos sin ninguna necesidad de control, pero la realidad real me dice que es una utopía, hacia la que caminar, pero utopía al fin y al cabo.