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.

Sobre la Agile Practice Guide

Sobre la Agile Practice Guide

Recientemente en un charla con un estudiante surgió el tema de la “documentación oficial de Agile”. Con esto el alumno apuntaba a algo así como PMBoK o el SWEBoK pero de Agile. Esa consulta me motivo a escribir estas líneas.

En primer lugar lo que tenemos es el manifiesto ágil que dice y de forma bastante genérica (pero lo que dice es importante). Por otro lado tenemos libros sobre métodos y prácticas específicas escritos por sus propios autores (obviamente también hay libros escritos por terceros, pero el hecho de que estén escritos por los autores podría llegar a darle un peso diferente). Un ejemplos de esto son los libros de Beck sobre XP y TDD. En el caso de Scrum tenemos la Guía Oficial de Scrum escrita por Schwaber y Sutherland y avalada por varias “organizaciones de Scrum”.

Pero más allá de métodos en particular, existe la Agile Practice Guide, un libro de unas 180 páginas publicado hace un par de años. El mismo surgió de un esfuerzo conjunto del Project Management Institute y la Agile Alliance. Esta guía es de acceso gratuito para los suscriptores de la Agile Alliance (y estimo que también para los del PMI) pero también puede comprarse en Amazon.

Debo admitir que antes de leerla tenía cierto prejuicio sobre su utilidad y el nivel de “humo”. A pesar de eso, la leí y me sorprendí. Personalmente no me aportó mucho pero creo que puede ser un punto de partida intersante para gente que recién se acerca a agile. Más aún, en un punto creo que podría ser una lectura obligatoria. Me pareció muy sano que el primer capítulo es muy explícito sobre las limitaciones de agile en el sentido de que:

  • no es una bala de plata
  • no aplica a todos los contextos/proyectos
  • requiere de ciertas pre-condiciones

Por otro lado también debo decir que tiene un foco en temas de gestión. Apenas menciona a la pasada algunas prácticas técnicas y sin entrar en detalle en ninguna de ellas.

Algunos puntos interesantes que incluye esta guía y que me parece vale la pena destacar son:

  • Trata el tema métricas
  • Dedica una sección importante al modelo de equipo haciendo incapié en Servant Leadership y hablando incluso del rol de Project Manager
  • Provee algunas herramientas de assessment

Agiles 2019: un espacio para los autores latinoamericanos

Agiles 2019: un espacio para los autores latinoamericanos

Tanto en la conferencia Agile, organizada anualmente por la Agile Alliance, como también en la XP, suele haber un espacio de “librería” donde se venden libros de los oradores de la conferencia y también clásicos de agile.

Me gustaría ver algo así en Agiles2019 pero con una vuelta de rosca.

Dado que en la comunidad Agile de Latam hay varios autores de libros de sobre agile y afines, planificaría una sesión (estableciendo de antemano día, horario y sala) para que cada autor presente su libro en 5 minutos (tipo lightning talk). Luego de la sesión cada autor podría vender o regalar sus libros.

Para que esto ocurra es necesario que la organización haga dos 2 cosas:

  1. Difundir la idea ANTES de la conferencia para que cada autor pueda preparar su lightning talk y también para que pueda organizarse para llevar libros en formato físico o para subirlos a algún medio digital.
  2. Reservar el espacio en cuestión (tanto físico como a nivel agenda)

Me parece que en términos de costo/beneficio esta iniciativa sería muy positiva:

  • El costo para los organizadores es mínimo (yo mismo me ofrecería a hacerlo si me dieran acceso a la lista de participantes).
  • Me parece que también es bueno para que los autores puedan difundir su obra
  • Creo que es un aporte de valor para los asistentes, ya que los libros en castellano sobre agile no tienen gran difusión y escuchar sobre un libro de la voz del propio autor creo que siempre suma.
  • Finalmente, si esta sesión se hiciera el primer día de la conferencia podría funcionar como disparador de otras sesiones en torno a alguno de los libros presentados.

Como realmente quisiera ver esto materializado, ya le escribí al grupo organizador de Agiles 2019 para ver si puedo conseguir su apoyo para llevar esto adelante.

Preparando sesiones para Agiles 2019 (invitación)

Preparando sesiones para Agiles 2019 (invitación)

Estamos a prácticamente 3 meses de la conferencia pero no aún no se sabe mucho aunque, dado que es en formato Open Space, tal vez tampoco haya mucho que decir. Será en el Salón Metropolitano de Rosario del 19 al 21 de Septiembre, se esperan unas 1000 personas, será en formato Open Space y ….. listo. Hay algo más de información en el sitio, pero es más bien metadata. Yo ya compré mi entrada en el primer early bird, la misma incluye una remera pero no el almuerzo.

Personalmente no me terminan de convencer las conferencias en formato 100% Open Space. Y mucho menos en la comunidad Agiles Latam, principalmente porque he visto varias sesiones con un exceso de improvisación y muy bajo nivel/calidad.

A grandes rasgos la propuesta es:

  • Lanzar la convocatoria de participantes de esta iniciativa (este post)
  • Hacer una primera sesión online para explicar conocer la iniciativa, confirmar los participantes y definir los sesiones/temas a preparar. A partir de esto empezamos a preparar las sesiones.
  • Hacer una o dos sesiones online de seguimiento y coordinación para asegurarnos de llegar Agiles con las sesiones pulidas y sincronizadas.
  • El punto de partida e hilo conductor de las sesiones será el libro Accelerate, o sea: las sesiones tratarán algún tema del libro
  • Durante la conferencia realizaremos las sesiones planificadas y generaremos el/los entregables.

¿Te gusta el plan? ¿Queres sumarte?:

Sobre Scrum Masters & Project Management

Sobre Scrum Masters & Project Management

Continuando con la cuestión de planteada previamente (el sospechoso rol del Scrum Master…) sobre las responsabilidades extra que suelen recaer en aquellas personas que ocupan el rol de Scrum Master en las empresas de desarrollo de Software, hoy quiero referirme puntualmente al Project Management.

Antes que nada hago algunas aclaraciones sobre Management según Agile:

  1. El manifiesto ágil dice explícitamente que el equipo es auto-organizado, lo cual implica que la estrategia de management es distinta a la tradicional (muchas veces taylorista) y que varias tareas de management recaerán en el propio equipo. No está completamente claro cuales de las tareas de management toma el equipo y cuales caen fuera, eso habilita a que cada equipo/organización lo maneje de forma distinta.
  2. Más allá de que el equipo sea auto-organizado es razonable que el equipo tenga que interfacear/reportar/coordinar en algún punto con la organización a la cual pertenece. Una cuestión clave aquí es como de implementa esa interface respetando la auto-organización del equipo.

Más allá de de estas cuestiones conceptuales lo que suelo encontrarme muy frecuentemente en empresas de desarrollo de software es que una misma persona concentra el rol de Scrum Master y también varias tareas de management. En particular hay 2 escenarios muy comunes: 1) Scrum Masters haciendo Project Management y 2) Project Managers haciendo de Scrum Masters.

1) Sobre Project Managers haciendo de Scrum Masters

Esta es gente viene de una experiencia de Project Management y que ahora que “el mundo es Agile” se metió en Scrum y adoptó el rol de Scrum Master. Como ya tiene una experiencia en management no le resulta difícil tomar las tareas de management que le pide la organización. El gran desafío aquí es que esta persona pueda dejar de lado algunas practicas de management porque está trabajando con un equipo auto-organizado. Situaciones típicas en este escenario son:

  • La Daily Standup convertida en un reporte de estado
  • Ver al Scrum Master asignando tareas
  • Tracking y reporte en término de horas
  • Micro-management
  • Percepción del Scrum Master como Jefe del equipo

2) Sobre Scrum Master haciendo Management

En este escenario tenemos gente que se formó/entrenó como Scrum Master y que adicionalmente se encuentra con que debe cubrir tareas de management para las cuales no tiene formación. En este escenario estoy hablando de personas que llegan a ser Scrum Master luego de haberse desempañado como Developer, Tester o algún otro rol pero no Project Managers. En estos casos, si el equipo no tiene la experiencia suficiente para auto-organizarse vemos sufrir al proyecto: no hay métricas, el equipo no tiene una velocidad de delivery predecible ni estable, el cliente ve mucho post-its que en lugar de ayudar a la gestión generan una sensación de desorden y extrema informalidad, la gestión de riesgos es bastante endeble (si es que se hace), y el equipo no tiene la habilidad/capacidad de manejar imprevistos de ningún tipo, etc.

Como ya mencioné no me convence la estrategia de concentrar las tareas de management y Scrum Master en una misma persona, pero si alguna organización piensa hacerlo, espero que al menos tomen la precaución de asegurarse que esa persona que ocupe el doble rol tenga la apropiada formación tanto para las tareas de Scrum Master como también para las tareas de Project Management.

El sospecho rol del Scrum Master en las empresas de desarrollo de Software

El sospecho rol del Scrum Master en las empresas de desarrollo de Software

Una situación que veo recurrentemente en las empresas de desarrollo software para terceros es que conforman sus equipos poniendo una persona en el rol de Scrum Master y asignandole también algunas otras tareas. Esto genera que en términos generales que la persona en el rol de Scrum Master termine concentrando 3 grupos de tareas:

  • a) tareas de facilitación propias del Scrum Master que podemos resumir como ayudar a que el equipo siga la propuesta de proceso de Scrum, removiendo potenciales impedimentos, etc
  • b) tareas típicas de la gestión del proyecto desde la perspectiva de la software factory como ser: seguimiento del presupuesto, planificación del equipo a mediano/largo plazo, seguimiento de la facturación, gestión de riesgos, etc. Aclaro aquí una cuestión importante: la gestión de presupuesto y del plan son responsabilidades del Producto Owner cuando vemos el proyecto desde la perspectiva de la organización que es dueña del producto, pero estas cuestiones también están presentes desde la perspectiva del proyecto de la software factory.
  • c) tareas de gestión internas requeridas por la organización(software factory) respecto de los miembros del equipo como ser evaluaciones de desempeño, coordinación de licencias, etc.

Lo que me resulta sospecho es la concentración de estos tres grupos de tareas en un misma persona porque me parece que puede haber cierto conflicto. Un caso puntual a modo de ejemplo: se supone que el Scrum Master debería generar un contexto de seguridad para que el equipo y sus miembros puedan hablar en confianza sobre sus dificultades, equivocaciones, etc, pero al mismo tiempo esa persona Scrum Master tiene que evaluar el desempeño de los miembros del equipo ¿cuan seguro puede sentirse un miembro de equipo para hablar de sus equivocaciones cuando ese Scrum Master es también la persona que evalúa su desempeño?

Lo que yo recomendaría en estos escenarios es tener dos personas distintas: una con el rol de Scrum Master (que estaría presente en el día a día del proyecto ) y otra con el rol de gestor de proyecto (con una presencia mucho más esporádica).