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

38

Soy un gran fanático del desarrollo ágil y utilicé XP en un proyecto muy exitoso hace unos años. Me encantó todo al respecto, el enfoque de desarrollo iterativo, escribir código en torno a una prueba, programar en pareja, tener un cliente en el sitio donde dirigir 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 utilizan / utilizan Scrum. Sé que es el niño del póster para el desarrollo ágil en estos días, pero no estoy 100% convencido de que sea ágil. A continuación se muestran las dos razones principales por las que simplemente no se siente ágil para mí.

A los gerentes de proyecto les encanta

Los gerentes de proyecto, quienes por su propia naturaleza están obsesionados con las líneas de tiempo, todos parecen amar a Scrum. En mi experiencia, parecen utilizar el Backlog de Sprint 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 rellenar religiosamente.

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

Reuniones de apoyo

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 repasamos nuestra "estimación" de tiempo para una tarea, el administrador del proyecto generará un mal olor y hará referencia al Sprint Backlog como una forma de demostrar que usted es incompetente por no adherirse a la línea de tiempo.

Ahora comprendo 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 un lugar donde está tu estilo de tarea. Además, seguramente el punto clave de Agile es que las líneas de tiempo cambian, no deben estar escritas en piedra.

Conclusión

La idea de ágil 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 dirigido por un desarrollador. No creo que tener un administrador de proyectos que use un proceso que han etiquetado como "ágil" para rastrear un proyecto tiene algo que ver con el desarrollo ágil.

¿Pensamientos a alguien?

    
pregunta T-Pane 20.01.2014 - 15:44

5 respuestas

19
  

Sí. Incluso uno de los "padres" de ágil 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 de Scrum y básicamente dice que Scrum no es un proceso de desarrollo Agile 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.

    
respondido por el T-Pane 10.03.2014 - 15:53
24

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

Cualquier transformación ágil expondrá todo lo malo que está ocurriendo en su organización, incluidos, entre otros, los microgestores, las personas poderosas con sus propias agendas, los desarrolladores insuficientemente capacitados, los silos de comunicación, etc. Si no hay voluntad colectiva para hacerlo. aborda estos problemas y solo "haces standups" y solo "trabajas en los sprints", la implementación de Scrum se va a quedar en el suelo.

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 dónde te lleva ...

    
respondido por el Stefan Billiet 20.01.2014 - 16:35
13

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

Sí, los gerentes de proyecto pueden usar una acumulación de productos, especialmente una que ha sido digitalizada, para abusar de las métricas que estos sistemas reúnen. Pero el Equipo de Desarrollo y el Scrum Master no deberían dejarlo. ¿Qué está haciendo allí un Gerente de Proyecto de todos modos? ¿No debería ser un propietario del producto ?!

Al igual que XP se puede hacer mal, y algunos procesos más rigurosos pueden sentirse muy fluidos (con integración continua, implementación, pero aún muy impulsados por el plan), 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í.

    
respondido por el jessehouwing 20.01.2014 - 16:36
12

Probablemente esperó eso, pero solo porque algunas (¿muchas?) personas hacen un mal uso de Scrum de una manera no ágil no significa que Scrum no sea Agile.

Gestor de proyectos : no hay tal función en un equipo de Scrum. Scrum Master no es responsable por el presupuesto o los plazos de las reuniones. Es responsable de ayudar al equipo y eliminar cualquier impedimento que se interponga en su camino hacia la meta que se comprometieron. Por lo que describe, parece que su PM secuestró Scrum para tomar prerrogativas que normalmente van al equipo y al Propietario del producto, perpetuando los hábitos anteriores de comando y control.

Seguimiento del tiempo : Scrum recomienda realizar un seguimiento del tiempo restante y resumirlo para determinar el estado del sprint, no el momento en que pasó el equipo individual. miembros. Esto puede parecer un detalle, pero marca la diferencia entre una cultura orientada a la culpa y un enfoque orientado a objetivos.

De la Scrum Guide :

  

Monitoreando el progreso del sprint

     

En cualquier momento en un Sprint, el   El total del trabajo restante en el Sprint Backlog se puede sumar. los   El Equipo de desarrollo rastrea este trabajo restante restante al menos por cada   Daily Scrum para proyectar la probabilidad de lograr el objetivo Sprint . Por   rastreando el trabajo restante a lo largo del Sprint, el Desarrollo   El equipo puede gestionar su progreso.

    
respondido por el guillaume31 20.01.2014 - 16:59
2

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

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

scrum + ágil funciona muy bien

scrum sin ágil ... no tanto

    
respondido por el Steven A. Lowe 20.01.2014 - 18:10

Lea otras preguntas en las etiquetas

Comentarios Recientes

Solo recientemente pudimos pasar un par de horas depurándolo. Me imagino que esto está en la cadena de selección de equipo ". ¡Mi familia chilló! Vince Howes se rió cuando lo dije." ¡Me parece ágil! ", Responde. Yo también me reí. Mi alma de hueso recuerda que sentí Scrum Lean. Creo que es porque estaba enfatizando los aspectos narrativos que ahora dominan el proceso Scrum, como las pruebas unitarias, la refactorización y los mecanismos de dominio. Eso fue hace aproximadamente dos meses. Y estoy aprendiendo... Lee mas