¿Scrum convierte a los desarrolladores activos en desarrolladores pasivos?

  

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 sobre el proceso" debe incluir "no forzamos a nuestra gente a hacer cosas que apesten". Aquí hay algunas ideas:

¿Estás haciendo "scrum but"? Es decir, parte scrum, parte alguna otra cosa. (es decir: "Estamos haciendo scrum, pero todas nuestras historias tienen que venir de nuestra PMO, no del propietario de un producto"). Muchas cosas locas se llaman Scrum en estos días.

¿Usted, personalmente, no está involucrado en el proceso donde debería estar? He conocido a muchas personas que están molestas por el contenido de las historias, y resulta que solo se involucran una vez que la historia está en la acumulación de sprint. Hable con el propietario del producto desde el principio en el desarrollo de la historia y envíe 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 satisfacer las necesidades del equipo. Plantea tus inquietudes en la retrospectiva. Si puede proponer un proceso de modificación para sugerir, eso hace que sea más fácil vender para algunos equipos.

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

"Sin embargo, debido a la metodología scrum, ahora muchas decisiones simplemente vienen del propietario del producto. Prioriza los PBI, analiza cómo debería 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 ".

Estás equivocado. Solo con un breve vistazo a página de wikipedia para Scrum se puede ver que: "el Equipo, un grupo multifuncional que realiza el análisis, diseño, implementación, prueba, etc. real " ¿Ves? El propietario del producto le dice a usted qué hacer, pero le corresponde al equipo decidir cómo hacer eso.

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

BTW micromanagement hace convertir a los desarrolladores activos en desarrolladores pasivos.

Lo que estás describiendo NO ES SCRUM

El propietario de su producto está sobrepasando 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 empoderarlos se encarguen de determinar cuánto tardan las cosas y cómo hacerlas.

SCRUM tiene que ver con la 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 funciones, 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 GUI y flujos de trabajo a menos que tengan la tarea específica y estén capacitados para trabajar con los clientes y eliminar la funcionalidad directamente con los clientes. El Programador construyó las GUI en un vacío que rara vez satisfacen las necesidades de los clientes.

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

Me entristece escuchar historias de que cosas tan buenas se están pervertiendo de esta manera.

Supongo que antes de Scrum, todos hicieron lo que querían: yippee ki-yay mf'er . Sus usuarios son sus benefactores y ellos impulsan la historia y pagan las cuentas. El dueño 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 decirle cómo programar.

¿Quieres escribir código o hacer pequeñas aplicaciones que crees que son geniales? "Quiero hacer la característica 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 estar en desacuerdo con la historia, diga algo, haga su argumentación. No siempre puedes ganar. Es su trabajo volver a los usuarios y hacerles saber que hay un problema válido con su solicitud. Seamos realistas, si la historia le pide que elimine una base de datos aleatoriamente durante todo el día, sin una copia de seguridad, sin pérdida de datos o tiempo de inactividad, tiene un problema y la obligación 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, lo convierte en el que más gusta a los administradores, ya que sienten que están recuperando el control de esos molestos desarrolladores, pero, por supuesto, ves la realidad de la situación.

Agile no tiene que ver con seguir una ruta prescrita, está diseñado para hacerte más productivo y motivado. La gente no procesa dice el manifiesto (parafraseado), y eso se pierde en el sistema que estás usando.

Así que cambialo. Coméntelo 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. Muestra el Manifiesto Ágil (y su gemelo malvado ) y demuestre que no solo ha aprendido las lecciones de este experimento, sino que también desea convertir las partes buenas de él en un mejor sistema (uno que es como solía tener, que parece funcionar bien para usted).

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

Desafortunadamente, creo que una gran cantidad de software es menor 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 sensación de propiedad.

No tengo idea de cómo sugerirte que hagas las cosas mejor o más divertido, pero es una gran pregunta y una muy buena visión.

¿Está recibiendo historias de usuario en forma de "Como --role--, quiero --goal / desire-- para que --benefit--"? Parece que su propietario de producto quiere hacer el trabajo de diseño, y puede que él / ella 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 adhiera a los intereses comerciales y que los desarrolladores de software estén realizando el desarrollo del software.

En Scrum hay mucho espacio para que los desarrolladores contribuyan y den consejos sobre nuevas funciones, IU, facilidad de uso ... Se requiere colaboración y conversación entre empresarios y desarrolladores en Scrum, 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 después de sprint (en otras palabras, el ROI).

Del Manifiesto Agile:

  

Nuestra máxima prioridad es satisfacer al cliente a través de principios y   entrega 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, usted debe tener la última palabra ya que usted es responsable de la calidad interna del software que produce.

Quizás trabajes en una empresa creada por desarrolladores donde los programadores tienen libertad para implementar las funciones que deseen. Sin embargo, la mayoría de las metodologías Agile establecen una clara separación entre las personas de dominio empresarial y el equipo responsable de producir software (desarrolladores, evaluadores ...), 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, diseño y otras actividades de meta-desarrollo que menciona (que, de nuevo, no se supone que sean realizadas por el propietario del producto), se supone que los equipos de Agile tienen funciones cruzadas y no tienen silos. Se supone que nadie debe poseer todo el conocimiento en torno a una actividad de desarrollo específica, por lo que tal vez haya una oportunidad para que usted pueda diversificar allí, en lugar de solo "código de código".

Al contrario, descubrí que tener un propietario de producto para tomar decisiones sobre la funcionalidad me permite dedicar más tiempo a la producción de código de calidad. Además, si hay inquietudes válidas, siempre puedo cuestionar las decisiones de los propietarios del producto, y eso generalmente conduce a discusiones fructíferas.

Aquí practicamos Scrum. Tenemos una reunión de planificación quincenal en la que alimentamos las prioridades comerciales actuales, los éxitos y los fracasos del sprint anterior, y decidimos, como un equipo , qué queremos abordar para el próximo sprint.

Una de las formas en que lo hacemos es ordenar la acumulación en una pizarra por complejidad vertical y prioridad comercial horizontalmente. Después de eso, el propietario del producto ha recibido su opinión, por lo que depende del equipo seleccionar lo que queremos hacer. Obviamente, desaprueba una tarea de baja prioridad y alta complejidad, pero esto lo decidimos como un equipo. Hace que las sesiones de planificación sean más largas, pero vale la pena, y una parte central del proceso Agile.

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

El problema real que estás describiendo es una patología común cuando los equipos adoptan una Metodología: apagan sus cerebros. Esto es tan cierto con un sistema ágil de nueva escuela como con los sistemas de peso pesado de la vieja escuela.

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

A: Refina tu implementación de x. Tal vez deje de hacerlo por completo. La Metodología no es tu jefe!

En este caso específico, parece que el propietario del producto puede 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.

No estoy realmente en sintonía con todo el asunto del scrum, ya que han sido más cascadas por un tiempo.

Pero, para ser honesto, esto parece más un problema del personal de administración que un problema de la técnica de gestión de proyectos. Como en eso hay más personas basadas que técnicas.

El rol de los líderes en un equipo autoorganizado sería una publicación de blog sobre algo que parece faltar en tu publicación. ¿Dónde está el equipo decidiendo qué trabajo se hace en un sprint? ¿Dónde está el equipo dueño del proceso y del trabajo? ¿Tienes a alguien que conozca Scrum lo suficiente como para que estés haciendo Scrum y no una versión pervertida?

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

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

La única salida que encontré hasta ahora fue abandonar el Scrum (a menudo no es posible y / o apropiado porque, después de todo, tiene sus ventajas) o introducir algo así como el 20% de tiempo de Google para dar a los desarrolladores una salida creativa aparte del "Usted es libre de elegir cómo implementar la Página de inicio de sesión ", porque en realidad no es su implementación. está restringido por el código existente y la arquitectura del sistema, es decir, a menos que uno tenga en cuenta la libertad de elegir entre 'un bucle para y un momento' una libertad.

  

Hay una gran diferencia entre que decida qué hacer o se le diga qué hacer .

En mi experiencia, hay un camino bastante largo para desde saber qué hacer a decidir qué hacer.

Al final de esta manera, por lo general, resulta que recibimos instrucciones no porque les tengan el poder y no porque ellos no tengan nada mejor que hacer. Todo lo contrario, al final de esta manera, cuando ellos obtienen la suficiente confianza en nuestro equipo, parecen sentirse aliviados y felizmente nos pasan el mayor control que podemos manejar (y si su confianza es realmente firmes, incluso intentan pasar más que eso)

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

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

Según mi experiencia, Scrum es para observarte profundamente lo que haces. Solo está sentado en tu hombro y observando lo que haces. A pesar de que tiene su propia ventaja, odio la metodología scrum. Se espera la cuenta, no la calidad. La calidad se está comprometiendo con la metodología scrum.