El compromiso del equipo

Escrito el 26 de Enero de 2009 a las 13:06 

A lo largo de todo el pasado año hemos trabajado con muchas empresas relacionadas más o menos directamente con el mundo del desarrollo del software. Así, hemos pasado por operadores de telecomunicaciones, grupos editoriales, software factories puras, desarrolladores de videojuegos, empresas de contenidos, empresas de comercio on-line, “serenos” (de portal en portal ;-) ), desarrolladores de productos software, empresas de software libre, integradores, consultoras… Y en ellas nos hemos encontrado todo tipo de equipos, lo que nos ha proporcionado una visión privilegiada de lo que funciona y lo que no, lo que va bien y lo que va mal, los denominadores comunes y las singularidades maravillosas.

En tal panoplia de escenarios hemos implantado con difrerentes niveles de profundidad y éxito muchos tipos de herramientas y metodologías, siendo nuestro “producto estrella” la consultoría ágil y la implantación de Scrum como metodología de gestión de proyectos. Aquí, señores, debo decir que hay equipos que lo pillan y equipos que no. A nivel individual, Ken Schwaber estima en “The enterprise and Scrum” que un proyecto de implantación corporativa de cualquier iniciativa “Agile” debería estar dispuesto a dejar ir hasta al 20% de la plantilla. Mi experiencia confirma la cifra a partir de determinado tamaño de empresa (típicamente 40-50 desarrolladores o más).

Una importante parte de este 20% de seres impermeables a la filosofía Agile suele estar compuesta de inmobilistas, tradicionalistas y escépticos, es decir, lo normal en cualquier proceso de gestión del cambio. Pero hay otra parte que comienza con cierto entusiasmo en esto de Agile, por aquello de la autogestión del equipo, que el Dueño de Producto no deba intervenir en los Sprints, que las fechas más o menos las pongan ellos (ya que son los que dan las estimaciones y deciden cuánto puedes hacer por Sprint), que no se puedan introducir cambios “al tun-tun” sino que deban hacerse al principio de los nuevos Sprints (y generalmente a cambio de otras funcionalidades o compromisos), la comunicación cara a cara… Guay.

Pero señores, no nos engañemos: Scrum y Agile no son “buenrollismo institucionalizado”, al igual que XP no es “hacking institucionalizado”. Me viene a la mente la anécdota del autor del libro “Balancing Agility and Discipline” (creo que fue este), al que, en la presentación del mismo, se le plantaron los Popes y Gurus de Agile a preguntarle que quién le había dicho a él que Agile no era disciplinado. De hecho, somos los tíos mas disciplinados del mundo. Planificamos a diario. Reportamos a diario. Entregamos continuamente. Nos comunicamos constantemente. Progresamos en orden de prioridad… ¿Sigo?

Y eso es lo que algunos equipos no pillan: que todos estos componentes de “buenrollismo” tienen un precio. A saber: desarrollaréis el trabajo en el orden que yo, cliente o Dueño de producto, determino. Me reservo el derecho de aceptar o rechazar el resultado del trabajo, pues yo soy quien tiene la visión y debo deciros si nos acercamos o no a lo que tengo en mente. Debéis reportar y aportar visibilidad a diario sobre el estado del proyecto, pues si no deberé intervenir e interrumpir para saber qué está ocurriendo. Y debo ver compromiso, rendimiento, en definitiva: entregas. Es un precio que muchos pagamos con gran satisfacción y convencidos de que merece la pena el esfuerzo.

Pues bien, cuando ponemos la ecuación completa en juego (que es lo que funciona de verdad), en estos equipos de los que hablábamos comienzan los problemas:

Como comprenderéis, ante un panorama como este hay muy poquitas cosas que se puedan hacer. ¿Se os ocurren algunas? ;-)

Categorías: Gestión, Gestión de Proyectos
Tags: ,,,,,,,
6 comentarios | Compártelo

Buscar:

Suscriptores:

Kisei Dojo Aikido

Pastafari!

Tags

Que se dice por aquí:

Qué se dice por ahí:

Twitter

    Fotos

    www.flickr.com
    angel.medinilla fotos Más fotos de angel.medinilla
    Cerrar
    Enviar por Correo