Metodologías

Scrum en la práctica

Te proponemos una serie de experiencias o de escenarios que resultan de gran utilidad, ya que son preguntas que pueden aparecer en la parte práctica de los exámenes de certificación de Scrum.

Publicado el 29 de Septiembre de 2019
Compartir

¿Qué ocurre si en un Daily Scrum se entromete el Product Owner?

Si el Product Owner decide entrometerse en un Daily Scrum sin la aprobación de nadie, puede ocurrir que el Daily Scrum cambie el objetivo para el que se ha diseñado.

El Daily Scrum está creado para que los miembros del equipo se sincronicen y busquen y eliminen los impedimentos, por lo que al entrometerse el Product Owner, o cualquier otra persona externa al equipo de Scrum, se puede convertir en una reunión de reporte a cualquier departamento, y ese no es el objetivo.

Además, se puede alargar más tiempo de lo necesario y las personas que participan se pueden sentir intimidadas y no van a hablar con soltura o directamente no van a hablar. También es probable que el Product Owner pregunte continuamente para conocer el progreso, intente inculcar qué es lo que tienen que hacer, etc.

Por todo lo comentado, su presencia es claramente una actitud tóxica desgraciadamente os la podéis encontrar. En estos casos lo que se debe hacer el Scrum Master, ya que mayormente la responsabilidad es suya, es evitarlo y proteger al equipo de estos factores externos.

¿Qué ocurre cuando un miembro del equipo lo abandona?

Puede ocurrir que un miembro del equipo se vaya de la empresa, o bien que uno de los miembros se marche a otro equipo y entre un nuevo miembro a sustituirlo.

En estos casos lo normal es plantearse algunas preguntas como ¿qué ocurre con los Sprints, con las capacidades, las estimaciones y el tiempo que se suele tardar? ¿seguimos al mismo ritmo, bajamos el ritmo? ¿cómo hacemos comprender a los demás que habido un cambio en el equipo?

Cuando entra una persona nueva en el equipo, el trabajo debe seguir adelante. Hay que seguir entregando los Sprints, pero va a tener una repercusión en la velocidad, ya que la misma se va a ver ligeramente reducida en consecuencia al periodo de adaptación de esa persona nueva.

Este aspecto hay que tenerlo en cuenta y es algo de lo que deberían de ser conscientes todas las personas que del equipo.

¿Cómo identificamos y eliminamos las dependencias?

Para identificar las dependencias y eliminarlas, la recomendación es programar una reunión por Sprint o por semana, según las dependencias que tenga cada proyecto. Si son dependencias que aparecen puntualmente, por lo menos una reunión al Sprint sería lo recomendable.

No tiene que ser el Scrum Master, puede ser una persona elegida por los miembros del equipo, que incluso la persona elegida puede rotar, o acudir junto al Scrum Master.

En definitiva, la idea es que esa persona se reúna con otra persona de otro equipo y, entre ambos, identifiquen las dependencias, las lleven en común y busquen un plan de acción para trabajar en su eliminación.

Si convivimos con las dependencias, pueden aparecer más y pueden llegar a complicarse, que es lo que finalmente trae problemas.

¿Quién es el responsable del progreso de desarrollo de un equipo?

El responsable del progreso de desarrollo de un equipo es el propio equipo, por lo que el equipo debe saber dónde se encuentra cada día, los avances que se van haciendo, si van por la dirección correcta o si hay que corregir rumbo, etc.

El propio equipo es el que tiene que tener protagonismo y tiene que ser consciente del trabajo que se está haciendo y si se están incumpliendo las normas, porque tiene que aprender a ser auto gestionable, y para conseguirlo deben ser conscientes de la responsabilidad que conlleva gestionar tu propio progreso.

¿Quién ordena el Product Backlog?

El Product Backlog es responsabilidad del Product Owner, por lo que es la persona que indica cuáles son ítems con más importancia, los que se tienen que hacer primero, el orden de los elementos dentro de los Sprints, etc.

El equipo le puede dar soporte y le puede dar recomendaciones, al igual que el Scrum Master. Ellos le pueden sugerir y le pueden dar apoyo, pero la responsabilidad no deja de ser del Product Owner.

¿Cuál es la responsabilidad del Scrum Master?

La responsabilidad del Scrum Master es que la empresa tenga una cultura de Scrum, que se cumplan todas las reuniones de Scrum, que existan los roles de Scrum y no otro tipo de roles, que las reuniones se adapten al horario establecido para ellas, etc.

En definitiva, su responsabilidad básica es que se cumplan las normas de Scrum.

¿Puede haber dos Product Owners?

No es posible, porque no puede haber dos personas marcando las prioridades.

Los roles están muy claros y bien especificados en la guía de Scrum, por lo que solo puede haber una persona con el rol de Product Owner, al igual que ocurre con el rol de Scrum Master.

¿Puede existir una figura que sea Product Owner y Scrum Master al mismo tiempo?

No, porque estas dos figuras son muy poderosas, y porque en conjunto, para los miembros del equipo sería también una figura muy confusa, no tendría sentido.

Debemos ser pragmáticos, adaptar la metodología a nuestras necesidades, pero no debemos inventar nuevas figuras.

¿Cuándo un miembro del equipo se hace responsable de un Backlog Item?

Nunca, porque las historias de usuario no se asignan a los miembros del equipo, se asignan al equipo.

Debemos ser conscientes que, aunque un miembro del equipo esté trabajando en esa historia de usuario, no es el responsable de la misma, el equipo es el responsable.


Compartir este post

También te puede interesar...

Scrum: Fundamentos y buenas prácticas

Curso de Scrum: Fundamentos y buenas prácticas

2 horas y 11 minutos · Empresas

Descubre los fundamentos y las buenas prácticas a la hora de trabajar con Scrum para sacarle el mayor partido posible a esta metodología agil.

  • Productividad & habilidades
Scrum técnico

Curso de Scrum técnico

2 horas y 22 minutos · Empresas

Aprende con nosotros qué es Scrum, cuál es su filosofía y las herramientas que utilizamos en la gestión de proyectos Agile. Además, será objetivo del …

  • Gestión de Proyectos y Estrategia
Artículos
Ver todos