Scrum Master

Scrum Master, hay muchos artículos que hablan de la teoría, y de lo que deberías hacer, por eso me apetece mas hablar de los problemas con los que te vas a encontrar, y como me enfrenté a ellos, cuando era Scrum Master. Con tiempo me dí cuenta que algunas cosas que hice, las hice como el culo, pero bueno…..

Espero que mi experiencia te pueda ayudar, a ayudar a otros, recuerda que tu no eres el importante, tus equipos si.

El certificado solo te vale para pasar la entrevista de recursos humanos, espabila.

En la primera empresa donde trabajé estuve 15 años, más de la mitad trabajando con Scrum, Kanban, XP, TDD, etc. Por desgracia esta empresa tuvo problemas económicos y muchos tuvimos que salir.

Cuando empecé a buscar trabajo, en todas las entrevistas de recursos humanos, me pedían algún certificado en Scrum, y no las pasaba. Estaba super frustrado porque toda mi experiencia no valía para nada, y me negaba doblegarme ante esta exigencia.

Con el tiempo comprendí que si quería trabajar en lo que me apasionaba, tendría que entrar en el juego de la titulitis Española, y tuve que  sacarme algunas de ellas.

Las certificaciones, me permitieron meter la cabeza en el mundo laboral, pero mi experiencia y bagaje, hizo que me pudiera desenvolver en el medio.

Por eso amigo para trabajar en esto no vale solo la certificación, así que ten cuidado cuando digas que tienes experiencia y sea mentira.

No seas zoquete, la excelencia técnica de tu equipo es parte de Agile (XP, TDD,CI,BDD).

Si hablamos de excelencia técnica y en concreto de TDD, tengo que agradecer a personas como Kent Beck y a Carlos Blé, la gran aportación que hicieron a la comunidad de desarrollo. Os recomiendo que leáis sus libros “Test-Driven Development by example”, y “Diseño Ágil con TDD”.

Scrum Master, estás trabajando con equipos de desarrollo, y no conoces, ni quieres conocer los “palabros técnicos” que utilizan, pues levanta el culo y ponte las pilas, ya puedes empezar a estudiar, y no digo que te hagas un experto.

Como vas a ayudar a nadie, si no les entiendes, o dime que haces cuando utilizan palabras como: “Kubernetes, Kafka, Mongo, OpenShifth, Sisyphus, Copado, Pruning, TDD, Junit, Jenkins, etc”. He visto a más de uno con esa expresión en la cara de “qué coño dirá esta gente”. 

Mi consejo, estudia y comprende este vocabulario técnico para que poco a poco puedas entender a tu equipo, y en el fondo poder ayudarles mejor. Es importante que todos habléis el mismo idioma, y este esfuerzo te hará ganar confianza dentro del equipo.

Acuérdate que la búsqueda de la excelencia técnica es uno de tus desafíos, con lo que tienes que asegurarte, que el equipo mejora en este aspecto (patrones de diseño, revisión de código, pruebas unitarias, integración continua, o despliegue continuo). Será muy duro para tí decirle al equipo que el que no quiera entrar en este juego, sintiéndolo mucho no va a tener cabida en el equipo.

Mi tarjeta roja para aquellos Scrum Master que viniendo del mundo del desarrollo, pasaron de reciclar su vocabulario técnico, porque ahora como soy Scrum Master no lo necesito, gran error amigo.

Scrum Master, tienes que ser pesado con el Valor y la Velocidad.

El mensaje que nos dió Javier Garzás en el curso de Pragmatic Agile Coaching, era simple (que no fácil de aplicar) y era que teníamos que velar por el Valor (Eficacia), y la Velocidad (Eficiencia), y nos dejáramos de tonterías.

Scrum Master, desde mi punto de vista puedes darle todos las vueltas que quieras pero el mensaje para el equipo es claro, mejora continua, velocidad y predictibilidad y para la empresa es estrategia, generación de valor para el cliente y cultura organizacional.

Puedes engañar a tu empresa / equipo diciéndole que lo más importante es aportar valor al cliente, pero sí para aportar valor tardas en desarrollarlo 6 meses estás muerto. Hacer muchas cosas que no generan valor tampoco vale. Lo ideal sería generar muchas cosas y con mucho valor, y esta debería ser nuestra visión. Yo no digo que sea fácil conseguirlo ojito……

Hay algunos gurús del agile que dicen que el concepto “productividad” es un concepto “oscuro”, relacionado con el command and control o con el taylorismo, por lo tanto medir la velocidad de los equipos también. Puedo estar de acuerdo, si lo que quieres es comparar la productividad de un equipo con otro, pero si lo que quieres es que tu equipo sea cada vez mejor, y que haga más y mejores cosas el tema cambia (sin sobre esfuerzos).

Lo que sí es un error, es pensar que un equipo recién formado va a desarrollar muchas cosas, va a tener una velocidad constante y va a ser predecible (no pidas peras al olmo).

El gran secreto de la entrega temprana y de las estimaciones.

Cuantas empresas han desaparecido por no haberse adaptado a los nuevos tiempos. Llámame loco, pero lo que premia ahora es el «Time to Market», es decir salir al mercado en el menor tiempo posible y probar hipótesis.

Herramientas como Scrum, Devops, Cloud, Micro Servicios, etc, nos deberían ayudar a subir a produccción antes, con la mejor calidad posible, y con personas mas felices en su trabajo.

Desde mi humilde opinión, si todas las herramientas molonas, y frameworks de moda, nos ralentiza la subida a producción, lo siento pero no me vale. Yo soy de Customer first – Delivery first.

Scrum Master, que nos ayuda generalmente en el delivery first:

• Tener historias de usuario pequeñas.
• Involucar al usuario en el ciclo de desarrollo.
• Automatizar las pruebas para asegurarnos la calidad del software.
• Eliminar desperdicio en el flujo de desarrollo.
• Automatizar el despliegue entre entornos.
• Mantener equipos estables en el tiempo.

No soy el único que piensa en el delivery first. Carlos Buenosvinos, nos dice que a veces nos flipamos con las tecnologías punteras, y desatendemos el delivery. Scrum Master, para tí este video debería ser un must.

Scrum Master, no eres un reserva salas.

Muchos Scrum Master, trabajan como aquellos porteadores que aparecían en las películas de Tarzán, que obedecían las órdenes  sin rechistar, sí bwana, si bwana (amo en Suajili) 

Solemos utilizar a los Scrum Master como personas que se dedican a reservar salas de reunión, perseguir a la gente que no va a las dinámicas (pastoreo), documentar las reviews, las retrospectivas y subirlas al confluence.

Cuando llega alguien nuevo al equipo, se encarga de pedirles los accesos a las 20 herramientas, jira, permisos, repositorios de software, welcome pack, onboarding etc, etc. Resumiendo, suelen hacer las tareas que nadie quiere hacer, y tú Scrum Master dices, es que “Scrum es difícil de aplicar a la realidad”.

Scrum Master, aplica la palabra “coraje” que predicas a tus equipos, y explica a todo el mundo lo importante que es tu verdadero trabajo. Si no te hacen caso, cambia de curro, no pierdas el tiempo.

Scrum Master, predica con el ejemplo amigo.

No es la primera vez que me pasa que el día antes de la review, el equipo de desarrollo decide quedarse un rato mas del horario, porque quieren dejarlo lo mejor posible, y que el Scrum Master se va a su hora diciendo que no les puede echar una mano. 

A mi personalmente, me gusta que un Scrum Master también sea parte del equipo de desarrollo, y aún más, que el rol de Scrum Master sea rotativo dentro de él. De esta forma, todos estamos involucrados de la misma forma en la consecución de los objetivos de equipo.

Scrum Master puede ser que hagas su trabajo de maravilla, pero si no estás en los momentos de dificultades de tu equipo, se abrirá una brecha de confianza importante. Lo que estaría genial es que si todos decidimos quedarnos un poco más (de forma voluntaria), estuviera el Product Owner, Scrum Master y el Development Team. A lo mejor de esta forma el Product Owner el próximo sprint se lo piensa dos veces antes de meter algo que no estaba incluido dentro del alcance inicial.

Si eres un Scrum Master, y no eres parte del equipo de desarrollo, a lo mejor te tienes que encargar de las pizzas de la cena, ayudarles con las pruebas, o simplemente estando ahí, será una oportunidad magnífica para que el equipo siga creciendo, y confíen en ti. 

Remángate y nunca digas eso de caca no toco.

Admitimos el cambio, pero no es gratis amigo.

En el manifiesto ágil se puede leer algo como:

“ Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo”

Algunos clientes con lo único que se quedan es que en un framework agile lo más importante es la satisfacción del cliente, y que se aceptan cambios de requisitos en cualquier momento, pero no sé por qué pero piensan que el coste y la fecha de entrega va a ser la misma. Scrum Master en este sentido no dejes pasar ni una porque te la van a colar.

Scrum Master, le piden a tu equipo que hagan 1.000 botijos en dos meses. El primer mes entregan 400, y cuando el cliente los vé dice que se ha confundido y que eran 1.000 botas de vino, vaya por dios. Lo peor de todo, es que las quiere en la misma fecha y con el mismo coste (y ahora que….).

Scrum Master, si obligamos a hacer al equipo las 1.000 botas en solo un mes por no perder el negocio, lo que perderéis es toda la confianza con vuestro equipo, y todo el trabajo que hayas hecho se irá a la mierda (como decía Fernando Fernán Gómez).

Los buenos Scrum Master y los buenos Product Owner se ven en los momentos difíciles (como todo en la vida). Decir “SI” es muy fácil, pero lo que realmente diferencia del crack y el chusquero es saber decir “NO”, cuando corresponda. Negocia amigo…

Scrum Master, gestiona el cambio en tu organización.

La cruda realidad es que para que se produzca el cambio en una organización, los altos mandos, directivos, y gerentes tienen que querer positivamente que se produzca el cambio. De no ser así lo tienes bastante jodido amigo.

Como herramienta para trabajar en este punto, me gustó mucho el libro “Liderando el Cambio” de John Kotter, considerado por algunos el cuerpo de conocimiento básico en el campo del cambio, la innovación y el emprendimiento.

Scrum Master, vas a ver que los 8 pasos de Kotter tienen un rollito Manifiesto Ágil (creo yo): 

1. Crear sentido de urgencia.
2. Formar una coalición.
3. Crear visión para el cambio.
4. Comunicar la visión.
5. Eliminar los obstáculos.
6. Asegurarse triunfos a corto plazo.
7. Construir sobre el cambio.
8. Anclar el cambio a la cultura de la empresa.

Me gusta mucho en mis formaciones, explicar los 8 pasos de Kotter con la película “Moneyball”. Os dejo el ejemplo:

Fomenta la Formación y la Innovación.

Como sabéis una persona tiene tres motivaciones principales para mantenerse en una empresa, la motivación económica (la pasta), la motivación emocional (vida personal), y la motivación intrínseca (hacer algo diferencial y maravilloso en el trabajo).

Leyendo el libro “Coaching” de John Withmore indicaba lo siguiente:

Los millennial exigen un cambio de liderazgo, que los líderes no saben cómo ofrecérselo. El cambio de expectativas de los empleados más jóvenes, han dado los primeros toques de atención. 

En las entrevistas de trabajo quieren saber qué oportunidades de formación y de desarrollo pueden esperar en la empresa y con qué tipo de liderazgo se van a encontrar. 

No buscan, ni quieren un trabajo para toda la vida, y cambiarán de empleo si sus necesidades no son satisfechas.

Como a mi me encanta esto del Coaching y estoy certificado, «por si te interesa», te dejo algunos consejos de como deberías realizar una buena sesión de Coaching Individual.

Hasta hace no mucho, si un empleado trabajaba muy bien y querías se se quedara, le subías el sueldo y era suficiente (motivación económica). En los tiempos que corren la motivación emocional y la motivación intrínseca, muchas veces están por encima de la motivación económica.

Scrum Master un empleado formado, contento, y motivado es mucho más productivo que simplemente uno al que le paguen bien. He trabajado en empresas donde al no pagar unos salarios vamos a decir “dignos”, hemos tenido que trabajar mucho más en la motivación emocional o intrínseca, promoviendo por ejemplo teletrabajo, formación, innovación, etc.

Scrum Master, me gustaría dejarte este video de David Bonilla que habla de los tipos de motivación que existen, y como un empresario puede ser competitivo en sueldos.

Que tipos de personalidades tienes en tu equipo.

Tienes varios machos alfa en tu equipo, que pelean por ser los dueños y señores de la manada. Tienes muchas personas en tu equipo que solo hacen planes pero nunca se arriesgan a tomar una decisión. Scrum Master tendrás que ver cual es el comportamiento individual de cada persona y como afecta al equipo.

Lo que hace rico a un equipo es la diversidad, y que según vaya pasando el tiempo, se vayan conociendo, se respeten y que tomen confianza.

En el siguiente enlace puedes ver cómo estudiar la personalidad de cada una de las personas de tu equipo y ver si estas personalidades compensan o desestabilizan al grupo.

Trabaja las disfunciones de tu equipo, para que sea de alto rendimiento.

Scrum Master, la prueba suprema de un gran equipo son los resultados. La disfunción mayor de un equipo es la tendencia de sus miembros a ocuparse de algo distinto de las metas colectivas del grupo.

Una de las herramientas que he utilizado para trabajar las disfunciones de un equipo, la pude encontrar en el libro “Las cinco disfunciones de un equipo” de Patrick Lencioni. En este libro indica que para llegar a los resultados, había que resolver antes las siguientes disfunciones:

1. Ausencia de confianza
2. Temor al conflicto
3. Falta de compromiso
4. Evitar responsabilidades
5. Falta de atención a los resultados

Yo como lo veo, y seguro que estoy equivocado, es que el Scrum Master tiene que adoptar el papel de Líder, para trabajar en las disfunciones de su equipo. 

Llevar a un grupo de personas que trabajan juntos, a un equipo de alto rendimiento, es super complicado, y a veces hay factores externos que nunca podrás controlar. Si tienes pasión por tu trabajo, y eres paciente mi consejo es el siguiente:

“ Da igual todas las buenas herramientas que tengas, si no pones en primer lugar las relaciones humanas, no conseguirás algo realmente grande”.

Para hablar de liderazgo, os dejo un video de uno de uno de los mejores entrenadores de baloncesto del momento, Ettore Messina. Es un video un poco largo pero merece la pena. 

Be careful with Funny Retrospectives. ¿Que quieres conseguir?.

Scrum Master, las dinámicas para relajar un ambiente hostil (ice breaker),  pretenden conseguir algo, bajo un contexto determinado. Si buscas la última funny retrospective, porque te han dicho que hay que cambiar la dinámica sin ninguna otra razón, te estás equivocando.

Es cierto que deberías conocer diferentes tipos de retrospectivas, y según el ánimo del equipo, los conflictos producidos durante el sprint, o el objetivo deseado, sepas cual puede encajar mejor.

Otra cosa importante, algunas personas del lado oscuro o miembros del equipo te van a decir que con media hora para una retrospectiva es suficiente tiempo.  Tu trabajo es el de rascar, rascar y rascar hasta que aflore la transparencia y así podáis inspeccionar y tomar planes de acción.

Los conflictos constructivos son buenos para el proceso, acuérdate de la segunda ley de Lencioni (gestión de conflictos).

Por favor, por favor, por favor evita el agile cosmético y el pinta y colorea, que tanto daño nos está haciendo.

En este artículo escribí  más cositas que deberías tener en cuenta en una retrospectiva.

Scrum Master, no te desanimes y sigue intentándolo.

Una vez cuando trabajaba como Scrum Master entré en una empresa y esto es lo primero que me dijeron “aquí cada Scrum Master tiene tres equipos”, trabajamos con SAFE, tienes que gestionar los impedimentos, convocar las reuniones, preparar las restrospectivas, formar a los equipos, Product Owner y a la empresa. A parte tenemos una comunidad de Scrum Master, donde buscamos propuestas de mejora, con acciones que hay cumplir.

En el contexto anterior, a las personas de tu equipo las ves básicamente en las dinámicas y poco más. Tienes tres dailies de 15 minutos consecutivas, donde lo único que haces es mirar el reloj, en vez de estar atento a la transparencia, inspección y adaptación. A los quince minutos dices, bueno seguid vosotros…

Haces encaje de bolillos para que no te coincidan las reuniones de refinamiento, reviews y retrospectivas, pero claro como haces SAFE que te aconseja sincronizar los finales de sprint, tienes que comprimir las review, retros y planis en 3 horas, para ver si en un día puedes gestionar al menos dos de tus tres equipos.

Esto anterior sin contar las reuniones de gestión de riegos, dependencias, gestión de las releases, inception, etc, etc. A tomar por c…… lo dejo

Manager y gerentes de empresas “en serio queréis esto”, no señores, eso no es un Scrum Master, ni nunca lo será….

Muchas gracias por haber leido el post hasta el final, porque se me ha ido un poco de las manos (sorry). Espero que os haya podido ayudar a entender lo que es y lo que no es un Scrum Master.

Felicitaciones a esos Scrum Master que arriesgan su puesto de trabajo por hacer las cosas como deben ser. Ahí lo dejo….