Cuando tiene un Product Owner que es menos técnico, ¿pueden los desarrolladores ser descubiertos por los usuarios y las partes interesadas?
Por ejemplo, un nuevo proyecto está en marcha y el PO está descubriendo, creando epopeyas, historias de usuarios, etc. Sin embargo, los desarrolladores entienden los aspectos técnicos mejor que el PO; ¿Deberían incluirse en las discusiones con los usuarios y las partes interesadas?
Parece que no es una buena idea, pero realmente nunca había pensado en eso antes y Mike Cohn realmente no lo aborda en ninguna de sus publicaciones.
Sí, por supuesto, ¿por qué el equipo de desarrollo debería conformarse con información de segunda mano? ¡Los equipos autoorganizados deben obtener la información de la fuente!
Me gusta mucho este artículo de Cargo Cult Agile Checklist :
Se impide que las partes interesadas hablen con los equipos de Scrum
¿Qué son las partes interesadas? (citado de Modelado ágil: participación activa de las partes interesadas )
Una parte interesada es cualquier persona que sea un usuario directo, un usuario indirecto, un administrador de usuarios, un gerente sénior, un miembro del personal de operaciones, el "propietario de oro" que financia el proyecto, un miembro del personal de soporte (mesa de ayuda), auditores, su programa/gerente de cartera, desarrolladores que trabajan en otros sistemas que se integran o interactúan con el que está en desarrollo, o profesionales de mantenimiento potencialmente afectados por el desarrollo y/o despliegue de un proyecto de software.
Así que esto significa que todo el mundo es una parte interesada. ¡Involúcrelos! Pero, ¿a quién invitar, a todos?
Mis equipos actuales intentan invitar a las partes interesadas clave a nuestras sesiones de refinamiento y planificación para obtener el contexto de la fuente. Quién está invitado depende en gran medida de los temas que estemos manejando. El Product Owner hace esta llamada, el Scrum master se asegura de que el PO piense a quién invitar por adelantado. Las partes interesadas explican el contexto, el equipo de desarrollo hace preguntas.
Promueva que el equipo de desarrollo hable con tantas partes interesadas como sea posible. Esto para recuperar el conocimiento del dominio y la comprensión de cómo los usuarios reales usan el producto. Las reuniones de planificación, revisión y refinamiento son el lugar ideal para esto, ya que los desarrolladores ya están fuera de su zona (de codificación).
Simplemente pruébelo e inspeccione y adapte después de algunas sesiones con PO, usuarios y desarrolladores incluidos. Pídales sus comentarios o realice una retrospectiva específica para ver qué funciona y qué no para este tipo de comunicación de descubrimiento.
En ciertas situaciones, creo que deberían, pero hay muchas advertencias y trampas. Permítanme enumerar las razones por las que lo he hecho, y también las ocasiones en que no lo haría y tal vez eso lo ayude a considerar lo que necesita.
Antes de comenzar, quiero hacerme eco de Sarov, sin embargo, si su razón principal para hacer esto es porque el PO no es técnico, entonces se debe hacer algo de capacitación allí para ayudarlo a comprender. Independientemente de la validez de las siguientes razones, esa falta de experiencia/capacitación aún debe corregirse a largo plazo. Si los requisitos son su problema principal, haría que el experto en scrum ayudara al PO a escribir los requisitos y explicárselos al equipo, y con el tiempo ayudaría al PO a hacerlo mejor. Esta es probablemente la respuesta principal a su pregunta, pero voy a hablar sobre la participación de los desarrolladores, ya que sigo pensando que podría ser valioso para usted.
Razones por las que he involucrado a los desarrolladores en el descubrimiento:
Identifiqué un problema en el que el descubrimiento avanzaba muy lentamente, y había un gran problema en el que la empresa y la OP profundizaban demasiado en sus ideas y en cómo se iban a implementar, se involucraban emocionalmente y luego las arrojaban por la borda. muro al desarrollo. Como parte de mi estrategia para solucionar esto, instituí un proceso en el que todo el equipo de producto estuvo involucrado desde el primer día para ayudar a guiar el curso del producto. Esto no siempre fue asistencia, pero fue visibilidad para todos. Al principio hice que un desarrollador y un diseñador asistieran a las reuniones principales, pero como esperaba, a medida que todos se acostumbraban a trabajar juntos y comunicarse, esto se volvió cada vez menos necesario a medida que se establecía la confianza y el respeto y el PO se volvió más versado en problemas de desarrollo La comunicación continuó incluso cuando no hubo asistencia,
Otra buena razón por la que involucré a los desarrolladores desde el principio es que, para algunos proyectos, quería que escucharan los puntos débiles de primera mano de la boca del cliente. Esto requiere un poco de tiempo para un desarrollador, pero nuevamente conduce a una mayor aceptación y comprensión del problema que el proyecto está tratando de resolver. Descubrí que en muchas situaciones esto conduce a una mayor creatividad e ingenio por parte del desarrollador, ya que tienen una mejor comprensión de los desafíos para el cliente. Esto conduce a un producto mejor que el que podría ser el caso de otra manera, que es una de las principales razones de Agile, y está respaldado por estos principios en el Manifiesto Agile:
Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso . -Énfasis añadido
El método más eficiente y efectivo para transmitir información a un equipo de desarrollo y dentro de él es una conversación cara a cara . -Énfasis agregado http://agilemanifesto.org/principles.html
Para resumir, las principales razones para involucrarse en el desarrollo son si les ayudará a construir un mejor producto. Esto debe analizarse proyecto por proyecto y, en general, debe ser una decisión del equipo. Si el proyecto es pequeño, tiene una base más interna o tiene un nivel muy alto al principio y una descripción general simple o las notas de la reunión transmitirán el significado, entonces no me preocuparía involucrar a los desarrolladores.
Por lo general, se considera que los desarrolladores pueden interactuar con los usuarios y las partes interesadas en la forma en que lo solicitó como una excepción en lugar de la regla .
Siempre tienes tres roles:
Siempre hay alguien en cada uno de esos sombreros. Podría ser una persona que se sienta detrás de la pantalla escribiendo una nueva red social con tres sombreros uno encima del otro. O una gran empresa con departamentos caminando en un sombrero estrechamente especializado cada uno.
Volviendo a su pregunta, ¿cómo tomar realmente una decisión "deberían los desarrolladores hablar con los usuarios durante el descubrimiento" o no? Depende únicamente del objetivo que quieras lograr, si es bueno para tu objetivo o no. Y asumo que el objetivo es la visión de la organización como un mecanismo detrás del producto entregándolo como valor de la manera más eficiente posible.
Si la distribución actual de sombreros (roles) entre las personas es la misma que debería ser en su organización, entonces lo está haciendo todo bien. Pero dado que existe una persona con título de PO, podemos concluir que se supone que esta misma persona debe llevar un sombrero de PO, y en realidad no puede hacerlo. La distribución de sombreros parece estar mal y la respuesta a su pregunta en su situación es: no, no deberían. (O alguien tiene un título incorrecto que no coincide con el rol real).
También algunos ejemplos cuando desea un compromiso directo no en la forma en que lo solicitó :
El equipo de desarrollo no tiene nada que hacer ya que PO como cuello de botella no puede cargar el equipo. Podemos aliviar el cuello de botella sin pasar por alto y cargar el equipo de desarrollo de los usuarios directamente. ¿Deberíamos hacer eso?
Desafortunadamente, aquí es donde tiene lugar el verdadero arte de la gestión de proyectos. Debe considerar todos los riesgos, consecuencias y beneficios tanto a corto como a largo plazo. Algunos de ellos ya se mencionan en otras respuestas.
PS Su pregunta asume que las partes interesadas son de alguna manera más técnicas que PO. Además, el equipo de desarrollo necesita obtener conocimientos técnicos de las partes interesadas. Esto suena muy sospechoso.
En teoría, podría, pero eso podría resultar en una pérdida significativa para el Desarrollador debido al tiempo involucrado y al cambio de tareas, especialmente si esto se hace en medio de un Sprint.
¿Qué ventaja esperaría aprovechar al tener desarrolladores presentes durante el descubrimiento?
Si es para que los desarrolladores obtengan una mejor comprensión de los requisitos, entonces me centraría en mejorar la capacidad de su OP para analizarlos y difundirlos entre sus desarrolladores.
Si es para que las partes interesadas puedan tener una mejor idea de lo que es factible, esto probablemente podría mencionarse durante la Revisión del Sprint, a la que se puede/debería invitar a las partes interesadas.
Niels van Reijmersdal