¿Alguien más siente que Scrum no es ágil?

41

Soy un gran fanático del desarrollo ágil y utilicé XP en un proyecto muy exitoso hace unos años. Me encantó todo, el enfoque de desarrollo iterativo, escribir código en torno a una prueba, programar pares, tener un cliente en el sitio para ejecutar las cosas. Era un ambiente de trabajo altamente productivo y nunca sentí que estaba bajo presión.

Sin embargo, los últimos lugares en los que he trabajado usan / usan Scrum. Sé que es el niño del cartel para el desarrollo ágil en estos días, pero no estoy 100% convencido de que sea ágil. A continuación se presentan las dos razones principales por las que no me parece ágil.

Los gerentes de proyecto lo aman

Los gerentes de proyecto, que por su propia naturaleza están obsesionados con los plazos, todos parecen amar a Scrum. En mi experiencia, parecen usar el Sprint Backlog como un medio para rastrear los requisitos de tiempo y mantener un registro de cuánto tiempo se dedicó a una tarea determinada. En lugar de usar una pizarra, todos usan una hoja de Excel, que cada desarrollador debe completar, religiosamente.

En mi opinión, esto es demasiada documentación / seguimiento de tiempo para un proceso ágil. ¿Por qué habría de perder el tiempo calculando cuánto tiempo me llevará una tarea si puedo continuar con la tarea misma? O de manera similar, ¿por qué perdería tiempo documentando cuánto tiempo llevó una tarea cuando puedo pasar a la siguiente tarea en cuestión?

Reuniones de pie

Las reuniones de pie en el lugar anterior donde trabajé fueron una pesadilla. Todos los días teníamos que explicar lo que habíamos hecho ayer y lo que íbamos a hacer ese día. Si pasáramos a nuestro "cálculo" de tiempo para una tarea, el gerente del proyecto desataría un hedor y haría referencia al Backlog de Sprint como un medio de demostrar que eres incompetente por no cumplir con la línea de tiempo.

Ahora entiendo la necesidad de comunicación, pero seguramente el tono de las reuniones diarias debe ser alegre y centrarse en el intercambio de conocimientos. No creo que deba convertirse en una farsa de estilo de tarea. Seguramente, el punto clave de Agile es que las líneas de tiempo cambian, no deben establecerse en piedra.

Conclusión

La idea de agile es mejorar el software al facilitar la vida de los desarrolladores. Por lo tanto, en mi opinión, cualquier proceso ágil utilizado por un equipo debe ser liderado por un desarrollador. No creo que tener un gerente de proyecto use un proceso que hayan etiquetado como "ágil" para rastrear un proyecto tiene algo que ver con el desarrollo ágil.

¿Alguien piensa?

winarama
fuente
66
En scrum, los equipos deben ser autogestionados. El objetivo del gerente de proyecto es eliminar eventualmente su rol para que el equipo se organice y asista a las reuniones diarias por sí mismo. Idealmente, el rol de gerente de proyecto debe eliminarse para asistir a reuniones retrospectivas y de planificación y manejar todo el trabajo organizacional.
SuperM
77
Sí. Incluso uno de los "padres" de Agile no está de acuerdo con que Scrum sea realmente ágil: youtube.com/watch?v=hG4LH6P8Syk
Euphoric
18
Entonces, ¿lo que estás diciendo es que no estás haciendo Scrum, y eres consciente de eso, pero entonces te sorprende que Notscrum también sea Notagile?
pdr
2
Nunca he pasado más tiempo en reuniones hablando sobre el proceso que todos los equipos "ágiles" en los que he estado. Pero todavía me gusta mucho más que la alternativa.
Rob
11
En mi experiencia, Scrum es esencialmente un intento de hacer que Waterfall se vea ágil al dividirla en unidades más pequeñas. De hecho, los sprints deberían llamarse de manera más realista "cascadas".
Berislav Lopac

Respuestas:

25

Hay ciertos elementos en Scrum que son más propensos a la perversión, pero para ser sincero, lo que está describiendo es el resultado de intentar que una organización adopte Scrum sin educar a todas las partes interesadas sobre de qué se trata, cómo funciona y por qué funciona Necesitas compra en toda la empresa para obtener resultados.

Cualquier transformación ágil expondrá todo lo malo que está sucediendo en su organización, incluidos, entre otros, micromanagers, personas hambrientas con sus propias agendas, desarrolladores insuficientemente capacitados, silos de comunicación, etc. Si no hay voluntad colectiva para abordar estos problemas y simplemente "haces standups" y simplemente "trabajas en sprints", la implementación de Scrum va a caer de bruces.

No puedo enfatizar esto lo suficiente: si quieres hacer Scrum, necesitas entrenadores competentes que puedan mostrarte el camino. No es suficiente leer Essential Scrum y luego ver a dónde te lleva ...

Stefan Billiet
fuente
16
¿En qué se diferencian las standups diarias de la microgestión?
Giorgio
10
Las standups son para que el equipo organice su tiempo para que no se interpongan entre sí. Es absolutamente inapropiado hablar de estimaciones, tiempo transcurrido en tareas pasadas, etc., de hecho, un gerente de proyecto (a diferencia del scrum master) posiblemente no debería asistir.
Julia Hayward
10
@Georgio: depende de lo que entiendas por microgestión. El objetivo de un standup diario en SCRUM es mantener a todos informados sobre lo que están haciendo los demás, no proporcionar una oportunidad para que un gerente de proyecto castigue a las personas por no cumplir con las estimaciones. De hecho, no hay un gerente de proyecto en SCRUM, el seguimiento y el ajuste de las estimaciones es el trabajo del equipo, y si no se cumplen, la pregunta es "¿qué lo causó y cómo podemos evitarlo o permitirlo en el futuro? ", no" ¿de quién es la culpa y qué tan mal podemos hacerlo sentir? "
Michael Borgwardt
3
@ErikReppen, tal como está con casi cualquier cosa, tienes un pequeño grupo de personas que logran una mejora digna y luego obtienes un grupo mucho más grande que quiere monetizarlo y generalmente lo pervierte por completo: -p Creo en Scrum, pero me alejo completamente de la Alianza Scrum y su negocio de certificación.
Stefan Billiet
8
@jessehouwing: Sí, pero imponer reuniones en un equipo maduro es como acercarse a alguien que puede caminar perfectamente y decirle: mira, tienes un problema, no puedes caminar, te enseñaré a caminar correctamente. Estas personas te mirarán y se preguntarán: ¿Qué quiere este chico de mí? Por supuesto que puedo caminar. Por lo tanto, imponer reuniones diarias en un equipo maduro y autoorganizado solo perturba su flujo de trabajo: es solo un desperdicio. Tal decisión puede explicarse por la gestión incompetente o por la voluntad de observar / controlar cómo funciona el equipo.
Giorgio
20

Sí. Incluso uno de los "padres" de Agile no está de acuerdo con que Scrum sea realmente ágil: youtube.com/watch?v=hG4LH6P8Syk - Euphoric

Creo que este enlace de uno de los comentarios anteriores realmente lo dice todo. Vale la pena verlo, el tío Bob da una breve historia sobre Scrum y básicamente dice que Scrum no es un proceso de desarrollo ágil porque Scrum ha evolucionado con el tiempo para convertirse en un proceso de gestión . Las razones detrás de esto parecen ser porque fueron los gerentes de proyecto, y no los desarrolladores, quienes tomaron los cursos de Scrum.

winarama
fuente
2
Esto (lo que has escrito, no lo que dijo el tío Bob) no es un secuestro. El hecho de que algo sea un proceso de gestión no lo hace inherentemente no ágil.
Dave Hillier
99
Puedes tener gatos marrones y perros marrones, pero un gato marrón nunca puede ser un perro marrón. No es porque no sea marrón, es porque no es un perro. Del mismo modo, un proceso de gestión ágil no puede ser un proceso de desarrollo de software ágil, no porque no sea ágil sino porque no es un proceso de desarrollo de software, de lo que estamos hablando.
winarama
1
Entonces es posible que desee actualizar su pregunta, titulada "¿Alguien más siente que Scrum no es ágil?"
Dave Hillier
Gracias por compartir el video. Lo encontré realmente esclarecedor.
MickJ
Bueno, a los gerentes les gusta agile, incluso lo usan mal. Para que puedan culpar a los desarrolladores. Entonces, usar ágil sea lo que sea falso o no, es un problema de corrección política.
Amor
13

Lo que está describiendo es lo que nosotros, los instructores profesionales de Scrum, vemos mucho en organizaciones que han "implementado scrum". A menudo, también hacen "XP en el equipo de desarrollo", lo que significa que hay algunas pruebas unitarias que se ejecutan en algún servidor de compilación. Esto no es scrum .

Sí, los gerentes de proyecto pueden usar una cartera de productos, especialmente una que ha sido digitalizada, para abusar de las métricas que estos sistemas recopilan. Pero el Equipo de Desarrollo y el Scrum Master no deberían dejarlo. ¿Qué hace un gerente de proyecto allí de todos modos? ¿No debería ser un propietario del producto ?

Del mismo modo que XP se puede hacer mal, y algunos procesos más rigurosos pueden parecer muy fluidos (con integración continua, implementación, pero todavía muy planificada), Scrum es solo un marco. Se necesitan buenas personas que entiendan los valores y el proceso para ejecutarlo bien. Se necesita aprendizaje continuo una mejora para llegar allí.

jessehouwing
fuente
12

Probablemente esperaba eso, pero solo porque algunas (¿muchas?) Personas usan mal Scrum de una manera poco ágil no significa que Scrum no sea ágil.

Gerente de proyecto : no existe ese papel en un equipo Scrum. El Scrum Master no es responsable del presupuesto ni de los plazos de cumplimiento. Es responsable de ayudar al equipo y eliminar cualquier impedimento que se interponga en su camino hacia el objetivo al que se comprometieron. Por lo que describe, parece que su PM secuestró a Scrum para tomar prerrogativas que normalmente van al equipo y al Propietario del producto, perpetuando los hábitos de comando y control anteriores.

Seguimiento del tiempo : Scrum recomienda realizar un seguimiento del tiempo restante y resumirlo para determinar el estado del sprint, no señalar el tiempo dedicado por los miembros individuales del equipo. Esto puede parecer un detalle, pero marca la diferencia entre una cultura orientada a la culpa y un enfoque orientado a objetivos.

De la Guía Scrum :

Monitoreo del progreso de Sprint

En cualquier momento en un Sprint, se puede sumar el trabajo total restante en el Backlog de Sprint. El equipo de desarrollo realiza un seguimiento de este trabajo total restante al menos para cada Scrum diario para proyectar la probabilidad de lograr el objetivo de Sprint . Al rastrear el trabajo restante a lo largo del Sprint, el Equipo de Desarrollo puede administrar su progreso.

guillaume31
fuente
Es inevitable convertirse en una cultura orientada a la culpa, incluso Scrum es 100% político correcto en teoría.
Amor
2

scrum es una metodología de gestión de proyectos

ágil es una metodología de desarrollo de software (-ish)

scrum + agile funciona muy bien

scrum sin agile ... no tanto

Steven A. Lowe
fuente
3
Es interesante que Scrum solía ser una metodología de desarrollo de software, pero con el tiempo se ha convertido en una metodología de gestión de proyectos.
winarama
2
Creo que eso es inevitable. Los desarrolladores simplemente no tienen tanto sentido de propiedad en el proceso (no lo quieren). Recientemente, en una revisión de sprint, cuestioné el propósito del equipo: escribir software o hacer que el gráfico de carga se vea bien. Hice mi punto, pero luego todos los PM en la sala tuvieron que hacer todo lo posible para enfatizar la importancia de bla, bla, bla. jajaja
Rob
2
@ Panel T: Aún más interesante que Scrum se propuso originalmente como una metodología de desarrollo de nuevos productos - hbr.org/1986/01/the-new-new-product-development-game/ar/1
Steven A. Lowe
2
@ StevenA. Lowe Ah Scrum, está en un viaje de autodescubrimiento.
winarama
1
Sé que es viejo pero esta respuesta es completamente falsa. Scrum es un marco en el que se ajustan los patrones. Ágil es un conjunto de valores y principios.
Venture2099