Blog Post

Agile Coffee I

Antonio Jesús Ruiz Córdoba • 14 de marzo de 2023

¿Primer trabajo como Scrum Master? ¿Qué hacemos con tareas burocráticas? Hablemos de ello.

Después de mucho tiempo con intención de hacer algún tipo de evento donde podamos tratar temas que antiguos alumnos puedan necesitar consultar y debatir, por fin hemos conseguido cuadrar una sesión que intentaremos hacer de forma periódica.

Le hemos llamado "Agile-Coffee", por la similitud a "tengamos una charla informal en el tiempo que nos tomamos un café juntos".

En esta primera edición hemos hablado de dos temas principalmente:

  • "Cómo empezar a trabajar de Scrum Master después de conseguir la certificación"
  • "Cómo lidiar con tareas burocráticas que no generan valor a lo largo del Sprint"


En el primer punto estuvimos hablando de que efectivamente la experiencia es muy importante, como en cualquier trabajo, pero a la hora de conseguir esa primera oportunidad (como en cualquier otro trabajo) tenemos que buscar cubrir esa falta de experiencia con otros elementos. Entre otros, hablamos de compartir conversaciones con otros Scrum Master para conocer qué hacen, qué harían o qué dejarían de hacer en distintos casos; aprovechar las preguntas que te hagan durante una entrevista para moverlas en foros de confianza donde te puedan dar respuesta a qué hace un buen profesional en esos casos y llevarte así parte de esa experiencia; participar en foros, debates, entrevistas, etc. para seguir evolucionando e incluso intentar hacerlo de forma activa; e incluso la posibilidad de buscar algún lugar conocido donde ofrecerte para hacer unas prácticas o un acompañamiento al Scrum Master de forma gratuita.

Al principio, cuando la experiencia es un déficit en nuestro CV todo aquellos pasitos pequeños que podamos añadir hará que vayamos mejorando poco a poco y toda entrevista es una experiencia más que nos ayudará a conseguir ese primer trabajo.


Sobre el segundo punto, vimos que si una tarea burocrática o repetitiva, pero que no da valor al producto/servicio, no debería estar en el Sprint Backlog ni en el Product Backlog.

Incidimos en evaluar bien por qué se hacen tareas que no dan valor al producto, ya que por defecto estaríamos hablando de un "desperdicio" (algo que nos cuesta tiempo/esfuerzo/dinero y que no hace que nuestro producto/servicio sea mejor. Parte de nuestro trabajo es evaluar esos desperdicios para tratar de reducirlos al máximo e incluso eliminarlos.

Si no fuera posible eliminarlos, hablamos de la posibilidad de crear un Backlog específico para ello. Scrum nos prescribe tres artefactos, pero no impide tener más, por lo que si fuese necesario podríamos contar con otro listado de "cosas por hacer". Serían "cosas" que no nos van a ayudar a conseguir el objetivo del Sprint, de ahí que no estén en el Sprint Backlog.

Hubo un comentario interesante sobre la posibilidad de añadir esos puntos al DoD. Es algo factible, todo depende del caso y de a qué nos refiramos con ese tipo de "tareas burocráticas". Si es algo que tiene que hacerse sí o sí antes de que un PBI se dé por terminado, es perfectamente válido (de hecho tiene que ser así).

Además, hablamos de los "Spikes", que son tiempos dedicados a profundizar sobre algún tema que requiere más investigación o conocimiento antes de iniciar un PBI, como si fueran PoC (Pruebas de Concepto). Esos "Spikes" tampoco deberían estar en el Sprint Backlog, puesto que no es algo que nos vaya a ayudar a conseguir el objetivo del Sprint, puesto que generalmente son tareas que salen de los Refinamientos necesarias para aclarar algo (el uso de una herramienta, tecnología, etc.). Normalmente un Spike va a ayudar a que un PBI que aún está en el Product Backlog sea candidato a entrar en la siguiente iteración, por lo que no deberíamos hacer Spikes de PBI que ya estén en el Sprint Backlog. Sin embargo, y eso sería ideal, sí que podríamos hacer el PBI y el Spike asociado en el mismo Sprint si el PBI se añade a posteriori del Sprint Planning porque hayamos finalizado lo planificado antes de tiempo y podemos abordarlo antes de que finalice el Sprint.


Del feedback solicitado de esta charla, gustó mucho que hubiera participación de los asistentes, compartiendo sus experiencias; y el tema del trabajo, del cual hubo varias propuestas, por lo que en la próxima charla profundizaremos más en estos puntos.


Si te perdiste la sesión, aquí te dejo un vídeo con toda la charla (1h):


Otras entradas del blog:


Por Antonio Jesús Ruiz Córdoba 14 de noviembre de 2024
Diferencias entre el Agile Coach y el Scrum Master
Por Antonio Jesús Ruiz Córdoba 10 de octubre de 2024
Encontrarás la solución pasito a pasito
Por Antonio Jesús Ruiz Córdoba 5 de septiembre de 2024
10 similitudes entre Scrum y un cuchillo
Si el equipo nunca falla, tienes un problema.
Por Antonio Jesús Ruiz Córdoba 5 de mayo de 2024
¡Celebra los fallos!
Por Antonio Jesús Ruiz Córdoba 3 de marzo de 2024
La absurda necesidad de vender certeza en la incertidumbre
Por Antonio Jesús Ruiz Córdoba 2 de febrero de 2024
Evaluamos la progresión de Agile
Por Antonio Jesús Ruiz Córdoba 7 de enero de 2024
Deja de ser un buen Scrum Master para ser un gran Scrum Master
Por Antonio Jesús Ruiz Córdoba 3 de diciembre de 2023
Necesitamos menos "managers" y potenciar el "self-managment"
Por Antonio Jesús Ruiz Córdoba 5 de noviembre de 2023
Consejos para facilitarte tus primeros pasos como Scrum Master
Por Antonio Jesús Ruiz Córdoba 6 de octubre de 2023
Charla de Octubre-23' del Agile-Coffee
Más entradas
Share by: