El compromiso del equipo

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:

• No quiero hacer Scrum diario: es una forma de control y, como toda forma de control, coharta la libertad del individuo. Idem para el tablón Scrum y el diagrama de Burn Down
• ¿Que qué voy a hacer hoy? Pues estaré “con lo del cliente A”. No puedo dar más detalles, porque eso sería interferir con el equipo. No, no puedo decirte con qué tarea me pongo, ya te hemos dicho que el tablón es microgestión y fiscalización. Las cosas estarán cuado estén. ¿Es que no confías en mí?
• No controles mis entregables: si me corriges, me estás microgestionando. Si yo, que soy el que sabe de esto, digo que el producto está bien, es que el producto está bien. ¿Quién eres tú para contradecirme? Además, ¿por qué hablas tú directamente con el cliente final? Eso es que no confiais en mí. ¿Que el cliente quiere otra cosa? Bah, el cliente no tiene ni idea.¿Que hay que cambiar algo? Haberlo dicho antes, ya no se puede.
• No puedo dar estimaciones. Si doy estimaciones y luego no se cumplen, vendrás a perseguirme. Si me acorralas, triplicaré mis estimaciones para ir sobre seguro.
• Si, vale tu prioridad es la historia uno. Pero la quince es más bonita, la veinticuatro más divertida, la setenta y tres más fácil y la ciento dieciocho simplemente me apetece más. Ah, y hemos metido siete historias que a tí no se te habían ocurrido pero que nosotros estamos convencidos de que son importantísimas.
• Y, bueno, dije que iba a tener tres historias y solo hay una. No ha dado tiempo, que se le va a hacer. ¿Que en qué hemos invertido las horas? Ah, no, eso es control y fiscalización y va en contra de Agile. ¿Que a partir de la semana vamos a cumplir los horarios estríctamente? Eso va en contra de la política de flexibilidad horaria de la empresa. ¿Es que no confías en nosotros? (again)

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