¿Limitar el compromiso en Scrum conduce a la complacencia?

En mi organización, los equipos Scrum casi nunca terminan todas sus historias al 100%. Sugerí que nos comprometiéramos a contar menos historias cada Sprint, pero el gerente de I + D dice que si lo hacemos, la gente aún no completará el trabajo, sino que hará menos, lo que ralentizará el desarrollo. Él dice que hay un Síndrome de Estudiante en el trabajo aquí.

¿Cuál es tu opinión sobre eso?

Su gerente necesita comprender que el Síndrome del Estudiante / Ley de Parkinson se convierte en un problema significativamente mayor cuando no hay ninguna esperanza de alcanzar objetivos. De repente, el tiempo disponible para completar una tarea es infinito. Como solía decir un viejo colega mío: "Los plazos son solo cosas que pasan por aquí. Los extrañamos, se mudan, los extrañamos de nuevo".

Y eso fue completamente el resultado de plazos irrazonables en primer lugar. Estas personas no eran perezosas por naturaleza, simplemente no veían la esperanza de golpear un objetivo y ninguna consecuencia de no golpearlo, entonces, ¿por qué preocuparse por eso?

Mi punto es que su gerente bien podría estar en lo cierto. Pero necesita entender que está creando el problema.

Cuando un equipo hace una buena planificación de sprint, comienzan a trabajar en equipo para cumplir con sus plazos. Cualquier persona no tira de su peso, fallan como equipo. Si eso sucede continuamente, el equipo trata con esa persona.

Existe la posibilidad de que reduzca demasiado la velocidad y logre menos de lo que podría haber logrado. Pero habrás tenido éxito. Los sentimientos en el equipo serán positivos. Es probable que alguien diga "Honestamente, creo que podemos lograr un par de puntos más el próximo sprint".

Eventualmente, encontrará su punto de equilibrio y comenzará a predecir correctamente la cantidad de trabajo que realmente puede lograr en una iteración.

¿A quien le importa? ¿No debería el propietario del producto preguntar dónde está el resto de mis características?

Es posible que deba limitar la duración de sus sprints. De esta manera, se debe mostrar más progreso junto con el camino. Use los comentarios sobre lo que se está haciendo para determinar cuánto se puede lograr en los sprints posteriores.

No puede tener un marco de tiempo fijo para un proyecto y una lista fija de tiendas / características sin asignar suficientes recursos. Si hay una fecha de vencimiento fija, es posible que no termine todas las historias. ¿Quieres cortar algunas historias? ¿Cuáles? ¿Realmente puedes determinar eso al principio? Con suerte, si prioriza correctamente, el propietario del producto obtiene lo más importante. Es su prioridad después de todo.

El gerente está jugando juegos mentales. Si eres un niño que quiere un perro, pide un pony.

En mi organización, los equipos Scrum casi nunca terminan todas sus historias al 100%. Sugerí que nos comprometiéramos con menos historias cada Sprint, pero el gerente de I + D dice que si lo hacemos, la gente aún no completará el trabajo, sino que hará menos, lo que ralentizará el desarrollo. Él dice que hay un Síndrome de Estudiante en el trabajo aquí.

Desde mi experiencia limitada con [lo que posa para] Agile, no me sorprende. Todo lo que he leído sobre Agile sugiere que todos necesita una organización mucho más organizada que en otras técnicas de desarrollo, pero, como usted, veo poca o ninguna evidencia de ello.

La estimación de Story Points no es una ciencia exacta, especialmente en áreas "de vanguardia" como I + D. Fácilmente podría ser que tus Desarrolladores estén calculando mal sus Story Points (IME, generalmente más de -estimating sus propias habilidades) o podría ser que hay algún número "objetivo" de puntos que se supone que deben producir en cada Sprint (en mi humilde opinión , una manera completamente imperfecta de administrar, lo que me lleva a ...).

Su gerente debe investigar esto y descubrir qué no funciona. Es su responsabilidad hacer que las cosas se entreguen a los clientes (o debería serlo), por lo que su "cuello en el bloque" cuando los usuarios comienzan a quejarse.
[cinismo] Por supuesto que no lo será, porque tienen todo el entrenamiento / habilidades necesarias para asegurarse de que ninguna de las culpas se les pegue. [/cinismo]

Y insultar a sus trabajadores, calificándolos con cualquier tipo de "síndrome", nunca es un comportamiento aceptable, solo muestra la falta de compromiso de la gerencia con el Equipo y su deseo de "distanciarse" de él.

El desarrollo se está ralentizando de cualquier manera, pero hacer el trabajo de manera lenta y más concienzuda (es decir, hacer que las cosas funcionen) es mucho, mucho mejor que simplemente no entregar nada en absoluto.