La comprensión de roles en el desarrollo ágil / ¿El PO siempre tiene la razón?

Siempre que la OP sea lo suficientemente responsable como para asumir la culpa si el producto falla, no debería ser una preocupación. El equipo del proyecto se preocupará si el PO echa toda la culpa a los equipos de desarrollo y diseño por la falla de un producto. Habrá diferencias de opiniones. Cuando el PO requiere que se haga algo de cierta manera, la única forma de evitar que eso suceda, si los expertos del equipo piensan lo contrario, es comunicar qué puede ser y qué es, y explicar las diferencias tanto como sea posible y el pros y contras. Requiere tiempo de cualquier equipo ágil para estabilizarse y lograr una buena velocidad.

Pruebas

El trabajo de prueba en un proyecto ágil recae en todos los miembros del equipo. Tiene sentido tener un ingeniero de pruebas dedicado en el equipo. Pero cuando empiezan a sentirse abrumados por el trabajo, otros miembros del equipo, especialmente los desarrolladores. Debería ser parte del proceso de revisión del código verificar y construir los cambios y probarlos. Esto puede requerir un poco más de esfuerzo, pero da como resultado una mayor calidad y menos bucles de prueba/corrección/prueba con el personal de control de calidad dedicado.

Dueño del proyecto

El trabajo del propietario del proyecto es decirle al equipo qué debe hacer el software, no cómo. Especialmente en las externalidades, no es raro que el PO pueda dar algunas sugerencias sobre cómo deberían ser ciertas cosas. Pero los expertos del equipo deberían tener la última palabra sobre cómo funciona algo. Por ejemplo, si el PO sugiere poner 1 TB de datos en Excel, el equipo debe retroceder y usar una base de datos adecuada en su lugar.

En el caso de UX, esto se complica un poco. La apariencia de una aplicación es un poco el qué y un poco el cómo. A menudo se trata más de gustos y patrones de uso aprendidos. Aquí ayuda hacer pruebas de usabilidad. Si no puede ejecutar una prueba de usabilidad externa adecuada, busque personas dentro de la empresa que coincidan con los usuarios esperados y muéstreles la aplicación. Los aprendizajes de las pruebas de usabilidad deben anular tanto a los desarrolladores como a la PO.

Con respecto a las pruebas, no existe un rol de prueba en un equipo Scrum. Las personas pueden tener afinidad con las pruebas y pueden describirse a sí mismas como probadores, pero eso no las hace responsables de las actividades de prueba. Todo el equipo es responsable de que se lleven a cabo todas las actividades necesarias para llegar a un producto potencialmente liberable.

Se supone que el PO debe tener una visión con respecto al producto que el equipo está creando y, en base a eso, crear elementos pendientes que son pasos hacia esa visión. Esta visión puede contener aspectos de UX, por lo que podría haber un acto de equilibrio entre la visión del PO y la opinión profesional de los diseñadores de UX. El PO ciertamente no siempre tiene la razón, pero los diseñadores de UX tampoco siempre tienen la razón.

Un rol que no vi mencionado en la pregunta es el de Scrum Master (SM). El papel del SM es doble:

1. El SM debe asegurarse de que se siga el proceso Scrum. Esto incluye garantizar que un sprint activo no se vea perturbado indebidamente por cambios en el alcance.
2. El SM debe resolver los impedimentos que impiden que el equipo alcance su máximo potencial. Esto podría incluir escalar problemas a la gerencia, por ejemplo, si hay muy pocos miembros del equipo con conocimientos de pruebas. O problemas que surgen en un retro y que están fuera de la capacidad de resolución del equipo.

La prueba casi solo está representada por una prueba en el equipo ágil. A él se le confían todas las eventualidades. Desde la planificación, estructuración hasta la prueba de aceptación, pruebas exploratorias. El probador critica esa sobrecarga de trabajo masiva, y eso que lleva meses en la retro. Pero no hay solución, o no se ofrece solución. Por lo tanto, el sentido detrás de lo retro no se da aquí.

¿Por qué no hay solución? La solución es obvia. Si un compañero de equipo tiene tanto que hacer que se convierte en el cuello de botella, lo ayudas . Eso significa que todo el equipo de desarrollo es responsable de las pruebas, como debería ser de todos modos.

¿Pero el equipo de UX no tiene ningún derecho en un equipo ágil?

De hecho, no lo hacen. Porque no existe tal cosa como un "equipo UX" en Scrum. Está el PO con su visión y está el equipo de desarrollo con las habilidades para implementar esa visión. Asumiendo que el equipo de desarrollo contiene expertos en UX, cuando las historias se refinan, puede haber una discusión animada sobre si una función debe o no contener una UX específica, pero al final, el PO decide cómo quiere que se vea el producto. El trabajo del equipo de desarrollo es ayudar con esta decisión aportando la experiencia y mencionando los "costos" (o tiempo de desarrollo) de cada variante. Pero si el PO quiere que el producto parpadee en rosa, entonces esa es su decisión.

No citaré el resto de sus preguntas línea por línea, pero permítame preguntarle algo: ¿el equipo de desarrollo puede decir cuánto se involucra en un sprint? Porque ese es el único problema que pude ver con lo que describes.

La planificación de Sprint es un proceso colaborativo. El PO no puede poner algo en el sprint que el equipo de desarrollo no haya aceptado. Para empezar, normalmente los sprints se autoajustan en función de la velocidad . Básicamente, miras lo que lograste en los últimos sprints y basas tu sprint actual en eso. Entonces (muy simplificado) si solo completa 4 historias de 10, el próximo sprint solo comenzará con 4 y, con suerte, terminará todas. Y luego el equipo de desarrollo y PO pueden ajustar eso. Pero solo juntos . Los cuellos de botella o la mano de obra insuficiente no son un problema del equipo de desarrollo. Trabajarán lo mejor que puedan. ¿Que el producto no está listo tan rápido como lo necesita la OP? Eso es el POproblema. Y si no pueden obtener más recursos de la gerencia, la gerencia tendrá que vivir con el hecho de que el producto llega tarde.

Scrum no es fácil de hacer bien. Parece fácil, pero es más que una simple guía. Le sugiero que consiga un buen entrenador de Scrum o un maestro de Scrum con mucha experiencia para que lo ayude a atravesar la transición. También necesita la aprobación de la gerencia. En acciones, no en palabras. Si no tiene eso (y lo insinuó), está destinado a fallar. Scrum no es un movimiento de base. No puedes hacer Scrum en contra de tu gestión. Porque es un proceso colaborativo y si la gerencia no juega a la pelota, no producirá resultados de calidad. Y volverá al punto de partida, cuando la gerencia vea los malos resultados y diga "vea que no funciona" cuando, de hecho, fueron ellos quienes lo hicieron fallar en primer lugar.

Por alguna razón, la gerencia está más inclinada a escuchar a un consultor por el que ya pagaron mucho dinero para escuchar, en lugar de creer que su propia gente también podría tener un cerebro. Entonces, si ese es el caso... consiga un consultor. Haz que la gerencia pague por lo mismo que les podrías decir, porque para ellos, un consejo vale más si hubiera costado más.

La transparencia es un valor clave de Scrum. No puedes resolver todos los problemas en el equipo y tampoco puedes hacer que la gerencia te compre todo. Tal vez simplemente no hay presupuesto para contratar a otra persona. Su trabajo no es trabajar para dos, o regañar a la gerencia por algo que no pueden cambiar. Tu trabajo es hacer transparentes las consecuencias de esa decisión. Tal vez proporcionando gráficos sobre el progreso o estimaciones o simplemente explicando que no es económicamente viable tener una prueba de desarrollador todo el tiempo cuando un especialista podría hacer un trabajo mucho mejor. Pero al final, ahí es donde termina tu responsabilidad. Lo reportaste . Lo hizo visible. Cualquier otra cosa depende de ellos.

Sin comprensión de la gestión para el desarrollo ágil

Esto probablemente se puede resolver entregando a los gerentes alguna información básica, por ejemplo, un enlace al manifiesto ágil y algunos blogs sobre el tema. También deben comprender que ningún formato de gestión de procesos es una panacea. Ni Agile, Waterfall o cualquier otra cosa que se te ocurra resolverá automáticamente todos los problemas. En última instancia, la calidad de las personas involucradas determina eso. Y me refiero a calidad en términos de habilidades específicas del rol, pero también habilidades blandas.

Una OP que no le enseña a la gerencia que necesita más personas y capacidad

La gerencia puede o no ser capaz de permitirse más recursos. Y la cantidad de recursos solo debe determinar qué tan rápido puede moverse un proyecto, no qué tan bien funciona. Entonces, si están contentos con la velocidad, entonces no debería haber necesidad de agregar más personas.

Una visión ambigua de la PO pero también de los departamentos ágiles.

Cualquier rol en un equipo Scrum debe tener una comprensión clara de cuáles son sus responsabilidades y cuáles son las responsabilidades de los otros roles. Si eso se entiende entonces debe haber respeto por las decisiones que cada persona responsable está tomando para su rol. Aquí hay un breve resumen:

Propietario del producto: Es el responsable último del producto. Por lo tanto, ella puede determinar lo que se desarrollará. Pero lo está haciendo manteniendo únicamente la lista de productos atrasados.

Scrum Team / Scrum Master: El equipo es responsable de trabajar en los temas de mayor prioridad de la cartera de productos. También son responsables de determinar cuánto tiempo toman las tareas de desarrollo y de organizar el trabajo en equipo. Todos los miembros del equipo deben ser técnicos y todos deben poder cumplir con las tareas de desarrollo. Eso incluye pruebas y tareas relacionadas con el control de calidad. Muchas organizaciones contratan "testers" como un rol separado del "desarrollador" (a menudo menos pagado) y ese parece ser el caso en su organización. Desde la perspectiva de un equipo ágil real, no se debe hacer esa distinción y un desarrollador debería poder escribir pruebas para el SW que desarrolla su equipo. Lo ideal es que los incentivos se dirijan a todo el equipo y no a miembros individuales.

El equipo es responsable de estimar su productividad y comprometerse con un conjunto de elementos de la cartera de productos que se desarrollarán durante el próximo Sprint. El equipo debe hacer su mejor esfuerzo y si con frecuencia no logran sus objetivos, entonces son malos para estimar y deben aprender a mejorar.

Un equipo de scrum no debe tener más de 5 a 10 personas. Si es más grande, debe dividirse en varios equipos.

¿El PO realmente siempre tiene la razón?

Ver mi punto anterior. Siempre tiene razón cuando se trata de determinar cuáles son las prioridades de los elementos en la cartera de productos. Esto determinará qué se elegirá para el desarrollo en la planificación del próximo Sprint. Se debe confiar en él en términos de esas decisiones, pero no puede participar en la determinación de los plazos de desarrollo o las decisiones de implementación técnica. Solo puede influir en el desarrollo al proporcionar los elementos correctos de la cartera de pedidos con descripciones para la próxima planificación de Sprint. No puede influir en el desarrollo durante un Sprint y ni siquiera necesita ser parte de la planificación del Sprint si las historias de usuario en la cartera de pedidos están bien descritas.

¿El PO también puede decidir perjudicar al equipo?

Esa es una pregunta absurda y la respuesta debería ser obvia.

Lo retro no funciona porque no hay soluciones. Los otros problemas importantes no se pueden resolver.

La retroalimentación retrospectiva debe ser principalmente para la organización interna del equipo Scrum, pero si hay sugerencias para la gerencia, deben documentarse y enviarse por escrito a los gerentes responsables (con CC a los gerentes superiores si no ocurre ninguna reacción/respuesta).

El equipo se siente traicionado tanto por el PO como por la dirección. Esto conduce a reacciones de enojo.

Arreglar los sentimientos de los equipos debe ser su primera prioridad. Tenga en cuenta que absolutamente debe confiar en el PO en sus decisiones sobre la cartera de pedidos y, por otro lado, asegúrese de que pueda confiar en las estimaciones y los resultados del desarrollo de los equipos. Si está frustrado por la falta de recursos adicionales, debe organizar su equipo de scrum de manera diferente. Haga que algunos de los desarrolladores ayuden con las tareas de prueba y asegúrese de incluir esos esfuerzos en la planificación de Sprint. Esto significará que el equipo puede desarrollar menos funciones en un Sprint, pero todos estarán más contentos con los resultados.

Tenga en cuenta que es muy difícil arreglar un lugar de trabajo tóxico y solo es posible si todos quieren que suceda. Si sucede que es el caso debido a gerentes tóxicos, entonces no hay nada que pueda hacer más que encontrar otro trabajo.

Además de leer el manifiesto ágil , recomiendo ver el discurso "Agile is Dead" del pragmático Dave o leer su entrada de blog . Con eso y un poco de sentido común, probablemente no haya necesidad de un entrenador o consultor de Scrum.