Scrum roles mezclados

7

Aquí, en la oficina, nuestros roles de Scrum están un poco confundidos, por lo que agradecería cualquier consejo sobre cómo mejorarlo.

Somos un pequeño equipo de 4 desarrolladores (uno de los cuales es un scrum master de facto) y también tenemos un gerente de línea y un propietario de producto. El administrador de línea abraza simultáneamente a Scrum y tiene dificultades para "soltar"; él tiene el Product Backlog en su cabeza y también lo prioriza.

Un intento anterior de sacarlo de su cabeza solo llevó a un Product Backlog actualizado y de corta duración en Pivotaltracker.com; políticamente hablando, fue el programador que construyó el sistema actual hace 7 años. El propietario del producto ha estado en la empresa durante aproximadamente 2 años y parece tener una visión clara del producto, pero nuestro gerente de línea no tiene suficiente poder (que de hecho es el responsable de este y otros proyectos). Aparte de esto, nuestra implementación de Scrum es "por el libro".

¿Cuáles crees que son las desventajas de esta estructura en la que nos encontramos? ¿Qué podría mejorarse? ¿Cómo mejorarías?

    
pregunta Pomario 30.08.2011 - 13:53

4 respuestas

8
  

El administrador de línea abraza simultáneamente a Scrum y tiene dificultades para "soltar"; él tiene el Product Backlog en su cabeza y también lo prioriza.

Supongo que su administrador de línea está cumpliendo el rol de Scrum Master. En este ejemplo, no está aceptando los roles tradicionales de Scrum.

Uno de los aspectos clave de cualquier metodología ágil es la alta visibilidad. Eso significa que los productos de trabajo son visibles para el cliente de forma regular (como se ve a través de lanzamientos frecuentes de productos que se pueden enviar), pero también que el equipo puede ver el estado interno y las métricas. La acumulación de productos y su estado actual no deben estar en la cabeza de nadie, sino que deben ser visibles para todo el equipo (y algunos incluso podrían discutir con el cliente, si lo desean).

Además, se supone que el Propietario del producto es el propietario del Product Backlog. Es el trabajo del Propietario del producto escribir historias de usuarios, priorizar esas historias en el Registro de productos y garantizar que las historias se completen correctamente (verificadas y validadas).

  

El propietario del producto ha estado en la empresa durante aproximadamente 2 años y parece tener una visión clara del producto, pero nuestro gerente de línea (que, de hecho, es responsable de este y otros proyectos) tiene poca capacidad. p>

El propietario de su producto debe tener la capacidad de hablar en nombre del cliente; de lo contrario, esta función no tiene sentido. Tener una visión clara es importante, pero si no puede actuar sobre esta visión y crear y priorizar historias para permitir que el software alcance el máximo valor, entonces no puede cumplir con las responsabilidades del Propietario del producto.

  

¿Cuáles crees que son las desventajas de esta estructura en la que nos encontramos? ¿Qué podría mejorarse? ¿Cómo mejorarías?

Las desventajas son que no estás utilizando a tu gente. No tiene sentido tener un visionario o un campeón si no pueden hacer nada para actuar sobre sus visiones u objetivos. Todo vuelve a la conclusión: ¿qué les está pagando a estas personas por hacer y son capaces de hacerlo? Parece que no pueden cumplir con sus responsabilidades, por lo que hay que arreglar algo.

La única forma de mejorar es reevaluar los roles y asegurarse de que todos conozcan sus responsabilidades para con el proyecto y el producto. También debe centrarse en la calidad del producto y el proceso en lugar de seguir un proceso a la carta. Tal vez Scrum, de acuerdo con el libro, no sea lo que necesita, así que adapte el proceso para que se ajuste a la forma en que funciona su equipo y organización.

  

Aparte de esto, nuestra implementación de Scrum es "por el libro".

Siguiendo con mi último pensamiento, cualquier implementación de proceso "manual" me preocupa. Scrum es un marco para la gestión de proyectos. Se describe la implementación concreta y las historias de éxito, pero son para equipos particulares dentro de organizaciones particulares que trabajan en proyectos particulares. Scrum es un marco perfectamente fino, siempre que lo adapte para satisfacer las necesidades de su equipo dentro de su organización que trabaja en su proyecto.

    
respondido por el Thomas Owens 30.08.2011 - 14:11
2

No me suena como si hubieras mezclado tus roles de Scrum. Parece que tienes un individuo que no está seguro de cuál es su función y está anulando el papel de otra persona en el proceso de intentar demostrar su valor continuo.

Siéntese, como un equipo, y descubra lo que necesita de su líder de equipo. ¿Necesitas que sea un gurú técnico? ¿O un gurú del dominio? ¿O necesitas a alguien que sea un "ninja con cuello de botella", eliminando todos los problemas que retrasan al equipo de desarrollo? O si no necesita nada de esto, como un equipo Agile completamente maduro, ¿necesita reintegrarlo de nuevo al desarrollo?

Involúcrelo en esta conversación. Mira lo que quiere de la situación. Puede ser que prefiera volver al desarrollo. Puede ser que esté desempeñando el papel de Propietario del producto porque no cree que la orden de compra actual sea lo suficientemente buena.

La comunicación honesta siempre es clave en estas situaciones.

    
respondido por el pdr 30.08.2011 - 14:53
2

@Thomas Owens ha identificado sus problemas y le ha dado soluciones , pero me gustaría añadir algunas sugerencias más.

Los 4 miembros del equipo deben comprometerse con el PivotTracker o lo que prefieras. Si el gerente de línea quiere algo en su cabeza, esa es su perogotina, pero el resto de ustedes necesitan ponerlo por escrito. Me siento en muchas reuniones y obligo a los gerentes a disminuir la velocidad porque estoy tomando notas. Asumir la responsabilidad como equipo para organizarse.

El propietario del producto debe poder defender a los clientes y no dejar que los tecnólogos se aprovechen porque saben más acerca de la programación. Es posible que el propietario del producto no sepa tanto sobre los clientes como su gerente de línea. Eso es una vergüenza y una indicación de que no pueden hacer su trabajo y que alguien más se está recuperando. Hay situaciones en las que alguien construyó la aplicación y tal vez tuvo mucho contacto con clientes / usuarios y está operando con información y suposiciones obsoletas. Hace siete años, la mayoría de los usuarios no estaban interesados en una interfaz de Facebook. Los tiempos han cambiado. Es posible que su equipo tenga que hacer un esfuerzo para obtener las necesidades del cliente del Propietario del Proyecto si el gerente de línea no le hace caso a la persona por los motivos incorrectos.

Las partes interesadas se quejan menos cuando cuidan a sus clientes. Haga de eso una prioridad y trabaje alrededor de sus líderes disfuncionales.

    
respondido por el JeffO 30.08.2011 - 15:17
1
  

El gerente de línea ... tiene el Product Backlog en su cabeza y también lo prioriza.

Considere imprimir un póster grande de esto y colocarlo en la pared justo donde su SCRUmanager pueda verlo claramente: Manifiesto para Half-Arsed Agile Software Development ... mientras que los elementos de la izquierda suenan bien en teoría, somos una empresa empresarial y no hay forma de que dejemos de lado los elementos de la derecha.

    
respondido por el gnat 30.08.2011 - 17:26

Lea otras preguntas en las etiquetas