Diapositivas y vídeo de la presentación de Scrum Manager en Agile Lean Day Chile 2009

agile_lean_day_chile

Están disponibles, con muy buena calidad por cierto,  las presentaciones y los vídeos de todas las ponencias que se presentaron el pasado en el AgileLeanDayChile 209, entre ellas, la que hizo Claudia Ruata del proyecto Scrum Manager.

  • Casos de Éxito

Proyecto ProAud: Ricardo Jara (Continuum, Chile)
NameAction: Philippe Camacho (Leansight Consulting, Francia)

Motivación: mejor intrínseca que extrínseca

Scrum Manager bit: La motivación extrínseca es adecuada en trabajos relativamente mecánicos y entornos industriales, pero puede ser contraproducente en empresas del conocimiento.

Ambiente Industrial Campo de Scrum
Los principales responsables de la calidad del resultado son los procesos y la tecnología Los principales responsables de la calidad del resultado son las personas
Fábrica

cc by cloneofsnake

campo_scrum

cc by Dan Zen

Las personas ayudan a los procesos y la tecnología Los procesos y la tecnología ayudan a las personas
La mayoría de principios y prácticas de gestión en cualquier nivel y en sus relaciones (empresa, proyecto o producto) son diferentes.
La motivación extrínseca es una prescripción relativamente válida para los primeros, y  normalmente contraproducente para los campos de Scrum.

Safe Creative #1001035242501

Liderar como los grandes directores de orquesta.

En esta conferencia Itay Talgam nos desgrana distintos estilos de dirección de orquesta, totalmente trasladables a la dirección de proyectos o empresas:

Un director de orquesta afronta el máximo reto de liderazgo: crear armonía perfecta sin decir una palabra. En esta encantadora charla, Itay Talgam muestra el estilo único de seis grandes directores del siglo XX, ilustrando lecciones cruciales para cualquier líder

Puedes ver el vídeo con subtítulos en español o inglés desde la web de TED.

Itay nos va llevando por distintos tipos de liderazgo, desde el más autoritario de Riccardo Muti, cuya descripción cierra con la anécdota de la petición realizada por los 700 músicos de La Scala para que dimitiese, hasta el último cuyo nombre no dice y que no reconozco, que dirige a la orquesta solo con los movimientos de su cara.

Itay va avanzando, director a director, en el grado de excelencia en la dirección, no como posición autoritaria sino como facilitador. Veamos los pasos que nos muestras:

  • Riccardo Muti, autoritario, explícito, no deja espacio para que los músicos se desarrollen y estós terminan pidiendo su dimisión.
  • Richard Strauss, deja que todo suceda por sí mismo, sin interferir, pero dentro de un espacio delimitado, sin muchas opciones a la creatividad.
  • Herbert von Karajan, dirige sin dar instrucciones, la música está en su mente, “el peor daño que podría causarle a mi orquesta es darles una instrucción clara porque eso impediría la unión, escucharse unos a otros, lo cual es necesario en una orquesta”, llega a manifestar en una ocasión. Es un control muy espiritual, pero sin embargo firme, que causa una gran presión a los músicos que deben descifrar los mensajes del director.
  • Carlos Kleiber tampoco da instrucciones, en su lugar abre un espacio para que los músicos añadan otra capa de interpretación. Carlos conduce la representación disfrutando, viviendo la música. Cada músico sabe lo que tiene que hacer y se crea un espacio de compañerismo. Pero no solo motiva, también mantiene la autoridad ganada por su profesionalidad. Kleiber no solo crea un proceso, crea las condiciones para que ese proceso fluya. Todo esto es muy emocionante para los músicos, para el equipo.
  • Lenny Bernstein, el profesor de Itay, es otro ejemplo de dejar fluir a los músicos, de disfrutar y transmitir ese gozo. Si amas algo, déjalo ir dice Itay que le dijo una vez su amigo Peter y aquí lo utiliza para describir a Kenny Bernstein.

No he podido evitar pensar en los modelos de dirección de proyectos y en el proceso y las condiciones que se crean en las metodologías ágiles. Aunque esta forma de dirigir o gestionar no es exclusiva de SCRUM o del agilismo si es una de las características inequívocas de estas metodologías y una de las causas también de sus éxitos. ¿Son Kleiber o Bernstein SCRUM conductors?

Gracias a José de la Peña por la referencia de la conferencia.

¿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?