¿Modelo de Madurez de la Capacidad de los equipos?

equipo_baloncesto_1909Con el principio de calidad de Juran, el protagonismo del resultado lo tienen los procesos: “La calidad del resultado depende de los procesos empleados en su fabricación”

Con el principio de agilidad, el protagonismo del resultado lo tienen las personas trabajando en equipo: “Preferimos el valor de los individuos y su interacción, por encima de los procesos y las herramientas”

La apuesta de aplicar el primer principio para mejorar los resultados de la fabricación de software, viene desarrollando desde los 90 modelos de “Madurez de la Capacidad de los Procesos” (CMM’s) tomando por capacidad de un proceso, el grado de eficiencia con el que logra el resultado que se espera de él.

Parece lógico pensar que sobre el principio de agilidad se debería desarrollar la “Madurez de la Capacidad de los Equipos”  (MMCE… ¿Modelo de Madurez de la Capacidad de los Equipos?)

Aunque pueda parecer lo contrario, los procesos son fáciles, la agilildad no.
Aplicando las prácticas del modelo CMMI se logran los objetivos de las áreas de procesos y con ellos, procesos de alta capacidad.
Aumentar la capacidad de las personas, y de éstas trabajando en equipo es algo más complicado. Aplicando prácticas ágiles no se logran equipos de alta capacidad.

La agilidad sin control no vale de 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 no hay nada más lejos de la realidad. Entre el control absoluto y la libertad total hay muchos niveles, y una de las responsabilidades del scrum master 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, 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 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.

Y tú, ¿has llegado ya al horizonte de la utopía? ¿O al menos has encontrado un camino más directo para ella?

Agile Project Manager: ¿técnicos o gestores?

Uno de los debates típicos en el mundo de la gestión ágil de proyectos es si un gestor de proyectos 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. empatia

Sin embargo, desde mi punto de vista, estamos olvidando un aspecto importante: una de las cualidades más importantes para el gestor 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 no funcionarán:

  • 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 ágil, 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.

Y tú, ¿crees que la empatía es algo esencial para el gestor de proyectos ágiles, o simplemente lo ves como algo opcional?

¿Agilismo o formalismo?

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 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 continua 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 ágiles, 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.

La empresa como “campo de Scrum”

¿Por qué no aplicar Scrum en toda la empresa considerando a la organización en su conjunto, como un todo sistémicamente relacionado?

¿Por qué acomodar la empresa a la “forma” del modelo?: Sea la forma de Scrum o de DSDM o de CMMI. ¿Por qué no considerar a las formas como lo que son, y emplear los fondos de conocimiento que hay tras ellas para componer un modo de trabajo apropiado a las características de la empresa y de sus proyectos?

Scrum puede “implantarse” (forma) o “institucionalizarse” (fondo); y proporciona mayores cotas de agilidad cuanto más ágil es la empresa en su conjunto.

Poner un ScrumMaster en el departamento de programación de una empresa con visión y cultura apuntando en otra dirección, o sencillamente sin visión; con un área de RR.HH. no alineada hacia una gestión de personal ágil (gestión del conocimiento); con un departamento de marketing o de producto sin implicación en roles de propietario de producto; con áreas administrativas y comerciales trabajando sobre patrones de contratos de planificaciones cerradas… es una combinación peligrosa que suele producir empresas fragmentadas.

Más que aplicar una “forma” para el área de desarrollo se trata de gestionar la empresa en su conjunto desde los principios de agilidad. Es más una tarea de “Scrum Manager” que de “Scrum Master”.

Scrum Management

Continue reading “La empresa como “campo de Scrum””

Algunos mitos en la gestión de proyectos

Claudia Ruata, Agustín Villena y Juan Palacio charlan sobre algunos mitos de la gestión de proyectos: cuestionando la utilidad de los documentos de requisitos exhaustivos y de planificaciones y gráficos Gantt detallados al iniciar un proyecto, cuando los clientes se mueven en escenarios rápidos. De documentos que intentan cerrar con negociación, lo que en realidad necesita investigación…

Ir a descargar