Etiqueta: xp coach

Scrum Master, XP Coach, el Cholo Simeone y el maestro Tabarez

Creo que la primera ver que escuché el término coach fue viendo un partido de bastket de la NBA. Más aún estoy casi seguro que fue allá en los 90′ en un partido de Chicago Bulls donde el coach era Phil Jackson. En castellano el término es entrenador.

Años más tarde cuando me metí en el mundo de Extreme Programming (XP) me encontré con el término XP Coach. Al poco tiempo cuando conocí Scrum me encontré con el Scrum Master que es común considerarlo un Coach del equipo Scrum. Existe incluso bibliografía que menciona al Scrum Master como un análogo al XP Coach. En este sentido me parece relevante destacar un par de importantes diferencias:

  • El rol de Scrum Master es mandatorio en Scrum, mientras el XP Coach es opcional en XP. La bibliografía no dice que un equipo de XP deba tener un Coach, sino que en general se recomienda tener un XP Coach cuando el equipo está empezando a usar XP.
  • No se considera imprescindible que el Scrum Master tenga conocimientos técnicos, cosa que sí es requerida para un XP Coach.

En línea con este segundo punto y pensando en la analogía deportiva de coaches imagino al maestro Tabárez como Scrum Master y al Cholo Simeone como XP Coach. Ambos son coaches, pero da la sensación (por edad y estado físico) que de ser necesario el Cholo se pondría los botines y saltaría a la cancha junto a sus jugadores, cosa difícil de imaginar (al menos en la actualidad) del maestro Tabárez.

Hay veces que es mejor decir que No

Hay veces que es mejor decir que No

Hace un tiempo me contactó un cliente para pedirme que le de una mano acompañando a uno de sus equipos en un proyecto que estaban por empezar. Me adelanto algo de información por mail y agendamos una call. La información del mail ya me levanto algunos warnings: un proyecto de 3 meses con 12 personas en el equipo de desarrollo (demasiada gente apilada en para tan poco tiempo).

La idea del cliente era que yo colaborara haciendo coaching del equipo pues tenían la intención de realizar varios ajustes en la forma de llevar a cabo el proyecto incorporando prácticas ágiles. Ya en la call el cliente comentó que las fechas estaban fijas y que el alcance también estaba bastante fijo. A esta situación se sumaron dos factores importantes: el equipo de desarrollo estaría distribuido y el proyecto era de vital importancia porque era el primero con un nuevo cliente y el éxito de este proyecto definiría la realización o no de siguientes proyectos.

Si bien el proyecto parecía desafiante decidí no aceptarlo porque me pareció que no se daban las condiciones para hacer coaching (al menos como a mi me gusta hacerlo). Cuando acompaño a un equipo (no me gusta el término coaching, me gusta más hablar de acompañamiento) trabajo en la mejora del equipo y eso implica un proceso de aprendizaje que requiere tiempo para experimentar y posibilidad de equivocarse. Pero este proyecto que me proponía el cliente no contaba con un contexto favorable para experimentación y aprendizaje, había una presión muy fuerte para el éxito del proyecto y un conjunto de restricciones que limitaban mucho el margen de acción ante imprevistos y equivocaciones.