INSTITUTO TECNOLÓGICO DE ESTUDIOS SUPERIORES DE OCCIDENTE

Gestión ágil de proyectos

Desafío 1 – SCRUM

David Hernández Camacho

Omar Daniel Ponce Márquez

José Eduardo Hurtado Gómez

3 de marzo de 2023
Explicación del progreso del equipo:
Durante las primeras semanas había una idea errónea sobre cómo trabajar bajo el
nuevo margen de trabajo por lo que el equipo no mantuvo tareas concretas para
cumplir durante cada sprint, siendo incluso más de las que el equipo podía
completar. A medida que se introdujeron más miembros, entre ellos el
especialista, se trató de adaptar el equipo a cómo debería ser cada sprint, pero a
partir de la quinta semana comenzaron los problemas con el nuevo integrante de
desarrolladores (presuntamente Wong). Esto ocasionó que no se tuviera un
progreso en el equipo y por lo tanto no se completaron los compromisos
propuestos por el equipo.

Al finalizar la semana 6 se cumplieron todos los compromisos propuestos, y es en

este punto cuando observamos un aumento en la productividad con respecto a la
semana 5 (Justo después de que Wong saliera de vacaciones y se separara
temporalmente del equipo).

Problemas del equipo:

Problemas más relevantes:

1. Existe una pobre comunicación sobre los problemas que tienen los
miembros del equipo y es por ello que genera que haya conflictos (como lo
son con Pio, Jess y Wong) o faltas de interés a las demás opiniones del
equipo.
2. Dentro del equipo existe un poco iniciativa para proponer nuevas soluciones
lo que desmotiva a otros miembros, tal como el caso de Frank que es
ignorado, a opinar en las juntas y se continua con sprints que se entregan
con un poco progreso de mejora.
3. Poca motivación en el equipo, principalmente por Carlos lo que ocasiona
que no se involucre activamente en las juntas y no propone nuevas
soluciones que mejoren en otros aspectos del equipo.
 4. Tom al tener mucha participación en las reuniones de equipo siendo
director, afecta al tener control total de las juntas y bajar la moral del equipo
al estarlos comparando con el equipo espada.
5. Batman se encuentra en 2 equipos a la vez, provocando que exista menos
focus en su aportación a los equipos. Se encuentra activamente haciendo
nada.

Otros problemas:

6. La relación de Joseph con el equipo, como Product Owner, se involucra

además en tareas que deberían ser consideradas por el SCRUM Master y
no las que ve en otras fuentes.
7. La forma en que Joseph recopila la información para entender a los clientes
es escasa dado que se salta entrevistas con los clientes y está orientado
demasiado a su criterio.
8. Hay demasiados miembros en el equipo espada. Hay 10 miembros en el
equipo cuando lo recomendado es que no sean más de 8.

Explicación de la elección de problemas:

Se colocó como principal problema la comunicación dado que en el equipo a
medida que se fue expandiendo el equipo en cada sprint, provoco que por pobre
introducción al inicio del equipo se produjera que la mitad estuviera en conflicto.

Por otro lado, otro problema relacionado con la comunicación es la falta de interés
para participar en nuevas soluciones y que se cumplan. Esta es la situación de
Frank, pero se complemente con el primer problema identificado dado que no se
llega a un acuerdo por todos los miembros del equipo y se lleva a cabo una tarea
de mala gana.

Adicionalmente, existe el problema de motivación en el equipo, específicamente

hablando de Carlos, esta falta de motivación provoca desinterés en el proyecto y
resulta en poca participación en las juntas y la falta de propuestas o soluciones en
el proyecto. Esto en conjunto con el resto de los problemas mencionados reduce
la productividad en el equipo.

El problema de ignorar las responsabilidades del rol de cada miembro involucró

tener una participación de Joseph en asignaciones que deberían ser corregidas
por el SCRUM Master, mismo que estuvo cómodo en no hacer nada.

Para finalizar, está el problema claro con el Scrum Master, siendo que inicialmente
está en dos equipos y por ello no puede haber un compromiso total por la mejoría
del desarrollo del producto, y que además de ello no existe una participación
existente por parte del SM en cualquier actividad del equipo siendo que decide
hacer activamente nada.

Acciones correctivas
1. Separar las tareas del sprint de las decisiones que propone Tom como
prioridad. De esta forma, el trabajo de Tom si realiza las consultas a los
clientes entonces se pueden enriquecer cuáles compromisos se deben
cumplir para el siguiente sprint y que no sean interrumpidas.
2. Reducir el tiempo que dura el daily SCRUM a no más de 15 minutos,
además de que sean más interactivas (Motivando a que más personas
participen activamente).
3. Enfatizar que como equipo deberían de tomar críticas y opiniones de
manera constructiva y profesional para poder tener un mejor ambiente
profesional.
4. Promover la participación de ideas que cada miembro detecte para hacer
más dinámicas las tareas que cada uno es responsable en un sprint,
motivando cada integrante para desarrollar su compromiso.
5. Abrir un espacio en las juntas para escuchar nuevas propuestas en el
equipo.
Propuesta retrospectiva para el siguiente sprint
Durante el próximo sprint asignar a Batman como responsable de organizar los
Daily Scrum mientras Joseph puede trabajar en entender las necesidades del
cliente y el mercado. A lo largo del sprint, Batman podría establecer una prioridad
clasificada en las tareas que requiera el cliente, retroalimentadas por Joseph, y
aquellas relacionadas con corregir errores. En la planeación del Sprint Backlog se
trataría de resolver primero los problemas del producto y eventualmente introducir
las tareas relacionadas con las funcionalidades del cliente. Para este último punto,
es cuando el trabajo en pares se puede aplicar a fin de corregir los errores y evitar
trasladarlos a otro Sprint.

Propuesta sobre prácticas o técnicas para mejorar la forma de

trabajar del equipo

Cada miembro identifique las tareas que estén dentro de sus habilidades en las
que le gustaría trabajar para el próximo sprint y, durante los Sprint review, buscar
relacionar cómo podrían aplicar las responsabilidades que se asignan durante
cada Daily SCRUM con aquellas propuestas. Al igual que, se podrían definir
parejas diferentes cada semana en el que se encarguen de completar diferentes
tareas, esto con el objetivo de promover la colaboración, y disminuir la cantidad de
errores humanos al existir retroalimentación entre los desarrolladores.

Aprendizajes del desafío

Ciertamente podemos decir que durante el desafío en un inicio no se tenía una
idea muy clara de cómo tenían que ser las cosas al solo tener los conceptos de los
pasos o de cómo debería funcionar un modelo SCRUM en teoría, pero a medida
que fuimos adentrándonos más y más con este ejemplo presentado, nos
empezamos a dar cuenta de muchísimos factores que entran en juego al tener
presente este desarrollo del equipo durante 6 semanas, y con ayuda de las
gráficas y de las opiniones del equipo es posible darse una idea en qué dirección
va el equipo y cuáles son los claros problemas de este, como también los que no
son tan claros, así como cuál es el mejor camino para resolver dichos problemas.
Con este desafío nos aproximamos a una situación cotidiana donde las soluciones
que planteamos pueden ser distintas según el contexto del progreso en el equipo y
de los miembros, lo cual fue necesario tener información previa para plantear una
mejor solución.

Bonus:

Grafica 1:

El significado encontrado para la flecha en la gráfica uno la podemos ver

representando la brecha entre el número de ítems trabajados completados y los
que están en proceso en la fecha del 10/05.

Grafica 2:
Esta gráfica muestra el tiempo necesario para completar las tareas que se estaban
trabajando durante dos días.

Grafica 3:

Entre estos puntos se muestra el lapso que se tardó en recuperar el trabajo y

continuar con la frecuencia de tareas llevadas a cabo.

Grafica 4: