Formación en Scrum

Como empezamos en un formación en Scrum

Antes de empezar a hablar de lo que es una formación en Scrum, te quería contar algo de mi. Con 18 años daba clases de judo a niños de 5 y 7 años, con 20 daba clases de informática básica para oposiciones de auxiliar administrativo, y a partir de los 24 dando cursos de desarrollo (OCX ,Clean Code, TDD, BDD,etc) y Scrum por un montón de países de Sudamérica (Argentina, Chile, Brasil, México, Puerto Rico)

Cómo empezar, diciendo que una de las cosas que más me han apasionado tanto en mi vida personal como profesional ha sido la formación, sin entrar en si lo he hecho mejor o peor.

Para mi la formación tiene dos pilares clave, el primer pilar sería el de poder compartir mi conocimiento,  y el segundo pilar sería el la búsqueda de la mejora continua. En esta búsqueda, quiero ser mejor comunicador, empatizar mejor con el público, que muchas veces no sabes como va a reaccionar, y por ende ser mejor profesor.

Creo que el tipo de personalidad “entusiasta” que tengo (eneagrama), me ha ayudado a poder estar continuamente reinventándome dentro de este maravilloso mundo de la formación. He pasado del documento en papel, por el power point,  y últimamente estoy utilizando técnicas de Sketchnoting, con muchas dinámicas y lego (Lego4Scrum).

Mi consejo personal, para meterte en el mundo de la formación, tienes que tener una necesidad imperiosa de compartir tu conocimiento,y sobre todo la de querer cumplir las expectativas de un grupo de personas que dedican un tiempo muy valioso a atenderte.

Recuerda que en una formación tu no eres el importante, los importante son ellos siempre, no les hagas perder el tiempo. Es mucho mejor hacer un minicurso de un par de horas, pero que merezca la pena, que no un curso de dos días sin una estructura, un objetivo claro y bien armado.

Preparación de una formación en Scrum

Voy a contar como yo me preparo una formación básica en Scrum, aquí cada maestrillo tiene su librillo, y lo importante es que si copias lo hagas de los mejores.

Hasta hace no mucho tiempo, siempre iba a las formaciones con mi Powerpoint como herramienta básica, pero un día en un meetup de Bikablo (visualización gráfica), ví que un mundo de posibilidades se podían abrir. El cambio fue brutal, así que ahora siempre que puedo, dejo la presentación en casa y utilizo la representación gráfica. En este artículo podéis ver algunos que suelo utilizar.

Otra cosa muy importante en lo que os tenéis que fijar es en la cultura de la empresa. Me explico, suponte que te contratan para dar una formación de Scrum, donde la empresa tiene una cultura organizacional muy arraigada en un modelo tradicional (taylorista), donde los valores brillan por su ausencia, y lo de compartir el conocimiento es una quimera.

Si vais a dar una formación y no teneis nada de información de la empresa, no os preocupeis porque hay formas de obtenerla. En el siguiente apartado os cuento lo que yo hago.

Ronda de Presentación y Expectativas

En una formación de Scrum, lo primero que hago después de presentarme y de enseñar el guión de la sesión, es la de hacer una ronda de presentaciones. En esta ronda pregunto a las personas cual es su nombre, cuál es su rol, si conocen los marcos de desarrollo ágil y si han trabajado con alguno de ellos.

Si están trabajando con algún marco agil, me interesa mucho saber cuál fue su rol anterior. Es muy típico que el antiguo Jefe de Proyecto, ahora haga de Product Owner. También me interesa mucho el porcentaje de internos vs externos, para tener algo de información sobre la cultura organizacional de la empresa.

A parte de lo anterior, también les hago escribir en un post-it cuales son sus expectativas para el curso. Estos post-it los colocamos en una pizarra Kanban como veis en la foto.

Dependiendo del tipo de empresa, en una formación de Scrum, le suelo dar más peso a unos apartados más que a otros, y con mucha gracia y desparpajo, aprovecho para dar un poquito de caña a esos managers arraigados en la cultura del comand and control.

Visión Agil

Los seres humanos nos movemos por objetivos tanto personales como profesionales, y buscamos el mejor camino para llegar a ese objetivo, visión, pasión (llámalo como quieras). En este camino nos encontramos con piedras más pequeñas que podemos saltar, o con otras gigantes que tendremos que rodear, pero siempre deberíamos ir para delante. A veces es dificil, pero quien dijo que la vida era fácil.

Las empresas nos llaman porque quieren trabajar “de otra forma”, no saben cómo, pero lo que sí saben es que no están teniendo los resultados esperados, y abrazan con vehemencia el eslogan “Renovarse o morir”.

Yo en este caso como representante del “agile en la tierra” (es broma), y bajo mi experiencia intento trazarles un camino básico que cualquier empresa debería seguir en su transformación ágil. Ojito, que esto del agile no es la panacea, ni nos va a hacer ganar siempre dinero a espuertas, o sino fijaros en lo que dice el informes del Caos de 2018 de Standish Group, done un proyecto ágil tenía un 46% de posibilidades de tener éxito, frente a un 26% en un modelo tradicional.

Para resumir el camino que veis en el dibujo, indicar que para llegar a la fase “Agile”, primero deberíamos comprobar si las personas (a nivel individual), tienen la voluntad de salir de su zona de confort y plantearse un reto diferente o no. Hasta que no consigamos este hito no deberíamos pasar al siguiente nivel, donde cambiamos el yo por el nosotros, donde las necesidades del equipo estarían por encima de las necesidades del individuo.

En una primera formación básica de Scrum, no me interesa meterme mucho en la parte de escalado, pero siempre hay alguien que pregunta sobre SAFE, y si es agile o no (el lado oscuro), y hay que dar unas pinceladas.

Manifiesto Agil

Sabéis como yo que el Manifiesto Ágil es el abc de los “Métodos Ágiles”. Un movimiento promovido por diecisiete críticos de desarrollo software en el 2001, que buscaban una alternativa a las metodologías formales, que se consideraban excesivamente pesadas y rígidas.

En este punto, nada más empezar esta sección hago la dinámica de las monedas para comparar a grandes rasgos las diferencia entre un entorno de desarrollo tradicional (waterfall), versus un entorno utilizando una metodo agil, y al final abro un debate con las personas que están en la formación. Os dejo un video (que no es mío), donde podeis ver como funciona exactamente:

En el modelo tradicional todas las monedas van pasando por todas las fases de una cadena de montaje, y al final de la cadena se recibe el producto. Sin embargo en un modelo ágil se hacen pequeñas entregas, con lo que se puede ir viendo si el resultado de lo esperado es correcto o no (feedback).

En relación a los pilares y principios del manifiesto me gusta darle un poco más de cariño a la parte de los pilares (personas y sus relaciones, software funcionando, colaboración con cliente, y respuesta al cambio), que a los principios.

Scrum

Este dibujo me sirve para ir enmarcando el resto del curso. Cuando empezaba a dar formaciones de Scrum, explicaba demasiadas cosas en esta parte, y cuando iba avanzando en el resto de temas (roles, eventos, y artefactos), sentía que me repetía en exceso.  

En la formación en Scrum, me interesa en este punto dar unas pequeñas pinceladas del marco para no aburrir a la audiencia (less is more). Obviamente hay que comentar el origen del marco, y que es el framework agil mas utilizado en el mundo.

Elementos que quiero que formen parte de mi speech a partir de ese momento son: Valor y velocidad, Iterativo e Incremental, Reducción de Desperdicio, y de progreso constante.

Veis en la imagen del mapa de Scrum que hay post-it amarillos con preguntas. Realmente cuando les presento el dibujo por primera vez no están estos post-it. Estos los he preparado en casa, y al final del curso se los doy para que ellos los coloquen. Dudas??? no pues seguimos…

Pilares y Valores Scrum.

Pilares Scrum

Cuando hablo de pilares Scrum, y estoy dando la formación a equipos que llevan trabajando años dentro de un modelo tradicional tengo que tener cuidadín.

La razón viene de cuando digo que cuanto daño ha hecho al desarrollo del software los Microsoft Project  y los diagramas de Gantt, donde en un proyecto de 10 meses, en el mes 9 preguntábamos cómo iba el proyecto y el manager de turno nos decía que iba al 90 % (a un 10% por mes), y el cliente no había visto nada del producto que desarrollaban.

Trabajo en Madrid, donde la tasa de paro en informática es muy baja, y me ha pasado muchas veces, que un mes antes de la fecha de entrega de estos mega proyectos waterfall, la gente se iba de sus empresas. Se ivan porque sabían que el proyecto estaba hecho un desastre y no iban a acabar en fecha ni de cerca. Los manager tenían la excusa perfecta porque decían que iban bien, pero que al irse las personas claves el proyecto, este se iba a retrasar. Quién paga los platos rotos??? Los paga el de siembre, el cliente.

Para arreglar lo anterior, y para comernos un elefante (un proyecto huge), lo primero que tenemos que hacer es filetitos pequeños, que nuestros equipos puedan desarrollar en periodos cortos de tiempo. Fomentar la transparencia en el equipo del ¿cómo vamos?, no con el sentido de castigarlos, sino en el sentido de ¿cómo os podemos ayudar?. Si sabemos como vamos podemos saber cómo vamos según lo planificado (Inspección), y si no fúeramos bien, que podemos hacer para volver al camino (Adaptación).

Como cierre de este apartado en la formación en Scrum, suelo enfatizar la siguiente frase:

Recordad que todo esto debería ser desarrollado dentro de un ambiente de confianza, buena voluntad, y ayuda mutua.

Valores Scrum

En la formación de Scrum, no suelo extenderme mucho en esta parte, aunque si comento cada uno de los valores, para que todo el mundo los entienda, pero sobre todo me suelo extender en dos de ellos en Foco y en Respeto.

Antes contaba que para comernos un elefante, empezábamos a comernos un filetito, después otro, hasta comernos todo el elefante. Cuando hablábamos de un proyecto hacemos lo mismo, lo partimos en trocitos pequeños y todo el equipo se pone a trabajar sobre el primer trocito que debería ser el más importante para el cliente.

En entornos tradicionales, el equipo suele recibir órdenes desde diferentes orígenes, o trabaja en dos o más proyectos al mismo tiempo. Esto mata la productividad del equipo siempre, por eso soy muy pesado con el valor del «Foco«. Al equipo solo le deberían llegar necesidades desde un único punto de entrada, desde la figura del Product Owner y de una forma controlada, para reducir al máximo el cambio de contexto.

En la otra parte en la que soy muy pesado, en el valor del «Respeto«. Solemos asociar el respeto, con el respeto a tus compañeros, con la igualdad entre hombre y mujer, con el respecto a conceptos relacionados con el credo, raza o sexo.

A parte de lo anterior que un «must«, me encuentro otras faltas de respeto inherentes al mundo profesional. Por ejemplo, las diferencias que existen por tener una mejor titulación que su compañero, o la falta de respeto que algunos internos tienen con los externos, porque se sienten superiores. No quiero ni pensar en aquellas empresas que tienen restaurantes, o zonas para internos, y otras para externos, o las que en el correo electrónico se añada la extensión «external«, no lo soporto.

En general todo lo que explico en la formación en Scrum, en relación a pilares y valores Scrum, puede ser aplicado tanto al ámbito profesional como personal. Parece que explicamos cosas obvias, pero pregunta quién las aplica realmente.

Product Owner en una formación en Scrum.

Seguimos la formación en Scrum, con el maestro de los platillos chinos, el Product Owner. En el dibujo podéis ver lo más importante que cuento, que no se sale mucho de lo que cuenta la guía de Scrum. Pero para mi hay mucho más..

El Product Owner es la pieza clave para que la magia del Scrum suceda o no. Podemos tener a los equipos más maduros, auto organizados y múlti funcionalidades, pero si esta persona no lo hace bien, estáis jodidos.

Como debe ser eso de mantener muchos platillos en equilibro, y la caída de uno afecte significamente al resto. El Cliente, estrategia, mercado, roadmap, presupuesto, o el equipo, son algunos de estos platillos que el Product Owner no deberia dejar caer.

Cuento que Product Owner debería tener un ojo siempre mirando a las necesidades cliente y a la estrategia, y otro a su equipo para siempre velar por el valor y velocidad.

Valor, es ir  haciendo pequeñas entregas, que sean realmente elementos diferenciadores de los competidores, y Velocidad es ver cómo puedo reducir el tiempo de entrega, sin reducir la calidad de la misma.

Por otro lado, el Product Owner tiene que dar al equipo alas para que sean innovadores, disruptivos, y velen por la calidad. Otras veces les tiene que parar los pies, cuando se empiezan a desviar de la estrategia definida.

Para que un Product Owner pueda hacer bien su trabajo, a veces tiene que tener mano firme con el cliente y con su equipo y saber decir que no. Debe ser inteligente y negociar con ambas partes para llegar a acuerdos, esto es lo más importante. 

Scrum Master en una formación en Scrum.

Como hay muchos artículos que hablan de la figura del Scrum Master, en las formaciones en Scrum, me apetece mas de los problemas con los que se puedan enfrentar, que lo que dice la teoría. Lo de que vela por el marco Scrum, si me lo permitís me lo salto.

Cosas que cuento en las charlas que me mola remarcar de un Scrum Master:

• No eres un reserva salas, tu trabajo es mucho mas importante.
• Predica con el ejemplo amigo. Lo de los valores y pilares no es solo para los demás.
• Sabes que personalidades tiene tu equipo (Eneagrama).
• Sabes que disfunciones tiene tu equipo (Lencioni).
• Tus equipos tienen acuerdos de trabajo (Alianza).
• Sabes en que etapa esta tu equipo (Tuckman).
• Estudia los valores de tu empresa y entenderás muchas cosas (cultura organizacional).
• Trabaja en la generación de Valor (Product Owner) y en la Velocidad (Equipo)
• Fomenta la formación y la innovación.
• Admitimos el cambio hasta en etapas finales, pero no son gratis, negocia.
• Historias de usuarios pequeñas. El gran secreto de las entregas y de las estimaciones (objetivos del equipo).
• El que mucho abarca poco aprieta, controla el WIP, y el desperdicio, y fomenta el swarming.
• Experimentos, experimentos, experimentos, os ayudará a validar hipótesis. Reflexiona constantemente y ajusta.
• El certificado solo te vale para pasar la primera entrevista de recursos humanos.
• Si antes eras jefe de proyecto, aprovecha la parte del Peopleware y desaprende la parte del comand and control.
• No te desanimes y sigue intentándolo. Para dar un paso hacia delante, tienes que dar algunos pasos para atrás.
• No seas zoquete. Patrones de diseño, análisis estático de código, code review, pair programing, integración continua, despliegue continuo, XP, TDD, BDD, Gherkin, son parte de la agilidad.
• Ten cuidado con las funny retrospetives, que quieres conseguir???

Incluso si eres un excelente Scrum Master, y has tenido en cuenta todo lo anterior puedes fracasar, porque no tengas el apoyo de tu empresa. Recuerda que el lado oscuro siempre esta presente, conócelo e intenta llevarlo hacia la luz. Si no puedes, no pasa nada, a otra cosa mariposa.

Development Team en una formación en Scrum.

Cuando sé que en una formación en scrum, la mayoría de las personas que van son equipos de desarrollo, intento que el comienzo sea lo más impactante posible. Como vengo del mundo del software, se más o menos lo que pueden estar pensando.

Cosas como “a ver que nos cuenta este tío”, “no tiene ni idea”, “eso aquí no funciona”, o a ver si termina pronto que tengo mucho trabajo, son pensamientos que se palpan en el ambiente. Esa fuerza y energía, la tengo que canalizar para conseguir  mi propósito. Como decía Sun Tzu en el Arte de la Guerra:

Conoce a tu enemigo, y conócete a ti mismo, y saldrás triunfador en mil batallas.

Para atraer la atención de la audiencia, y enchufarles en la formación, les suelo poner el siguiente vídeo, de la película de 300:

Al acabar el vídeo remarco la frases con las que quiero hilar la formación:

Luchamos como una única e impenetrable unidad, ahí es donde reside nuestra fuerza. Cada Espartano protege al hombre que está a su lado, desde el muslo hasta el cuello con su escudo, un solo punto débil y la defensa se vendría abajo.

Lo siento amigo mío pero no todos hemos nacidos para ser soldados. Si quieres contribuir a una victoria de Esparta, saca los cadáveres del campo de batalla, atiende a los heridos, y llévales agua, pero para presentar batalla no puedo contar contigo. Te equivocas Leónidas, te equivocas.

Ahora sí estamos todos preparados para hablar de lo que es un Development Team en Scrum, y tengo que intentar cubrir todos los elementos que he marcado en negrita:

• Una sola e impenetrable unidad. Tenemos que hablar de lo que es un equipo auto organizado, y multi funcional. Nosotros, y solo nosotros vamos a decidir como vamos a hacer el trabajo y el tiempo que nos va a costar realizarlo. Obviamente tenemos en cuenta las opiniones de los demás, y reflexionamos constantemente en el cómo afrontamos los retos.

• Nuestra fuerza. Aquí es obligatorio hablar de objetivos comunes, y de mejora continua. Si o si hay que perseguir la excelencia técnica, la mejora de la calidad de nuestro trabajo, de las buenas prácticas (automatización de pruebas, integración continua, despliegue continuo, DEVOPS, etc).

• No todos hemos nacido para ser soldados. Queremos celebrar el éxito del equipo como propio, o solo miramos por el interés individual. Si es esto último lo siento amigo pero no hay lugar para tí en el equipo, por muy buen profesional que seas.

En las formaciones en Scrum, reto a los equipos de desarrollo, y les digo que para mi la agilidad es conseguir subir a producción cada vez en menos tiempo. Si antes subíamos a producción cada seis meses y ahora subimos cada cuatro, somos un poco más ágiles. Si conseguimos subir cada dos un poco más, así hasta poder subir llegar a subir a producción, varias veces por sprint, aunque digan algunos que eso es imposible.

No me vale utilizar Scrum o cualquier otro framework ágil si no hemos reducido el tiempo de delivery. Tampoco vale si subo muy frecuentemente a producción, si lo que subo no lo utiliza nadie (no aporta valor). Acordaros de Valor y Velocidad, ahí lo dejo.

Visión: Queremos llegar a ser un equipo de alto rendimiento

Eventos Scrum

Después de hablar de los roles en Scrum hay que contar una parte muy importante que son los eventos, cuando nos reunimos y para que?. 

Hay que tener reuniones eficientes para reducir al máximo el desperdicio. Lo normal sería invertir alrededor de un 12% a 15% del Sprint en reuniones de Scrum. Cuánto tiempo no? Mucho menos del que utilizarías en un entorno tradicional, os lo aseguro.

Recordaros, que trabajamos en pequeñas iteraciones de tiempo (Sprints), de un mes o menos, en el cual se crea un incremento de producto “Terminado”. 

Resumiendo mucho, mucho. Dentro del sprint, nos reunimos el primer día para ver qué podemos hacer durante el Sprint (Planificación), diariamente nos reunimos para ver cómo vamos según lo planificado (Daily), y al finalizar el sprint mostramos lo que hemos terminado (Review) y reflexionamos en él como hemos trabajado (Retrospectiva). 

    En la retrospectiva, que es la última reunión del sprint soy muy pesado en que se tiene que hablar de qué acciones tenemos que ejecutar para mejorar como equipo, y cómo genera más valor. Es decir si en vez de 10 historias de usuario por sprint podemos sacar 15 que deberíamos hacer.

En relación a la review y a la retro suelo amenizar la velada un ejemplo futbolístico. Veo la review como el equipo que sale a jugar delante de miles de personas, mostrando su mejor juego, y el público decide si pitarlos o no (feedback), y la retrospectiva vendría ser cuando el equipo va al vestuario y hablan de que van a hacer, para que la segunda parte sea mejor, además de recordar que lo que pasa en el vestuario se queda en el vestuario.

Por último suelo dar también mucho peso al refinamiento. Para mi es tan importante acabar bien un sprint según lo planificado, como preparar el siguiente sprint. No me vale acabar un sprint bien, y el siguiente sprint no sepamos que vamos a hacer. Aquí suelo contar el cuento del famoso “leñador” que dice así:

“Un leñador va a buscar trabajo, al entrevistarlo el capataz, ve un tío fuerte, motivado y con ganas de trabajar y le contrata. Este leñador se levanta el primer día las 8 de la mañana y se tiran 8 horas cortando árboles y corta 125 árboles. El leñador al irse a acostar piensa, mañana me voy a levantar a las 7 de la mañana y voy a cortar mas árboles que hoy. Al día siguiente al finalizar el día sorprendido ve que solo había cortado 105 árboles (como podía ser esto). El leñador enfadado piensa que al día siguiente se va levantar a las 6 de la mañana para cortar mas árboles que nunca.

Después de la tercera jornada solo consigue cortar 80 árboles. Al cuarto día por la mañana va a ver al capataz y le dice “señor voy a dejar el trabajo porque soy incapaz de mejorar, peor aún cada vez corto menos árboles”, a lo que el capataz responde “durante estos tres días has parado en algún momento a afilar tu hacha” a lo que el leñador contesta “no tengo tiempo para parar tengo muchos árboles que cortar”. 

Moraleja “Para poder mejorar, a veces es necesario parar, ver como podemos ajustar el proceso, y seguir mejorando”

Artefactos Scrum

Aquí el mensaje que doy y doy mucha caña es a la figura del Product Owner, en el sentido que tenga una visión de la estrategia de la compañía, que tengan un roadmap tentativo a dos o tres meses (no más), y que tenga al menos dos sprints refinados donde se cumpla aquello de “no hay malas historias de usuario sino malas conversaciones”. El roadmap es convertido en un Product Backlog, el compromiso de lo que vamos a hacer lo convertimos en un Sprint Backlog, y lo que generamos al final del sprint (valor) es lo que llamamos incremento. 

Pesao, pesao, pesao en tener historias de usuario cuanto más pequeñas mejor, recordando cosas como INVEST o técnicas de refinamiento.

Resumen de la formación en Scrum

Importante, no des en una primera formación de Scrum demasiada información con decenas de slides, mejor muestra información muy básica pero fácil de entender, y si puede ser con dinámicas de grupo. Jugando se aprende un montón, y encima divierte, aprovéchalo.

Ánimo amigo, y recuerda que el proceso de cambio cultural debería hacerse despacito….