¿Scrum convierte a los desarrolladores activos en desarrolladores pasivos?

103

Soy un desarrollador web que trabaja en un equipo de tres desarrolladores y un diseñador. Hace aproximadamente cinco meses que implementamos la metodología de desarrollo ágil de software scrum. Pero tengo la extraña sensación de que solo quería compartir en este sitio.

Un factor importante en la vida humana es el proceso de toma de decisiones. Sin embargo, hay una gran diferencia en las decisiones que toma. Algunas decisiones son solo el resultado de una fuerza interna o externa, mientras que otras decisiones se basan completamente en su libre albedrío, y algunas decisiones son simplemente algo intermedio. Cuanta más libertad tenga para tomar decisiones, más autónomo será su trabajo. Esto parece ser una regla. Porque tendemos a moldear nuestras vidas nosotros mismos.

Hay una gran diferencia entre decidir qué hacer o que le digan qué hacer .

Antes de scrum, sentía que tenía más libertad para tomar decisiones relacionadas con el desarrollo, el análisis, la priorización de la implementación, etc. Tenía más ganas de decidir lo que estaba haciendo .

Sin embargo, debido a la metodología scrum, ahora muchas decisiones simplemente provienen del propietario del producto. Prioriza los PBI , analiza cómo debe funcionar el software, incluso a veces cómo se debe implementar la interfaz de usuario y la funcionalidad. Sé que esto es parte de la metodología scrum, y también sé que esto puede resultar en mejores ventas de productos en el futuro. Sin embargo, ahora siento que siempre me dicen que haga algo, en lugar de decidir hacer algo . Este síndrome ahora me ha hecho más pasivo hacia el trabajo.

  1. Tiendo a buscar menos para encontrar una mejor solución, enfoque o técnica
  2. No me levanto por la mañana esperando llegar a un trabajo agradable. Más bien, me siento obligado a trabajar para vivir
  3. Tengo más hambre de trabajar en mis propios proyectos de pasatiempo después del trabajo
  4. No presionaré más al equipo para llegar a los niveles tecnológicos más altos
  5. Ahora paso más tiempo cenando o a la hora del té y tengo menos entusiasmo para volver al trabajo.
  6. Ahora estoy más dispuesto a que el trabajo termine antes, para poder llegar a casa.

El gran problema es que también veo y diagnostico este comportamiento en mis colegas. ¿Es el resultado del scrum? ¿Scrum realmente hace que el equipo de desarrollo sienta que no tiene parte en la formación del software en general, lo que hace que el proyecto sea pasivo? ¿Cómo puedo superar este sentimiento?

Saeed Neamati
fuente
44
¿Estás seguro de que no te estabas cometiendo disfuncionalmente mucho antes?
Donal Fellows
27
Buena publicación de blog.
Robert S.
20
lo que estás describiendo no es SCRUM
44
@Chad. Lo que discutí aquí no es una queja de mi situación laboral. Me pregunto si este estado de ánimo es el resultado del scrum. ¿Y si otros desarrolladores también están experimentando lo mismo o no?
Saeed Neamati
55
@Saeed - Lamento ser franco, pero su estado de ánimo es el resultado de su decisión sobre cómo lidiar con su entorno de trabajo. También puede verse afectado por otras opiniones y actitudes, pero también puede optar por adoptar este método. Le exime de la necesidad de ser responsable de las decisiones de diseño y le permite trabajar para resolver problemas específicos. No agota toda su energía y le permite trabajar en más proyectos de su hogar. Tienes más tiempo para desarrollarte. Estas no son cosas malas. No es el trabajo de tu empleador hacerte feliz. Puedes encontrar otro trabajo o puedes aceptarlo.
SoylentGray

Respuestas:

51

Sin embargo, ahora siento que siempre me dicen que haga algo, en lugar de decidir hacer algo.

Este es un indicador serio de que algo se ha salido de los rieles. Un proyecto ágil no debería sentirse así. Esa retórica de "personas en proceso" debe incluir "no obligamos a nuestra gente a hacer cosas que apestan". Aquí hay algunas ideas:

¿Estás haciendo "scrum but"? Es decir, parte scrum, parte otra cosa. (es decir: "Estamos haciendo scrum, pero todas nuestras historias tienen que venir de nuestra PMO, no de un propietario de producto"). En estos días, mucha basura se llama Scrum.

¿No estás personalmente involucrado en el proceso donde deberías estar? He conocido a varias personas que están molestas por el contenido de las historias, y resulta que solo se involucran una vez que la historia está en el backlog de Sprint. Hable con el propietario del producto desde el principio en el desarrollo de la historia y obtenga sus comentarios. (Como PO, tienen la última palabra, pero eso no significa que tengan que hacerlo solos).

En Scrum, se supone que el equipo es el propietario del proceso, y se espera que el proceso cambie con el tiempo para adaptarse a las necesidades del equipo. Explique sus inquietudes en la retrospectiva. Si puede proponer un ajuste de proceso para sugerir, eso tiende a facilitar la venta para algunos equipos.

Sean McMillan
fuente
10
+1 Scrum (como todas las metodologías ágiles) será más pesado en la conversación que en la dirección. El PO debe describir lo que el resultado final debe ser capaz de lograr, luego involucrar a los diseñadores y desarrolladores en formas de llegar allí.
StevenV
55
"personas sobre el proceso": Gracioso, entonces ¿por qué imponer el proceso SCRUM en lugar de dejar que las personas usen el suyo? ¿Y por qué todas esas medidas (programación de pares, revisiones de progreso frecuentes) que, en nombre de la transparencia, permiten monitorear el trabajo de los desarrolladores mucho más de cerca?
Giorgio
3
@Giorgio: Porque el desarrollo estructurado permite que los equipos trabajen juntos sin pisar los pies del otro todo el tiempo. Simplemente no hemos descubierto cómo hacerlo perfectamente todavía.
Phoshi
2
@Giogio, este es un problema con ágil en general. Aunque un objetivo es hacer que las personas superen el proceso, en realidad Agile se sigue religiosamente, lo que nuevamente pone el proceso sobre las personas. Personalmente, creo que lean hace un mejor trabajo que ágil, aunque no intenta imponer una estructura estrictamente horizontal del equipo: permite a los desarrolladores elegir mejor las tareas. Asumiendo que su equipo no cambiará, una junta kanban además de lo que está haciendo ahora podría hacer feliz a la administración y a usted también, dándole libertad para elegir sus historias / tareas.
jQwierdy
62

Su problema no es Scrum (y como Jarrod Roberson mencionó en los comentarios, no es Scrum lo que está describiendo), es la microgestión del propietario del producto y su falta de asertividad (y la del equipo) .

"Sin embargo, debido a la metodología scrum, ahora muchas decisiones simplemente provienen del propietario del producto. Da prioridad a los PBI, analiza cómo debe funcionar el software, incluso a veces cómo se debe implementar la IU y la funcionalidad. Sé que esto es parte de la metodología scrum".

Estás equivocado. Solo por un breve vistazo a la página de Wikipedia para Scrum, se puede ver que: "el Equipo, un grupo interfuncional que realiza el análisis, diseño, implementación, prueba, etc." ¿Ver? El propietario del producto le dice qué hacer, pero depende del equipo decidir cómo hacerlo.

Usted es la persona responsable de la implementación, por lo que debe decidir cómo se implementará la aplicación. Escuche la opinión del propietario del producto, pero la decisión final depende de usted (o del equipo).

Por cierto microgestión hace girar desarrolladores activos en los desarrolladores pasivos.

Lukas Stejskal
fuente
38
Amén a esa última línea
Wivani
66
"El propietario del producto le dice qué hacer, pero depende del equipo decidir cómo hacerlo". Eso es exactamente lo que puede ser un problema para la motivación de los desarrolladores: falta de innovación. La mayoría de las veces el cliente querrá caballos más rápidos, no autos. Pero estoy totalmente de acuerdo con la microgestión.
MaR
1
+1 @Lukas, debido a la diferenciación entre qué y cómo . Gracias amigo.
Saeed Neamati
55
"El propietario del producto le dice qué hacer" - No estoy de acuerdo con eso. Deberían decirte lo que necesitan . Una ligera pero importante diferencia. En otras palabras: describen el problema / problema, usted proporciona la solución.
DanMan
2
@MaR Es por eso que los desarrolladores no hablan con los clientes. Los clientes hablan con el Propietario del producto y solicitan caballos más rápidos, el PO es el que ve todos los problemas de los clientes, los combina y los prioriza, y en el proceso
descubre
29

Lo que estás describiendo NO ES SCRUM

El propietario de su producto está superando sus límites si le está diciendo cómo hacer su trabajo técnicamente, de eso no se trata SCRUM.

SCRUM se trata de liberar a los desarrolladores para que se concentren en los problemas de desarrollo y capacitarlos para que se encarguen de determinar cuánto tardan las cosas y cómo hacerlas.

SCRUM se trata de colaboración, para eso están las reuniones de planificación de Sprint, para promover la colaboración entre todos los interesados; propietario del producto, desarrolladores y pruebas.

Sí, el propietario del producto debe priorizar las características, lo que debe entregarse primero de acuerdo con las necesidades de los clientes, pero los desarrolladores deben hacer la ingeniería y el diseño, no el propietario del producto.

No estoy de acuerdo con que los desarrolladores deban diseñar interfaces gráficas de usuario y flujos de trabajo a menos que tengan la tarea y la capacitación específicas para trabajar con los clientes y analizar la funcionalidad directamente con los clientes. Las GUI creadas por el programador hechas al vacío rara vez satisfacen las necesidades de los clientes.

SCRUM se trata de poner un proceso ligero que pueda ser predecible y repetible sobre el manifiesto ágil.

Me entristece escuchar historias de que cosas muy buenas se están pervirtiendo así.

user7519
fuente
3
La naturaleza humana siempre encontrará una manera de arrebatar la derrota de las fauces de la victoria.
Warren P
2
Existe lo que se supone que es SCRUM , y existe lo que termina siendo , al menos en la mayoría de las empresas. SCRUM no es malo en sí mismo, pero es una herramienta que la administración usa muy fácilmente para el mal.
AresAvatar
11

Supongo que antes de Scrum, todos hicieron lo que querían: yippee ki-yay mf'er . Sus usuarios son sus benefactores y dirigen la historia y pagan las facturas. El propietario del producto se asegura de que la historia se haga. De alguna manera, su grupo llegó a la conclusión de que el propietario del producto debería estar diciéndole cómo programar.

¿Quieres escribir código o hacer pequeñas aplicaciones ordenadas que creas que son geniales? "Quiero hacer la función A primero y no B, para poder mantener mi libertad de elección". Encuentre un benefactor diferente y no una nueva metodología de desarrollo.

Estás atrapado en el título del propietario del proyecto o algo así. Si tiene una razón válida para no estar de acuerdo con la historia, diga algo, haga su argumento. Puede que no siempre ganes. Es su trabajo regresar a los usuarios y hacerles saber que hay un problema válido con su solicitud. Seamos realistas, si la historia le pide que suelte una base de datos al azar durante todo el día, sin una copia de seguridad, sin pérdida de datos o tiempo de inactividad, tiene un problema y un deber de aclarar la historia.

JeffO
fuente
10

Parece que tus aventuras en Agile han sido corrompidas por Scrum. Me parece que, de todas las metodologías ágiles, Scrum es el menos ágil. Es más como cascadas en miniatura y gestión de proyectos adicionales. Esto, por supuesto, hace que a la gerencia le guste más el hecho de que sienten que están tomando el control de esos desarrolladores molestos, pero por supuesto, ustedes ven la realidad de la situación.

Agile no se trata de seguir un camino prescrito, está diseñado para hacerlo más productivo y motivado. La gente no procesa dice el manifiesto (parafraseado), y eso se pierde en el sistema que está utilizando.

Entonces cámbialo. Explíquelo con la gerencia y diga que es un paso retrógrado, que su productividad es menor de lo que solía ser y que todos están descontentos con la forma en que está funcionando. Muestre el Manifiesto Ágil (y su gemelo malvado ) y demuestre que no solo aprendió las lecciones de este experimento, sino que quiere evolucionar las partes buenas de él en un sistema mejor (uno que es como solía tener, que parece funcionar bien) para ti).

gbjbaanb
fuente
66
¿yo? sí, solíamos trabajar bien, luego la gerencia decidió que Agile era el futuro e impuso scrum, lo que nos restringió enormemente. Lo que solíamos hacer sin esfuerzo se empantanó en el proceso y la burocracia. ¡Una vez tomé 3 cartas del tablero scrum! Las luces parpadearon y las sirenas aullaron por esta violación de "la forma de scrum", y una vez llevé la tarjeta a mi escritorio . Los policías de gestión de proyectos vinieron por mí. Y solía sentarme en los scrums diarios, eso tampoco funcionó bien. Todas las trivialidades en mi humilde opinión, pero se convirtieron en montañas.
gbjbaanb
2
¿No crees que en tu caso es una mala implementación de Scrum de arriba hacia abajo que causó una pérdida de productividad? Dices que te atascaste en el proceso y la burocracia, lo cual es extraño porque Scrum es la metodología burocrática más simple del mundo ... En realidad, todo el marco de Scrum cabe en una hoja o 2. Por cierto lo que llamas el "tablero de scrum" No es parte del marco. En el caso de Saeed, aunque creo que el problema es una brecha entre el tipo de organización en la que trabajó (con gran libertad y poder de decisión para los desarrolladores) y el tipo de organización a la que se aplica Scrum.
guillaume31
3
@ ian31: sí, ese proyecto fue particularmente malo, pero Scrum atrae a ese tipo de gerentes. Nunca los ves elegir Kanban o Crystal después de todo. Scrum demasiado fácilmente se convierte en "scrum pero" cuando estos chicos se apoderan de él. lástima.
gbjbaanb
1
Creo que es gracioso que cualquier compañía convierta a Scrum en una ceremonia religiosa. ¡Oye! ¡Párate durante esta ceremonia donde pretendemos ser ágiles! ¡Oye! ¡Sonríe mientras pretendemos escucharte, y luego, felizmente, sigue haciendo lo que queríamos de todos modos!
Warren P
2
Estoy totalmente en desacuerdo con el impulso de esta respuesta. Creo que algún tipo de "mini-cascada" puede ser muy beneficioso, especialmente para desarrolladores inexpertos pero inteligentes, que pueden hacer 5 cosas diferentes a la vez y no terminar ninguna de ellas. De hecho, la persona que me entrenó en Scrum dijo que aún puedes hacer "mini-cascadas" en Scrum si lo deseas, pero idealmente, deberían durar días o incluso horas . Pensé, las horas son muy cortas. No siempre se puede diseñar-> implementar-> probar una historia en unas pocas horas. Y dividir historias para que puedas no siempre es óptimo tampoco.
Robin Green
8

Creo que simplemente ustedes están acostumbrados a tener más propiedad, y creo que todos prefieren eso, su naturaleza humana.

Desafortunadamente, creo que mucho software es menos de lo que podría ser, porque a menudo las partes están escritas para el desarrollador y no para el cliente. Su nuevo enfoque debería reducir eso, pero a expensas de su sentimiento de propiedad.

No tengo idea de cómo sugerir que hagas las cosas mejores o más divertidas, pero es una gran pregunta y una muy buena idea.

Jonno
fuente
100% de acuerdo. Ahora está más alineado con el propietario del producto, pero eso significa que tiene menos libertad para hacer lo que cree que es correcto. También he experimentado esto y apestaba y hacía que mi trabajo fuera mucho menos agradable. Pero significaba que estaba mucho mejor alineado con el negocio y los objetivos del gerente de producto. El negocio paga las facturas, incluido mi salario, así que sí, pueden decir lo que quieren a un nivel de detalle. No creo que realmente te estén diciendo cómo codificar. Si supieran cómo podrían hacerlo ellos mismos.
Michael Durrant
El negocio no paga a los desarrolladores para que hagan lo que quieran. Pagan a los desarrolladores por la ganancia de productividad que proporciona un buen entorno de software. Si deja que la empresa le diga qué hacer "en un nivel de detalle", ¿realmente cree que obtendrán el buen entorno de software que están buscando?
Andomar
@Andomar: es un equilibrio. Cada lado tiene sus ideales, suposiciones y fallas. Ignorar cualquiera de estos conduce al peligro.
Jonno
5

¿Está recibiendo historias de usuarios en la forma de "Como un rol que quiero, meta / deseo, para que sea un beneficio"? Parece que el propietario del producto quiere hacer el trabajo de diseño, y es posible que no sea la mejor persona para hacerlo. El uso del patrón de la historia del usuario puede ayudar a garantizar que el propietario del producto se apegue al interés comercial y que los desarrolladores de software realicen el desarrollo del software.

Michael Munsey
fuente
44
Como desarrollador, no quiero volver a ver este tipo de historia de usuario, de modo que nunca tenga que gemir internamente por su locura.
Warren P
@WarrenP Sí, repetitivo puede ser una molestia, ya sea en forma de código repetitivo o requisitos de repetitivo. Creo que el punto clave es que todos esos 3 elementos deben ser establecidos o entendidos, pero lo más importante, debe ser claro para todos lo que realmente se quiere, y los requisitos de plantilla pueden obstaculizar eso. Especialmente si los desarrolladores comienzan a pensar que completar unas pocas palabras en esa plantilla siempre es suficiente.
Robin Green
4

En Scrum hay mucho espacio para que los desarrolladores contribuyan y den sus consejos sobre nuevas características, interfaz de usuario, usabilidad ... En Scrum se requiere colaboración y conversación entre empresarios y desarrolladores, y eso lo permite. Sin embargo, al final, el propietario del producto siempre tendrá la última palabra porque es el responsable de maximizar el valor comercial de los incrementos de software producidos sprint tras sprint (en otras palabras, el ROI).

Del Manifiesto Ágil:

Nuestra máxima prioridad es satisfacer al cliente a través de la entrega temprana y continua de software valioso.

Sin embargo, el propietario del producto que le dice cómo debe implementarse la interfaz de usuario y la funcionalidad no es aceptable. En ese caso , debe tener la última palabra, ya que es responsable de la calidad interna del software que produce.

Tal vez trabajas en una empresa creada por desarrolladores donde los programadores tenían libertad para implementar las funciones que quisieran. Sin embargo, la mayoría de las metodologías ágiles hacen una clara separación entre las personas del dominio empresarial y el equipo responsable de producir software (desarrolladores, probadores ...), que es la división de trabajo más común en la mayoría de los lugares. Si mis suposiciones son correctas, puedo entender la sensación que tienes de que ya no puedes "influir en el panorama general", pero con el crecimiento de la empresa, supongo que ese habría sido el caso de todos modos, Scrum o no.

Con respecto al análisis, el diseño y otras actividades de metadesarrollo que menciona (que de nuevo no debe realizar el propietario del producto), se supone que los equipos ágiles son multifuncionales y libres de silos. Se supone que nadie posee todo el conocimiento en torno a una actividad de desarrollo específica, por lo que tal vez haya una oportunidad para que se diversifique allí en lugar de simplemente "codificar código".

guillaume31
fuente
3

Por el contrario, descubrí que tener un propietario de producto que tome decisiones sobre la funcionalidad me permite dedicar más tiempo a producir código de calidad. Además, si existen inquietudes válidas, siempre puedo cuestionar las decisiones de los propietarios de los productos, y eso generalmente lleva a discusiones fructíferas.

Misko
fuente
3

Practicamos Scrum aquí. Tenemos una reunión de planificación quincenal donde introducimos las prioridades comerciales actuales y los éxitos y fracasos del sprint anterior, y decidimos, como equipo , qué queremos abordar para el próximo sprint.

Una de las formas en que hacemos esto es ordenar el trabajo acumulado en un tablero por complejidad vertical y prioridad comercial horizontalmente. Después de eso, el propietario del producto ha tenido su opinión, por lo que depende del equipo elegir lo que queremos hacer. Obviamente, elegir una tarea de alta complejidad y baja prioridad está mal visto, pero estamos decidiendo esto como un equipo. Hace que las sesiones de planificación sean más largas, pero vale la pena, y es una parte central del proceso Agile.

Y a veces tenemos microgestión, pero ese es un problema diferente.

Tim
fuente
3

El verdadero problema que está describiendo es una patología común cuando los equipos adoptan una Metodología: se apagan el cerebro. Esto es tan cierto con un sistema ágil de la nueva escuela como lo fue con los sistemas pesados ​​de la vieja escuela.

P: La metodología prescribe x, pero x no funciona bien. ¿Qué debemos hacer?

A: refine su implementación de x. Quizás deje de hacerlo por completo. ¡La Metodología no es tu jefe!

En este caso específico, parece que el propietario del producto podría estar haciendo demasiado. ¿Te sientes cómodo hablando con él sobre eso? ¿Te sentirías cómodo teniendo esa conversación si no estuvieras "haciendo scrum"? Si el propietario del producto no es sensible a los comentarios constructivos, no es un problema de metodología, es un problema con el propietario del producto.

Ian Olsen
fuente
2

Realmente no estoy en sintonía con todo el tema scrum, ya que han sido más cascadas por un tiempo.

Pero para ser sincero, esto suena más como un problema de personal de gestión que como un problema de técnica de gestión de proyectos. Como en esto, se basa más en las personas que en las técnicas.

temptar
fuente
No @temptar, nuestra relación es realmente buena. Sin ofender, sin odio, nada en absoluto. Todo está bien, todo excepto lo que sentimos por el trabajo.
Saeed Neamati
2

El papel de los líderes en un equipo de autoorganización sería una publicación de blog sobre algo que parece faltar en su publicación. ¿Dónde decide el equipo qué trabajo se realiza en un sprint? ¿Dónde tiene el equipo la propiedad del proceso y el trabajo? ¿Tienes a alguien que conoce Scrum lo suficiente como para que estés haciendo Scrum y no una versión pervertida de él?

JB King
fuente
2

Tuve la misma experiencia con Scrum y me gusta llamarlo la "tiranía de la historia".

Desde mi experiencia, los desarrolladores más creativos / de diseño / frontend parecen sufrir más que las personas involucradas en el trabajo de backend.

La única salida que encontré hasta ahora fue deshacerse de Scrum, a menudo no es posible y / o apropiado porque, después de todo, tiene sus ventajas, o introducir algo como el 20% del tiempo de Google para dar a los desarrolladores una salida creativa aparte del "tú" es libre de elegir cómo implementar la página de inicio de sesión ", porque en realidad no lo es, ya que su implementación está limitada por el código y la arquitectura del sistema existentes, es decir, a menos que se considere la libertad de elegir entre un bucle for a y while libertad.

Alexander Battisti
fuente
1

Hay una gran diferencia entre decidir qué hacer o que le digan qué hacer .

En mi experiencia, hay un largo camino desde que se les diga qué hacer hasta decidir qué hacer.

Al final de esta manera por lo general resulta que se nos instruyó no porque les gusta el poder y no porque ellos no tienen nada mejor que hacer. Muy por el contrario, al final de esta manera - cuando ellos ganan suficiente confianza en nuestro equipo - que parecen ser relevado y felizmente nos pasar tanto control como podemos manejar (y si su confianza es muy firme, incluso tratar de pasar más que eso)

Ah, y en mi experiencia, esto básicamente no tiene nada que ver con Scrum / agile. Pasó con scrum, iterativo, cascada, lo que sea. Parece que la cuestión de la confianza es un proceso agnóstico

mosquito
fuente
1

En nuestro equipo, el propietario del producto nos dice qué hacer y nosotros decidimos cómo hacerlo. Es realmente importante tener esta separación o terminarás en la situación que has descrito.

thegreendroid
fuente
1

Según mi experiencia, Scrum es observar profundamente lo que haces. Es solo sentarse sobre tu hombro y mirar lo que haces. Aunque tiene su propia ventaja, odio la metodología scrum. Espera el recuento, no la calidad. La calidad se ve comprometida con la metodología scrum.

Anto
fuente
"La calidad se ve comprometida con la metodología scrum". Tal vez sea un poco extremo decir que la calidad se ve comprometida, pero sí, la capacidad de control del proyecto tiene una prioridad más alta que la calidad.
Giorgio
Es sorprendente lo poco que algunas personas saben sobre scrum o ágil, y sin embargo cómo publican como autoridades. Uno tiene la impresión de que un individuo trabajó durante unas semanas en un grupo disfuncional donde dijo que estaba "haciendo scrum" y concluyó que así es como se supone que debe ser el scrum. En este caso, es un tipo completamente anónimo con solo una publicación o comentario en 4 años, y sin evidencia de experiencia en el tema. Es por eso que no podemos tomarnos muchos de estos comentarios muy en serio.
Curtis Reed