¿Scrum convierte a los desarrolladores activos en desarrolladores pasivos?

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?

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.

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.

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í.

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.

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).

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.

¿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.

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".

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.

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.

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.

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.

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?

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.

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

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.

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.