Episode Transcript
[00:00:01] Speaker A: Territorio Inesem potencia tu liderazgo ha pasado ya un siglo desde que Unamuno pronunciara la famosa frase el progreso consiste en renovarse que nuestro país dio lugar al popular refrán renovarse o morir. Para entonces ya habían transcurrido casi otro centenar de años desde que Darwin postulara que no es la especie más fuerte la que sobrevive, ni la más inteligente, sino la que más y mejor se adapta al cambio. Fue tan solo unos años antes de que el filósofo e historiador japonés Okakura Kakuzu afirmara que el arte de la vida radica en un constante reajuste a nuestro entorno. Y así podríamos continuar durante ni se sabe cuánto, acudiendo a frases célebres o axiomas y principios casi universales que ponen de acuerdo a la grandísima mayoría de mentes brillantes que han pasado por este planeta, coincidiendo en que la adecuación a las circunstancias y las características de todo aquello que nos rodea y con lo que interactuamos es esencial de cara no solo a avanzar, sino también a lograr el éxito dentro de cualquier campo y la realidad empresarial y organizacional, por supuesto, no es ninguna excepción. Bajo esta premisa nació la idea de las metodologías ágiles o agile, basadas precisamente en la capacidad no sólo para responder al cambio, sino también para generarlo. Estas derivaron a su vez en diferentes métodos o procesos, entre los que se encuentran, por ejemplo, el Kanban, el Design Sprint o el Agile Inception. Pero sin lugar a dudas, la más famosa de todas es la metodología Scrum, que aunque pueda parecer un acrónimo, es un término procedente del rugby y viene a significar una melee, simbolizando el poder de un grupo de individuos que trabajan en sintonía y coordinación, como un bloque potente y compacto. Este es el tema que nos ocupa en el día de hoy y que vamos a tratar con Miguel Ángel Martín. Miguel Ángel Martín es experto, entre otros ámbitos, en e commerce, en Social media, en Social selling, en Marketing digital, en transformación digital. Miguel Ángel ha ejercido además como docente durante más de 15 años en multitud de centros de formación y facultades de varios países, incluidos Perú, Colombia y por supuesto, España. Ha sido consultor y asesor pedagógico y editorial aquí en el Reino Unido, jefe y responsable de ventas y actualmente es el fundador y director gerente de MAM Social Media. ¿Qué tal Miguel Ángel? ¿Cómo estás? Bienvenido de nuevo.
[00:02:17] Speaker B: Hola, un placer, David.
[00:02:18] Speaker A: Pues deseando estamos ya, porque por mi parte está hecha la presentación, que nos expliques en profundidad en qué consiste esto de la metodología scrum. Además, a mí me encantan los deportes, así que ya partiendo de esa analogía con el rugby ya vamos bastante bien. Así que nada, deseando estamos que nos cuentes de qué va esto. Todo, todo tuyo.
[00:02:36] Speaker B: Gracias David.
Un saludo a todos quienes estáis ahora mismo uniéndose o unidos ya a esta charla y la estáis descargando, la estáis visionando. Vamos a hablar de metodologías ágiles y en concreto, como muy bien ha indicado David, que por cierto, obviamente después de hablar de Darwin, Unamuno, etc. Juntarme a mí pues me parece un gran honor, pero desmedido en detrimento de personajes tan ilustres. Pero bueno, vamos a centrarnos, vamos a hablar de las metodologías ágiles agile y en concreto vamos a centrarnos, vamos a destacar o vamos a desarrollar una de ellas. ¿Qué son las metodologías ágiles? Básicamente, las metodologías ágiles se basan en poner en práctica una serie de principios, una serie de acciones, una serie de valores que van a permitir el máximo desarrollo, la máxima optimización del trabajo en equipo y a la vez del trabajo individual para la obtención del mejor producto o servicio posible, sea donde sea y cuando sea.
Además, las metodologías ágiles permiten una continua y regular adaptación a cualquier cambio procedente del entorno.
Las metodologías, hablamos de metodologías ágiles porque de hecho no hay una metodología ágil o agile como tal, no es una metodología, sino digamos, el aglutinamiento de los principios de distintas metodologías. Aquí esta imagen marca más de 40, pero yo he llegado a contar incluso más de 65. Por lo tanto, tenemos que pensar que hay muchas opciones, hay para distintos aspectos, en muchos casos están especializadas en determinadas áreas, sobre todo lo que es desarrollo de software, ahora veremos que todo surge un poquito de allí Zweitausendein, pero a partir de ahí podemos adaptarlo libre y personalmente a cualquier actividad que nosotros queramos realizar.
¿Por qué debemos plantearnos Agile? Agile es, o las metodologías ágiles hay que plantearlas como filosofía de empresa o filosofía de grupo de trabajo.
¿A qué me refiero? Hay empresas que no todo su [sos/eos] planteamiento, no toda su infraestructura o su logística se forma o se basa en metodologías ágiles, pero sí el desarrollo de determinados proyectos, determinados productos, determinados servicios. Eso sí, esos equipos han de funcionar, han de seguir digamos, los planteamientos básicos de lo que son las metodologías ágiles o la metodología ágil que se seleccione.
¿Por qué la metodología Agile o la Metodología Ágil? Habitualmente cuando salíamos de un punto, cuando preparábamos, planificábamos algo, la planificación suele siempre plantear punto de origen y punto de destino.
1 vez que tenemos los dos parámetros, a ponernos en marcha y finalmente cuando terminamos el proyecto, ya sea producto o servicio, valoramos si lo que hemos hecho sigue el plan o no. Sigue el plan, el plan previamente trazado.
Sí, bueno, esto yo creo que prácticamente todos lo hemos hecho muchas veces, pero debemos de tener en cuenta un aspecto. ¿Qué pasa si en alguna de las fases de producción o de preparación nos encontramos con inconvenientes, obstáculos, barreras o simplemente inadecuaciones que lo tenemos que corregir cuando ya está terminado? Eso supone dar volver atrás muchos pasos. La metodología ágil lo que corresponde o lo que realiza es en la creación de pasos o etapas más pequeñas, más breves, que se tienen que cerrar en un determinado periodo de tiempo. Y ojo, que hablo de cerrar, significa darlas por validadas y que una vez que están validadas permiten pasar por un lado, pasar a la siguiente y por otro lado, permiten que el producto final o el servicio final sea mucho más adecuado, mucho más ajustado a las necesidades reales de clientes y nuestras.
Porque esto al final es que nosotros demos lo mejor que nosotros podemos dar.
Me refiero que dos empresas pueden desarrollar el mismo proyecto, una puede llevar un desarrollo, otra otro desarrollo, las fases las establecerá cada equipo en función de sus características.
Y ese punto b, como veis, está ligera o bastante separado, ligeramente, bastante separado de lo que podría ser el resultado Ÿousand en organización o un diseño planificado, pero se acerca muchísimo más a lo que realmente nuestro cliente va a necesitar.
Y por otra parte, nos va a validar todos los procesos previos o todos los microprocesos previos. Vamos a ir viendo un poquito más para entenderlo.
¿Esto para qué sirve? Fundamentalmente para una integración continua, un desarrollo continuado, que todo lo que hagamos pueda testarse, que al final de cada una de esas pequeñas etapas podamos ofrecer un producto mínimo viable.
Un producto mínimo viable no es el producto final, quizá ni siquiera es un producto que pueda, entre comillas, venderse Zweitausendein, pero se está pareciendo ya a eso. Yo lo comparo muchas veces a lo que podría ser el proceso de fabricación de un vehículo.
En el primer sprint o la primera etapa podemos tener el chasis y las ruedas, con eso el vehículo no anda, pero ya hemos desarrollado esa primera parte de manera pormenorizada y perfecta. Y luego iremos integrando en las siguientes etapas el resto de componentes, pero esa parte ya está cerrada y todo lo demás se tendrá que modificar en función de las características de lo que ya está cerrado y de las circunstancias externas que nos puedan afectar.
¿Y esto qué permite?
Plena comunicación entre todos los miembros de un equipo.
En los equipos Ÿousand no hay responsables, o vamos a traducirlo, todos somos responsables porque lo que yo hago es un aspecto que va a ser una dependencia de lo que otro de lo que otra persona necesite. Por lo tanto, yo lo tengo que hacer perfecto o lo más perfecto que pueda y en el menor tiempo posible o en el tiempo estipulado posible.
Cuando trabajemos en grupo, trabajaremos en grupo, cuando trabajemos individualmente, trabajaremos individualmente. Pero el éxito o el fracaso no es por culpa de especialmente el fracaso.
El éxito o el fracaso es del grupo, del proyecto.
Por lo tanto, aquí no hay responsables y sobre todo, ante un fallo, no hay culpables. ¿Por qué? Porque luego veremos que esto nos tiene que permitir evitar, en la mayor parte de los casos, las posibilidades de error, minimizar esa posibilidad.
Y creo que eso es muy importante.
Por lo tanto, tenemos un equipo, el equipo se divide en unidades, que pueden ser una persona o varios grupos.
Cada grupo, cada unidad trabaja lo que le corresponde. Ojo, está repartido, pero está repartido, digamos, está asumido por la propia capacidad de cada unidad.
Y lo que aquí denominamos sprints, lo que se denomina sprints en las metodologías ágiles, es el periodo de tiempo que dura esa unidad de trabajo, esa primera flechita que hemos visto, y es un tiempo que está preestablecido y acordado y aceptado por parte de todo el equipo.
Esto surgió, las metodologías ágiles, en principio como agrupación o como concepto, como filosofía, surgieron en el año 2001, y lo he mencionado hace un momentito. ¿Un grupo de desarrolladores de software, acordaros, en esas fechas que justo acababa de suceder precisamente la explosión de las puntocom y la explosión de la burbuja de las puntocom en aquel momento, se reunieron para qué? Para poder trabajar no más, sino para poder trabajar mejor, de forma más eficaz y sobre todo de forma más eficiente. Ÿousand y posteriormente se vio que estos planteamientos que en principio se aplicaban a desarrollo de software, se pueden aplicar a otros muchos factores.
Luego lo veremos, pero incluso el scrum se ha llegado a aplicar a la hora de diseñar una boda, sí, el matrimonio de dos personas.
¿Qué quiero decir? Que se puede aplicar a muchos factores y no necesariamente solo a factores de desarrollo de software. Y que una empresa lo podemos poner en marcha, pilotarlo y ponerlo en marcha. Vamos a ver cómo. Vamos a hablar primero un poquito del manifiesto Agile, del Manifiesto Ágil, que se basa en cuatro aspectos fundamentales individuos e interacciones sobre procesos y herramientas. ¿Qué significa? Las capacidades de las personas, las relaciones entre las personas son más importantes que el procesamiento y las herramientas que se puedan utilizar. Claro que son necesarias las herramientas, pero para la optimización del trabajo de los individuos.
Por otro lado, el segundo punto, repito, esto estaba aplicado a software, lo vamos a aplicar a cualquier otro aspecto. Software funcionando sobre documentación extensiva. ¿Hay que documentar? Sí, pero en lugar de planificar en lugar de preparar, en lugar de tener un montón de manuales, un montón de información, que lo que se termine al final de cada sprint pueda ser válido y pueda ser validado. ¿Es decir, software funcionando al 10, al 20, al 30 % de manera incremental, entendéis? Es decir, que nuestro proyecto poquito a poco se vaya pareciendo a la idea final que podemos llegar a tener.
Tercer aspecto muy importante, colaboración con el cliente sobre negociación contractual. ¿Qué significa? El cliente forma parte del equipo, las necesidades del cliente se tienen en cuenta en cada momento del proceso de desarrollo y para eso el cliente tiene que estar presente, nos tiene que acompañar. Por tanto, es parte del gran equipo ágil.
Y finalmente, respuesta ante el cambio sobre seguir un plan.
Creo que esto ya lo hemos intuido a partir de la primera diapositiva que hemos puesto.
Si hay cambios, modificaciones internas o externas, es preferible ponerlas en marcha e implementarlas en cada uno de esos sprints, en cada una de esas etapas, mejor que nosotros hemos dicho que tenemos que llegar hasta aquí arriba y vamos a llegar hasta aquí arriba. El plan dice que hay que seguir y sigamos. Ÿousand no, esto no es un mapa rígido, esto es, digamos, como haría un GPS para que lo entendamos.
Un GPS nos marca la ruta optimizada, pero si realizamos algún desvío, inmediatamente reelabora la ruta para poder optimizar la nueva ruta o el recorrido hasta el punto final.
¿Pues en este caso, lo mismo, de acuerdo? Y como dice la diapositiva, los valores de la izquierda son más importantes que los valores de la derecha en esta explicación. Individuos e interacciones, software funcionando, colaboración con el cliente y respuesta ante el cambio.
¿Os habéis dado cuenta? ¿Te has dado cuenta de cuál es la palabra más importante?
Sobre.
Es decir, los principios que hemos visto en el lado izquierdo de la pantalla. Sobre, por delante de, por encima de, lo que habitualmente nos restringe, nos reprime, nos impide un desarrollo ÿousand mucho más eficaz, mucho más válido.
Los principios de manifiesto ágil están aquí, están en la página que os he mostrado, se crearon en 2001. Digamos que son los principios sobre los que cualquier otra metodología ágil se construye. Luego veremos que hay alguna diferencia entre ellas, pero bueno, pese a todo, obviamente hay más de 60 implementaciones ÿousand tiene que haber diferencias. Pero insisto, aquí la clave es en asegurarnos que el objetivo, el producto final, responde al no vamos a decir al 100, %, que el 100 % es el objetivo, pero el resultado final tiene que responder al 99,9999 ,99 % de las exigencias del cliente desde el principio y en cada uno de los aspectos durante todo el proceso de desarrollo.
Y si os parece, dentro de las muchas metodologías que hay, vamos a hablar de Scrum.
Scrum es quizás una de las más populares en este poquito rato.
Es complejo el poder asegurar que podéis implementarlo, pero al menos vais a tener una primera aproximación para entender los conceptos básicos, poder profundizar en ellos y luego construir.
Hay que entender el objetivo de scrum máximo valor empresarial en el menor tiempo posible.
¿Por qué? Porque esto nos permite validar, valorar cada acción al final de cada sprint, poder corregir, modificar, adaptar lo que estemos realizando en función de nuestras características, las características de nuestro cliente y las características del entorno.
Obviamente dentro de una empresa, pues nuestro cliente es nuestra propia empresa y la empresa marcará esas características, esas prioridades, ojo, sin interferir en el proceso. Ahora veremos que un proyecto scrum es un proyecto auto organizado.
Los equipos se auto organizan y deciden cuáles son las fases a seguir y cómo siguen.
Cada etapa suele durar normalmente entre dos, tres, cuatro semanas abierto. Cada etapa, cada sprint viene marcado, o la duración de cada sprint, de cada etapa viene marcado previamente, antes de comenzar el desarrollo.
¿A qué me refiero? Que el sprint un no te durará dos semanas y el sprint tres te durará cuatro. No, acordamos que esto cada sprint va a ser dos semanas. ¿Vale? ¿Vamos a ver cuántos sprints podemos necesitar para entendéis? Para llegar, para lograrlo, etc. Etc. Y aquí la clave está siempre en los resultados, no en el rendimiento, porque el rendimiento significa que tenemos que ofrecer no el 100, %, sino el 110 % de nuestra habilidad.
Disculpas.
¿Por lo tanto, esto qué implica? ¿Que yo lo sé todo y lo que yo sepa de lo que yo tenga que realizar lo voy a hacer siempre igual? No.
Yo sé lo que sé, voy a aportar todo lo que yo sé, voy a hacer lo mejor posible, pero a la vez necesito ser permeable y accesible a las modificaciones externas y a cualquier mejora que pueda provenir del equipo.
Scrum se puede utilizar en desarrollos complejos y en desarrollos no tan complejos. Repito, una boda en algún proyecto educativo, lo he puesto en marcha y ha funcionado.
Os puedo asegurar que funciona y que los supuestos novios en aquel momento lo único que sintieron es que realmente no era su boda y que no se estaban casando de nada.
Pero el rendimiento, la efectividad y todos los agobios que eso incluye estaban disipados. ¿Por qué? Porque lo que evita son ese tipo de tensiones, ese tipo de incertidumbres.
Vamos haciendo lo que tenemos que hacer fase a fase.
Advierto los principios básicos, las bases de lo que es scrum es sencillo de entender, pero no siempre es tan fácil de poner en práctica o de dominar.
Además, en cada caso ÿ lo tendremos que hacer de manera, digamos, adaptada a las características de nuestra empresa, de nuestro equipo y de las personas que conforman el gran equipo.
Por lo tanto, esto no deja de ser sino un modelo de gestión para desarrollo de proyectos, pero que a partir de aquí lo podemos poner en práctica y en otros muchos aspectos, prácticamente en cualquier empresa. Hay muchas empresas que son 100 % scrum y funcionan perfectamente.
Vamos a ver algunos aspectos. Los seis principios de scrum el primero, el control del proceso empírico.
Todo lo que se prueba o todo lo que se hace, se prueba.
Al final de cada sprint, de cada etapa, se tiene que validar el proceso de evolución de lo que se está desarrollando.
Significa que el sprint no se podría cerrar si alguna de las fases previstas para ese sprint no han sido cerradas y sobre todo validadas. La validación no viene de un ser superior, viene del equipo.
¿Entendéis? Por lo tanto, las pruebas están por encima de las teorías.
En segundo lugar, auto organización.
En un equipo scrum no se asignan tareas, se asumen tareas.
¿Dicho de otra manera, Zweitausendein, hay que hacer a, b, c y d. Pues mira, yo puedo asumir perfectamente b y con ayuda de alguien, quizás con este otro, con esta otra persona puede puedo hacer e, qué tal? Al final todo el mundo va asumiendo sus tareas para estar al 100 % de rendimiento durante todo el periodo que dura el sprint o etapa.
Colaboración.
¿Yo ya he hecho mi trabajo, ya está hecho, ahora depende de los demás, no?
Yo hago mi trabajo para que los demás puedan hacer el suyo y en colaboración y conjuntamente con los demás.
Scrum es un reloj suizo.
El engranaje de los mecanismos está perfectamente tiene que estar perfectamente engranado y todas las piezas alineadas unas con otras.
Aquí no hay divos, aquí el mérito no es de fulanito, no, el mérito es del equipo.
El éxito o el fracaso es del equipo. La ventaja de este tipo de metodologías es que aumentan las opciones de éxito.
La priorización se basaba en el valor. Se basa en el valor.
Si os dais cuenta, al final de cada sprint hay que poder mostrar, ofrecer un producto mínimo viable.
Repito, no significa que sea un producto que se pueda ya comercializar, pero que mínimamente se va apareciendo poquito a poco más al objetivo final es aportar valor al contenido del proyecto.
Aportar ese valor implica que el producto mínimo viable ha de generar, ha de suponer un incremento con respecto al producto mínimo viable del sprint anterior.
Esto incluye también una asignación de tiempos. La asignación de tiempos es propia del grupo, no se reparten los tiempos. De nuevo, no hay un ser superior entregando tiempos.
Auto organización y desarrollo iterativo. ¿Qué significa? Que una vez que un sprint ha sido validado, va a poder cualquier otra fase posterior en el desarrollo ya está validada. Cuando el producto ya esté terminado, esas fases van a ser simplemente repetitivas. Lo que ya está aprobado, está aprobado y no se cambia porque está aprobado, porque es lo mejor que podemos hacer.
Y traducido, tenemos un backlog de producto, un registro de producto que digamos, es la idea general del producto dividida en pequeños bloques.
El backlog, el registro del sprint, son aquellas tareas que vamos a realizar durante un sprint, durante una etapa que durará, como pone aquí, de dos a cuatro semanas.
Cuando esté terminado. Y como veis en la parte de arriba indica 24 h. Cada 24 h vamos a tener una reunión de 15 min, no más, en la que vamos normalmente al principio del día, en la que vamos a comentar un poquito cómo nos fue ayer, dónde vamos hoy y qué problemas hemos tenido o cómo podemos solucionar problemas. ¿Para qué?
Para conocer también los problemas de los demás y apoyar allí donde sea necesario apoyar.
Repito una vez más, el éxito y el fracaso de esta metodología o de la aplicación de la metodología es del equipo.
No vale que fulanito entregó otra tarde su parte. No.
Si fulanito entre optar de su parte es porque no se le ha ayudado, porque no ha tenido la suficiente ayuda o la suficiente capacidad y no lo hemos sabido ver. ¿Las responsabilidades del equipo no es sólo de fulanito, de acuerdo? Ÿ y finalmente, el producto final, al final de un sprint es un producto mínimo viable que genera un incremento con respecto al producto mínimo viable del sprint anterior.
Incremento, mejora, completarlo de alguna manera, etc. Por lo tanto, aquí ya estamos viendo no solamente el desarrollo, sino también los tres personajes que hay en un equipo scrum, que los vamos a ver enseguida.
Dentro de un equipo scrum hay tres grupos de personajes que vamos a ver el product owner, el propietario de producto, el scrum master y el equipo de desarrollo. ¿Por decirlo de alguna manera, nadie es más importante que nadie y todos son todos somos necesarios, pero nunca imprescindibles, vale? Pero sí que somos necesarios para el desarrollo del producto. ¿De acuerdo?
¿Y cuál es el marco de scrum?
Fundamentalmente, en cuanto a funciones, ya hemos hablado de los tres aspectos el propietario del producto, el scrum master y el equipo de desarrollo.
Lo que se denominan ceremonias, es decir, las actividades que envuelve o que implica la aplicación de scrum, la planificación de un sprint, la revisión, la retrospectiva y la reunión diaria.
Y lo que se denominan artefactos el registro de producto, el product backlog, el registro de sprint y la burndown chart, que ahora veremos lo que es.
Vamos a comenzar por las funciones tres el propietario de producto, el scrum master y el equipo de desarrollo.
¿Básicamente, el propietario de producto, qué es lo que hace?
Maximizar el retorno de la inversión. El propietario de producto es la persona que va a ser el nexo entre la empresa o el cliente y el resto del equipo.
Va a ser quien filtre de alguna manera las características o las necesidades del cliente, quien filtre las características y las necesidades del entorno para preparar las distintas tareas que habrá que realizar para poder tener el producto final.
Evidentemente es quien se encarga de la pre planificación o preproducción, por decirlo de alguna manera.
Es quien va a asignar o quien va a decidir.
Yo creo que para este sprint podríamos realizar esta tarea, esta tarea y esta tarea, pero no tiene la última palabra. La última palabra la tiene todo el gran equipo scrum que decide si podemos hacer todo esto y esta otra o no. Podemos hacer solamente estas tres y no las cuatro que has indicado.
¿Entendéis? No, no es un jefe, es un catalizador, por decirlo de alguna manera.
Después tenemos el scrum master, que es quien se encarga de, vamos a decir, velar porque los principios scrum se mantengan, es decir, por asegurarse la cohesión del equipo, el trabajo del equipo y la efectividad y eficiencia del equipo.
¿De acuerdo?
También tendrá sus tareas, pero digamos que es un poquito el que quien está, no vamos a decir coordinando, pero sí supervisando. Y finalmente, el equipo.
El equipo que serán personas especializadas en diferentes áreas y que forman un equipo. Lo he comentado, David, al principio, esto o el concepto inicial proviene del scrum, de las melees, del rugby.
Todos sabemos que un equipo, ya sea de rugby, de fútbol, es algo más que 15 en el caso del rugby, u 11 personas en camiseta de calzoncillos detrás de una pelota.
Un equipo es mucho más que todo eso.
Un equipo tiene mucha más fuerza, mucha más organización, pero un equipo es efectivo cuando se producen las interacciones entre las distintas áreas. Cada uno tiene su especialidad o su zona de especialización, pero eso no significa que si hace falta otros le apoyen, que esa persona apoye a otros cuando también le haga falta.
Es decir, funcionar como un equipo.
Y la potencia de un equipo es muy superior al número de integrantes, siempre y cuando sean efectivos y eficientes. Por lo tanto, aquí la clave está en el compromiso de todos los integrantes del gran Equipo Scrum. Si los integrantes del gran Equipo Scrum no están comprometidos, el proyecto puede fracasar. Y la mayoría de los fracasos de aplicación de esta metodología no provienen de una implementación inadecuada, provienen de la falta de implicación o compromiso por parte de los integrantes.
Y finalmente vamos a lo que serían las ceremonias.
¿Qué son las ceremonias? Pues son, digamos, las distintas reuniones, eventos, etc. Que tienen lugar antes, en y después de cada sprint para valorar lo que se está haciendo y mejorar lo que se puede hacer, siempre desde un punto de vista constructivo.
Aquí el objetivo no es juzgar lo que se hace, el objetivo es mejorar lo que se está haciendo a nivel global.
Por lo tanto, vamos a comenzar. Los sprints, como hemos dicho, son las etapas.
Cada etapa está acordada por los tres integrantes del gran equipo y de esta manera todos trabajan al 100 % en la efectividad y en eficiencia. No significa que lo van a tener antes de esas dos o cuatro semanas, probablemente no, pero seguro que lo que se ofrece al final de ese sprint es el mejor producto posible, producto mínimo viable posible que se puede desarrollar.
¿De acuerdo?
Esto vamos a tenerlo en cuenta.
Por lo tanto, cada sprint ha de tener una fecha de inicio, 1 fecha de finalización y así con todos. ¿Eso qué significa? Que antes de empezar el proyecto sabemos cuántos son los sprints que va a haber, cuál es la duración de cada uno de ellos y cuál es el número de sprints necesarios para poder tener el producto finalizado.
Y aquí tiene mucho que ver el cliente, lógicamente también el cliente tiene que estar implicado en toda esta fase, digamos como un personaje omnisciente, pero que también participa para poder optimizar su inversión. ¿De acuerdo?
Recuerdo que los sprints, las etapas son de duración fija, que no pueden variarse de uno a otro y que el número de sprints viene dado por el valor, o sea, por la cantidad de trabajo que se puede realizar y está acordado por el gran equipo.
La reunión diaria de scrum durante el desarrollo del sprint nos reunimos todos diariamente, 15 minutitos de pie, que no es necesario mucho más.
¿Para qué?
Para hablar de lo que se hace, de dónde estamos.
Para hablar de dónde estamos, qué hemos hecho, qué vamos a hacer hoy y qué nos ha impedido avanzar adecuadamente. No es para Oye, yo tengo que. No. Luego ya tienes tiempo, después de la reunión para hablar con el scrum master y poder articular ese problema.
¿Esto qué facilita? Que en esos 15 min todos trabajamos, todos sabemos lo que todo el mundo tiene que hacer ÿousand lo que nosotros tenemos que hacer hasta la siguiente reunión, que será 24 h más tarde o 23 h 45 min más tarde.
¿De acuerdo?
¿Y son las 15 las tres preguntas básicas que hiciste ayer qué vas a hacer hoy y que te impide entregar, desarrollar más o mejor producto?
¿De acuerdo?
Y a partir de aquí, la revisión del sprint.
Al final de cada sprint todos lo valoramos, digamos que nos hacemos una presentación de ese nuevo producto mínimo viable que hemos realizado.
Es una especie de pequeño autohomenaje y a la vez filtro crítico para valorar qué podemos mejorar en futuros sprints.
La retrospectiva del sprint. Al final de cada sprint, en una reunión de 15 30 min, tenemos que valorar lo que hemos hecho y cómo lo hemos hecho, qué ha funcionado para poderlo repetir, qué no ha funcionado para corregirlo o eliminarlo y buscar las mejores soluciones que podamos aportar en este sentido.
Y ya entramos en las ceremonias.
Finalmente, las ceremonias, el backlog de producto, el registro de producto Ÿousand, la lista de tareas que prepara el scrum master, perdón, el product manager, el jefe de producto, el propietario de producto para desarrollar el producto final. Son las pequeñas historias, las pequeñas tareas que debemos realizar.
Y como indico aquí, el cómo, las tareas técnicas y la duración del proceso lo determinará el equipo, no lo determina el Product Owner.
¿Queda claro?
Product Owner es un facilitador, un catalizador, no es el jefe, simplemente tiene unas funciones específicas, es alguien del gran equipo que tiene unas funciones específicas.
Por lo tanto, vamos a pensar siempre que el Product Owner no tiene todas las historias, todas las tareas desde el principio hasta el final, antes de empezar. No. Tiene, digamos, una aproximación para que podamos debatirlo para los primeros sprints, pero su reparto de tareas tiene que estar basado únicamente en lo que hay para el primer y segundo sprint.
Y poquito más.
Y poquito más, porque lo demás tendremos que adaptarlo a los desarrollos, a las características, a los obstáculos que vayamos viendo.
¿De acuerdo? Por lo tanto, lo tiene que continuamente crear y refinar, estimar duraciones, costes, etc. Y priorizar qué tareas hay que realizar antes y qué tareas hay que realizar después. En el ejemplo que he puesto hace un ratito, si estamos fabricando un coche y el primer sprint estamos trabajando sobre las ruedas y el chasis, evidentemente la calidad de la goma de las llantas tiene que ser una prioridad.
No lo vamos a dejar para tres sprints más tarde.
¿Entendéis, no?
El backlog del sprint. ¿Qué es el backlog del sprint? Son las historias, las tareas que vamos a realizar durante ese sprint que el equipo, que el gran equipo hemos asumido, aceptado, comprometido, que vamos a llevar a cabo.
¿Aquí el product owner sí que puede, en un momento dado, reordenar la prioridad de tareas en función de características externas, pero dentro de esas tareas que ya están asumidas dentro del sprint, de acuerdo?
Y tenemos que asumir que será el suficiente número de tareas para cubrir el periodo completo de duración del sprint, que no nos vamos a quedar cortos de trabajo, pero que tampoco nos vamos a quedar largos.
Por eso es una decisión de equipo, es una decisión de todos, de nuestra capacidad individual y de nuestra capacidad como equipo.
¿De acuerdo? Aquí tenemos una valoración de cómo podemos trabajar, prever estas duraciones, estas tareas y cómo podemos ir valorando un sprint con las tareas, con las historias previamente, con las que quedan por hacer, con las que están en proceso y lo que pone done, las que están hechas. Ojo, que esta definición es muy importante. La columna de la derecha es básica porque lo que está en esa columna ya no se toca, ya está hecho.
Está hecho, aprobado y consensuado por el equipo.
Es decir, no hay posibilidad ya de mejoras.
Podrás implementar mejoras en lo que está en progreso y a futuro, en lo que está por hacer, pero lo que ya está hecho, está hecho y se supone que no puede haber mejoras porque las has ido implementando conforme ibas desarrollándolo.
Finalmente, la Burndown chart. ¿La Burndown chart qué significa? ¿Para qué sirve?
Fundamentalmente para monitorizar el proceso de cada sprint, para asegurarnos que estamos en tiempo trabajando, desarrollando el producto, cada una de las tareas para el sprint en el marco temporal que previamente habíamos analizado.
¿Nos queda esto claro?
Por lo tanto, nos permite ver lo que hacemos a nivel diario, ver lo que nos queda por hacer y ver cómo estamos evolucionando para saber dónde tenemos que apretar y si estamos dando el 100, %, dónde tenemos que dar el 110.
Como veis, la lista azul o la línea azul marca Zweitausendein, la estimación, la lista roja o la línea roja el ritmo real y la amarillo verde no lo veo muy bien, lo que marca es la velocidad de desarrollo de cada etapa o de cada actividad, de cada tarea.
En este caso incluso hemos acabado un poquito antes de tiempo.
Siempre es mejor eso que lo contrario.
Evidentemente, hablar de scrum significa muchas cosas. Hablar de scrum implica una explicación un poquito más en profundidad y sobre todo una aplicación práctica, pero yo reto a profundizar en el tema y adaptarlo. Sí que os voy a comentar un pequeño secreto. En mi empresa utilizamos esta metodología como método de trabajo.
Lo único que no hacemos son, por ejemplo, las reuniones diarias. No las hacemos. ¿Por qué? Pues porque estamos a cada persona en sitios distintos, en ubicaciones físicas distintas. Entonces establecemos las reuniones cada 48 h en lugar de cada 24.
Son pequeñas adaptaciones que se pueden realizar.
Nadie va a venir a validar si somos 100 % scrum o somos 89 % scrum. ¿Entendéis lo que quiero decir?
Aquí lo que cuenta es si tu rendimiento es el óptimo y te sirve para desarrollarlo, Scrum ha demostrado que para muchos productos, para muchas tareas, para muchos servicios resulta efectivo, resulta productivo y resulta eficiente.
Le vamos a dar una oportunidad.
Por mi parte, esto es todo en esta pequeña introducción.
Espero que os haya gustado y estoy a vuestra disposición para lo que podáis necesitar. Un saludo y muchísimas gracias.
