Para resumir, estamos construyendo un producto y he introducido y luego implementado el marco Scrum para la gestión de productos. Ha estado funcionando extremadamente bien, y mi equipo ha hecho un trabajo increíble.
El problema que tengo ahora es que la parte interesada principal está empezando a tener hambre de funciones hasta el punto de que la calidad de los entregables se ve afectada por una mayor cantidad de elementos en el sprint.
Cada vez que hacemos un buen trabajo, es decir, cumplimos con el sprint, la semana siguiente, la parte interesada solicita más características. Él siente que debido a que cumplimos con el sprint, podemos hacer más trabajo la semana siguiente.
(En este momento, quiere que se entreguen 3 funciones por semana)
Entonces mi equipo tiene que compensar esto aumentando su velocidad. Eventualmente, ha llegado a un punto en el que en un sprint nos arrojaron el fregadero de la cocina y se espera que entreguemos el triple de funciones en relación con los sprints anteriores. Debido a la mayor velocidad, eso también significa que aparecen más errores de las funciones que se apresuran a la producción.
Ahora estoy en una situación en la que estamos empezando a retrasarnos en nuestros sprints, y mis compañeros de trabajo se quejan de que la carga de trabajo es demasiado. También estoy recibiendo mucho más calor de parte de las partes interesadas por no completar todo el trabajo que se prometió. En nuestra próxima reunión de equipo, pienso hablar con mi parte interesada con el equipo de desarrollo sobre esto, ¿es una buena idea?
¿Cómo puedo manejar esto?
De hecho, tengo que discrepar hasta cierto punto con David Espina. Es esencial en Scrum entender quién posee qué parte del proceso.
Al permitir que el PO (o, peor aún, una parte interesada) dicte lo que se convierte en un Sprint, está disminuyendo la efectividad del equipo y poniendo en riesgo la calidad de su trabajo, como ya señaló en su publicación. Esto no quiere decir que el ScrumMaster o el propietario del producto no puedan alentar al equipo a asumir más o incluso guiarlos hacia un Sprint Commit agresivo, pero nadie más que el equipo puede comprometer un elemento en el Sprint Backlog.
En su lugar, me tomaría un tiempo para explicarles a las partes interesadas y a los PO que, miren cuánto más estamos haciendo con Scrum: no pueden esperar un milagro en cada Sprint. La velocidad generalmente aumentará, pero a veces también disminuirá (ya sea que el equipo haga una mala estimación o que algo sea un 8 "pesado" en lugar de un 8 "ligero", por ejemplo). Les diría que debemos dejar que el El equipo de desarrollo hace lo que mejor sabe hacer y confía en que el equipo se comprometa tanto como sea posible con un Sprint sin poner en peligro la calidad de las características que se están entregando.
No soy muy quién está empujando a su equipo. ¿Usted o el titular de la participación?
1: obviamente, cualquier equipo necesita ser alentado y desafiado constantemente para lograr más y ser más productivo.
2: de nuevo, obviamente, independientemente de 'lo que dice scrum', los plazos son importantes si desea que le paguen.
¡Pero! El equipo de desarrollo debe estimar las tareas en el registro pendiente y la velocidad del sprint anterior debe brindarle una estimación de cuántas tareas "hay" en el próximo sprint.
Si el equipo está presionado para hacer estimaciones más bajas, no cambia la cantidad de trabajo realizado, solo el número de velocidad.
Si la parte interesada está satisfecha con más funciones y tal vez menos pruebas o menos detalles sobre cada función, entonces esa es su decisión y debe reflejarse en las historias. Todos sabemos que el último 10 % de una historia suele ocupar el 90 % del tiempo.
Si usted o la parte interesada están presionando directamente al equipo para que trabaje más duro, más rápido o más horas, eso es solo una decisión de la gerencia sobre si cree que están holgazaneando o no.
Sin embargo, su maestro de scrum debe proteger al equipo de este tipo de interacción directa con las partes interesadas.
Subir el listón es algo bueno. Deberías respaldar esto y seguir presionando para obtener más. Agregar desafíos a un equipo hace que el equipo descubra cómo enfrentar esos desafíos, y muchas veces un equipo muy pesimista que predice que "no se puede hacer" lo hace. De alguna manera, los equipos se adaptan e innovan.
También mitiga cosas como la Ley de Parkinson y el Síndrome del Estudiante cuando desafía constantemente a un equipo que cree que 'no se puede hacer'.
Y estoy de acuerdo en que esto no es sin costo y riesgo. Debe monitorear esas cosas y observar la moral del equipo, los problemas de densidad de defectos, las quejas de las partes interesadas cuando no se cumplen sus expectativas, etc. Sin embargo, creo que se sorprendería de cuántos de esos costos y riesgos en realidad no se materializan cuando piensa lo harían.
Es interesante sobre los valores de planificación y las expectativas de las partes interesadas. Planifique 2 características y consígalas en un período de tiempo determinado. Planifique para 4 y obtenga 3 en el mismo período de tiempo. El primero que cumpliste una meta. El segundo te perdiste tu objetivo. Pero, ¿cuál es realmente mejor?
EDITAR: Para el comentario de @ bobo2000: esperaría que hubiera un punto de rendimientos decrecientes. En mis observaciones, ese punto está más lejos de lo que muchos creen o predicen. Sin embargo, si cree que está en ese punto, entonces necesita sentirse realmente cómodo diciéndole a su cliente 'No'. Si elige decir que sí al desafío, entonces necesita escalar de una manera muy formal y en voz alta los riesgos que ve, por ejemplo, es muy probable que no logremos todos los objetivos en este sprint, o es probable que veamos un aumento en Los defectos de gravedad 1 y 2 dan la vuelta. En algún momento, debe comenzar a controlar la conversación. Su cliente va a empujar y empujar porque lo ven desde el punto de vista de 'maximizar el beneficio por cada $ gastado'. Di no y aumenta el riesgo. ¡Esto es parte de tu trabajo como PM! Buena suerte.
@Rubberduck: El aumento de defectos y los plazos incumplidos podrían significar que ha alcanzado su capacidad si tiene suficientes observaciones para descartar una causa normal. De lo contrario, es posible que tenga un falso positivo. Ambos son impulsados probabilísticamente por muchos controladores estocásticos. El aumento de los defectos por sí solo no dice mucho. Si se esperaba una tasa de defectos del 10 %, han tenido un rendimiento del 4 % y luego aumentan al 6 %, ¿sugiere esto un exceso de capacidad?
Y su comentario sobre la confianza y el proceso es exactamente mi punto. Si un equipo puede mejorar su capacidad mejorando sus procedimientos, entonces, para empezar, no estaba en su capacidad.
Los equipos pueden adaptarse a los desafíos a través de la innovación. Si no fuerza un desafío, los equipos no innovarán ni se adaptarán. De hecho, degradan... ¡el Parkinson!
MaestroPJ
jeff lindsey