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:
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):