SCRUM en la alta dirección de Dell

16 11 2009

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ú.

Anuncios




Podcast sobre agilidad y CMMI

9 11 2009

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

6 11 2009

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.





El rol del project manager: ¿gestor o técnico?

24 10 2009

Uno de los debates típicos en el mundo de la gestión de proyectos es si un project manager debe ser una persona técnica o no. Unos dicen que es necesario haber “luchado en las trincheras” para entender lo que significa el trabajo de campo, otros dicen que las habilidades necesarias para la programación son muy distintas a las de la gestión, por lo que promocionar un buen programador a gestor no suele ser más que una demostración más del principio de peter.

Y razón no les falta a ninguno de los dos.

En los ambientes más tradicionales (al estilo CMMI), es habitual encontrarse con gestores ajenos al mundo técnico, o gestores de proyectos industriales reconvertidos a proyectos de software. Al fin y al cabo, el estilo de gestión que propone CMMI es el mismo que se lleva aplicando hace años en proyectos de ingeniería civil, industriales, etc., por lo que un gestor de proyectos de ingeniería civil (por ejemplo), puede gestionar sin demasiado problema proyectos software al estilo CMMI.

Sin embargo, cuando introducimos la variable de la agilidad, la situación cambia. Desde mi punto de vista, un aspecto importante de la gestión de proyectos: es la empatía, eso que en castellano llamamos “ponerse en el pellejo del otro”, aunque siempre me ha gustado más la expresión inglesa “andar con los zapatos del otro”.

Esta empatía, debe aplicarse en tres dimensiones distintas, y si fallamos en una de ellas, las cosas pueden no funcionar:

  • Con los clientes: para entender sus necesidades y ofrecerles la solución más adecuada posible, que es habitual que no sea la misma que la que nos están pidiendo.
  • Con la dirección de la empresa: para entender sus exigencias y directrices y aplicarlas de forma coherente.
  • Y sobretodo con el equipo técnico: para entender sus necesidades y valorar sus opiniones, requisito imprescindible para mantener un equipo ágil motivado.

La empatía es una de esas características que vienen “de serie”: o naces con ella, o es difícil desarrollarla de un día para otro. Así que un buen gestor de proyectos debería ser alguien muy empático por naturaleza.

Ahora bien, una persona ajena al mundo técnico, ¿puede ser empática con los programadores de su equipo?  Dependerá mucho de su capacidad innata para empatizar.

Y una persona que es de naturaleza técnica ¿puede ser empática con un equipo técnico? También dependerá de su capacidad innata, aunque parece evidente que lo tendrá más fácil que el no-técnico.

Aunque parezca que lo más adecuado es promocionar a un técnico para tareas de gestión, no debe olvidar desarrollar su empatía en las otras dos dimensiones: con clientes (los técnicos no suelen practicar mucho el trato con clientes) y con la dirección (a veces, algunas de sus decisiones son difícilmente entendibles desde el punto de vista técnico, así que hay que aprender a verlas desde el punto de vista de negocio, estratégico, financiero, etc.).

Por supuesto, además de mejorar su empatía en esas tres dimensiones, el técnico promocionado tendrá que aprender otro montón de cosas de planificación, gestión de riesgos, gestión de requisitos, negociación y gestión de proveedores, aseguramiento de la calidad, medición y análisis de indicadores, etc.

Así que, sea el gestor técnico o no, si no tiene la suficiente empatía para entenderse con su entorno de trabajo, tendremos un gestor “PHB” en toda regla.





Agilismo, formalismo o ambos?

7 10 2009

A estas alturas del partido, todos deberíamos saber que no existe balas de plata, así que aunque algunos defiendan a capa y espada SCRUM, CMMI, ISO, o lo que sea, hay que tener muy presente que quizá ninguna de ellas sea la metodología o proceso adecuado para tu organización.

Una metodología se crea en un contexto, y suele funcionar bien en ese contexto, y no en otros. En el caso de las metodologías ágiles, y en concreto SCRUM, nacen en el contexto de desarrollo de productos tecnológicos, con equipos estables, motivados, multidisciplinares y de un nivel muy alto, siempre buscando aportar valor al cliente por encima de seguir un plan preestablecido. Si estás en este contexto y aplicas SCRUM, lo más probable es que tengas éxito. Si tu contexto es otro (por ejemplo, no tienes equipos estables y/o están desmotivados, o no se espera que innoves, sino que te ciñas a un plan de fechas ajustado), entonces aplicar SCRUM seguramente sea como buscar la cuadratura del círculo: además de complejo, no aporta nada útil.
Ante este panorama tenemos dos opciones:

  • Que el proceso de implantación de la metodología se convierta en un proceso global de transformación de toda la organización: si crees que lo mejor sería aplicar SCRUM, pero no cuentas con el contexto adecuado, entonces tu primer trabajo es conseguir ese contexto: convertir tu empresa en una empresa ágil: equipos motivados y multidisciplinares, dirección alineada con la visión ágil, estrategia comercial compatible, etc. En este caso, implantar SCRUM no es algo exclusivo del dpto de desarrollo, sino que se convierte en un proceso global que afecta a todos, tal y como propone Scrum Manager. Cuando veas que el contexto está cambiando, entonces introducir SCRUM puede ser un buen método conductor hacia la nueva filosofía de empresa, aplicando prácticas y métodos concretos (la forma) a una forma de ser que ya está echando raices (el fondo). Como habrás imaginado, este es el camino difícil.
  • Buscar una metodología mixta, que aunque no sea 100% ágil o formal, pueda adaptarse bien a nuestra cultura de empresa. Si por ejemplo tenemos un dpto comercial que acuerda fechas fijas y no dejan margen de maniobra para reducir funcionalidad, o no hay ningún tipo de colaboración con el cliente, sino que todo se cierra en el contrato inicial, o si por desgracia no contamos con un equipo suficientemente bueno, sino que es “lo mejor que se pudo encontrar con los recursos que teníamos” entonces, tenemos una serie de obstáculos dificilmente salvables para poner en marcha una metodología 100% ágil. Si además, la forma de actuar del dpto comercial no podemos cambiarla (porque la dirección quiere o necesita ese tipo de estrategia comercial), o si no podemos mejorar el equipo (porque la empresa no tiene recursos para contratar a más y/o mejores técnicos), entonces introducir elementos de procesos más tradicionales, al estilo CMMI o ISO, nos puede resultar mucho más útil que empecinarnos en un enfoque ágil cuando sabemos que la batalla está perdida de antemano. Utilizar prácticas y procesos “tradicionales” no es malo en sí mismo, ni anticuado, ni de gestores del siglo pasado: lo que es malo es seguir utilizándolos en aquellos contextos donde se podría llegar más lejos con otras formas más ágiles. De igual forma, las metodologías ágiles no son buenas por sí mismas, ni son cool, ni de gestores visionarios, sino que lo realmente bueno es maximizar el rendimiento de la organización al completo hasta un punto óptimo de funcionamiento, y recalco lo de “la organización al completo”, y no cada dpto por separado.

Elegir una alternativa o la otra depende de muchos factores, pero sobretodo de la capacidad de la empresa y su gente para reinventarse a sí mismos: si tus compañeros y la dirección de la empresa son capaces de cambiar su forma de pensar y actuar, entonces ya tienen mucho del espíritu “ágil”, así que posiblemente la opción correcta sea la primera. Si, por el contrario, no tienes garantías de que todo el mundo sea capaz de adaptarse a otros métodos de trabajo más flexibles y dinámicos, entonces quizá un buen comienzo sea utilizar algo más “formal”, y más adelante ir reconduciendo hacia el “agilismo” o hacia el “formalismo” según la empresa vaya adaptándose o no a los cambios propuestos.





El agilismo en su contexto

3 09 2009

Uno de los temas que más me llama la atención es el afán de algunos en aplicar el agilismo en cualquier empresa, para cualquier proyecto, en cualquier mercado, bajo cualquier circunstancia… No lo entiendo, y eso que yo he sido uno de ellos (de hecho, no me entendía ni a mi mismo).

Lo primero que hay que tener claro es el contexto en que nacieron las metodologías ágiles y qué intentaban solucionar: allá por los años 90 se creía que la única forma válida de desarrollar software era al más puro estilo ingenieril, es decir: hacer software como si fueran puentes. Ese era el camino, y no había otro (lo que mi amigo Juan llama “la tesis”)dialectica1

Entonces se reunieron unos cuantos tíos listos, todos ellos con barba, y pusieron en duda la doctrina establecida. Eran, sin duda, valientes, además de listos. La conclusión a la que llegaron es que había otras formas válidas para desarrollar software, y que los procesos ingenieriles servían para eso: para la ingeniería que se basa en leyes físicas inmutables. En este encuentro se formuló el manifiesto ágil, con sus cuatro principios, o dicho de otra forma: la antítesis.

Más que fijarme en los cuatro principios (otra gente ya los ha analizado y desmenuzado mejor de lo que yo puedo hacer), yo destacaría el contexto donde lo hicieron: Silicon Valley, la cuna de la tecnología, y donde las empresas tienen unas peculiaridades que quizá sólo se den allí. Destaco el lugar porque me parece que tiene mucho que ver en qué es y cómo se entiende el agilismo: las empresas, la gente, la sociedad, funcionan allí de una forma muy distinta a como estamos acostumbrados en otros lugaros (por ejemplo, yo desde España). Allí están más basados en la motivación, en el alto perfil técnico, en el compromiso personal (con ayuda de las stock options, claro), en proyectos muy innovadores que buscan generar valor de forma rápida, en capital riesgo capaz de invertir en tecnología, y que asume que no van a recoger beneficios en los primeros años, etc. En este caldo de cultivo, el agilismo es la chispa que genera la vida.

Pero, ¿qué ocurre si aplicamos la receta “ágil” a otro tipo de entornos menos preparados para esas ideas? Pues lo más seguro es que no ocurra nada, o lo que es peor: que acabemos con la sensación de que esto del agilismo no funciona (he visto con mis propios ojos demasiadas empresas que han acabo con esas conclusiones)

Es por eso que cada empresa necesita un grado de agilidad distinto, y se debe ir variando este tono inicial hacia otro más “puro” conforme la empresa vaya asumiendo o descartando los principios básicos del agilismo (algo que requiere tiempo). Y que conste que descartar el agilismo no es bueno ni malo en sí mismo, como todo, depende de nuestro contexto (empresa, gente, negocio, etc.). Esto es la denominada síntesis, es decir: el unir lo mejor de los dos mundos.

Desde mi humilde opinión, creo que el único camino viable es este último, y no me parece una mala idea basarnos en CMMI (u otros modelos formales como Spice) como puntos de partida para empezar el camino.





El triángulo de la metodología

24 08 2009

Uno de los temas clásicos en la gestión de proyectos es el denominado triángulo de hierro: alcance – tiempo – coste. Hoy vamos a tratar con otro triángulo distinto: el triángulo cromático.

Muchos reconoceréis la imagen de la derecha: es el sistema clásico para representar las posibles combinaciones de colores usando tres componentes: Rojo, Verde y Azul.

Ahora cambiemos los colores por lo siguiente:rgbtri

  • Rojo: Falta total de método a la hora de desarrollar software. Cada persona lo hace a su manera, sin aprender lecciones del pasado, sin repetir prácticas que parecen haber funcionado. Ni implica que el software sea de mala calidad, sino que simplemente se desarrolla con ausencia total de método.
  • Azul: método tradicional clásico: predictivo al 100%, planificación estricta (posiblemente en cascada), control ferreo del equipo, negociación contractual hasta las últimas consecuencias… digamos algo parecido al CMMI clásico
  • Verde: método ágil puro: autogestión absoluta, seguimiento adaptativo, confianza plena en el equipo y en el cliente, equipo multifuncional perfecto en tamaño, habilidades y experiencia… digamos: la metodología ágil ideal que nos proponen en los libros.

Ser un color puro es imposible, siempre hay margen para el error, alguien que no comparte ciertas prácticas, nuevas pruebas de herramientas, clientes con otras necesidades… así que nos movemos en toda la gama de infinitos colores. Y menos mal, porque que aburrido sería el mundo sólo con tres colores ¿verdad?

En el resto del espectro de colores tendríamos los siguientes grandes grupos (cada uno con sus propios matices, claro):

  • Morado-Rosa: metodología clásica que se aplica parcialmente
  • Amarillo-Naranja: metodología ágil que se aplica parcialmente
  • Verde-azulado-Cian: combinación perfecta de metodología ágil y clásica que se aplica al completo y funciona sin ningún tipo de error.
  • Blanco: mezcla de metodología clásica y ágil, con margen para el error (con mecanismos para detectarlo a tiempo) y con espacio para la creatividad, la improvisación o la “artesanía” cuando la situación lo requiera y lo permita.

Ahora… ¿dónde te sitúas tú? ¿y dónde te gustaría estar? ¿merece la pena intentar ser un color puro o lo mejor es tender al blanco?