Según mi experiencia, en las empresas de software de tamaño mediano a grande, la agilidad suele surgir de la organización de ingeniería. Ya sea de base, desde el nivel de equipo, o patrocinado por ejecutivos de la alta gerencia de ingeniería. Significa que la organización de desarrollo a menudo usa Agile mucho antes que el resto de la empresa.
El desafío es que la organización de gestión de productos sigue operando en su modelo tradicional. Esto puede conducir a un obstáculo importante para la adopción ágil de proyectos. La organización de desarrollo está tratando de operar en un estilo iterativo, pero los requisitos aún se entregan en los documentos de requisitos de estilo antiguo y todos se detallan por adelantado. La resistencia a ir al modelo ágil a menudo puede ser alta. "No me importa cómo lo construya la ingeniería, solo construyo lo que quiero". Las organizaciones de gestión de productos rara vez quieren hacer el compromiso de tiempo que necesita hacer un propietario del producto. Están demasiado ocupados corriendo a la próxima reunión con el cliente.
Conozco dos modelos para tratar de involucrar a la organización de administración de productos.
Project Manager/Scrum Master actúa como una interfaz de PO: trabaja con la organización de PM para capacitarlos y traducir sus requisitos. Sustituye al PM como PO en las reuniones periódicas. Personalmente he trabajado con este modelo y no creo que funcione bien.
Crear una oficina de Propietario del Producto: Escuché de una empresa mediana en la que el vicepresidente de ingeniería creó una oficina de Propietario del Producto. Esta oficina es de ingeniería y cuenta con personal técnico con conocimiento empresarial. La gestión de productos entrega sus requisitos a esta oficina y el proceso ágil normal comienza desde allí. No hay información sobre qué tan exitoso (o no) es esto.
¿Alguna sugerencia?
Yo abordaría la situación desde la perspectiva de la gestión del cambio . Lo que describió es un problema común y sucede todo el tiempo y no solo con Agile. El cambio proviene del interior del grupo, de los desarrolladores, y en lugar de adaptarse, los grupos optan por luchar contra la nueva norma.
Lo que necesitas es algo que se muestra en este video . Hay un chico que empieza a bailar - uno gracioso -, y por un rato baila solo. Un poco más tarde, el primer adaptador se une a él, le muestra cómo bailar y bailan juntos, mientras los demás observan. Después de un par de minutos se une el resto y bailan juntos. Para mí, el primer bailarín es un PO de mente abierta , el baile es Agile, sin embargo, las cosas no sucederán tan rápido.
La lista TODO para comenzar algo similar:
Encontrar el PO correcto es una tarea difícil , pero debe haber un tipo que haya sido desarrollador antes, o que sienta curiosidad por las cosas nuevas. Estoy bastante seguro de que existe. Sin él, el cambio no sucederá, así que debes encontrarlo.
Ayudarlo a convertirse en un iniciador significa que debe trabajar con él para convertirse en un gran PO. No hay una buena receta, pero creo que el método shuhari es el mejor para este tipo de acciones. Primero ( shu ) tiene que aprender lo que significa Agile, segundo ( ha ) tiene que hacer su versión de Agile y tercero ( ri ) debe continuar su viaje solo, ser un maestro y correr la voz.
El último paso requiere que sepa cómo cambiar una organización usando su comportamiento . El libro Influencer es el mejor comienzo. Describe cómo cambiar cualquier cosa mediante el comportamiento. El PO necesita este conocimiento, porque un baile divertido atrae a más personas que una metodología de desarrollo de software elegante y difícil de adaptar.
Una vez hablé con un gerente de proyecto exitoso que dirigía la organización más exitosa en su antigua empresa. Introdujo el empoderamiento en su organización. Vivió con las normas requeridas para hacerlo realidad y al rato aparecieron sus compañeros y le pidieron la receta. Y el cambio comenzó a suceder. Por supuesto, no todos lo siguieron, pero después de alcanzar la masa crítica no tendrían otra opción . Soy consciente de que esta no es una historia ágil, pero se trata del cambio, así que creo que se aplica.
Por lo general, mi preferencia sería crear equipos en torno a productos, clientes objetivo o mercados objetivo. En ese escenario, la gestión de productos sería solo una parte diferente de un equipo que también incluye todos los roles de ingeniería. Eso, sin embargo, podría no ser factible.
Algunas organizaciones, la que usted describe parece ser una de ellas, están organizadas por funciones, gestión de productos en una parte de la organización e ingeniería en una parte diferente. Hay diferentes técnicas que he usado con diversos grados de éxito en el pasado.
Una opción que funcionó en algunos casos es tener una persona en el equipo de ingeniería que interactúe con la gestión de productos. Esta persona sería el propietario del producto desde la perspectiva del equipo de ingeniería. A pesar de que la gestión de productos aún escribiría todo en grandes lotes, el propietario del producto puede dividirlo en partes más pequeñas para el equipo. Mi recomendación sería luego poner a disposición de la gerencia de producto cada pieza más pequeña a medida que se completa, invitándolos a revisar lo que se ha logrado y brindar retroalimentación.
Las primeras de estas reuniones de "revisión" pueden ser muy desafiantes. Sin embargo, según mi experiencia, siempre hay miembros de la gestión de productos que descubren el valor de tener una visión temprana del progreso del proyecto y tener una oportunidad temprana para proporcionar comentarios. Una vez que comiencen a ver esto como una ventaja, es probable que la gerencia de productos comience a presionar para obtener más. Como resultado, ha iniciado un proceso de mejora incremental hacia conjuntos de requisitos más pequeños y hacia un proceso más ágil.
bobo2000