Soy scrum master certificado, pero nunca practiqué hasta mañana, cuando fui designado como ScrumMaster para una iniciativa piloto en la empresa para implementar scrum en un equipo que no es un software ni un proyecto, sino una actividad diaria. Te dejo imaginar toda la política en torno a esta decisión.
El trabajo comenzará el 1 de agosto y el propietario del producto ha programado una reunión mañana para crear la cartera de pedidos del producto conmigo y otra persona, que no formará parte del equipo.
Mis preguntas:
Conozco toda la teoría pero echo de menos los pasos muy prácticos para empezar.
Aquí hay más información:
Si no es un proyecto sino una actividad diaria, Scrum no es un proceso adecuado para eso. Debería considerar usar Kanban. Sin embargo, parece que todos ustedes han decidido usar Scrum. Entonces, responderé el resto de sus preguntas en base a Scrum.
¿Quién debería proponer la estructura de la cartera de productos mañana (yo o el PO)?
Desafortunadamente, parece que estás empezando con el pie izquierdo. Agile y Scrum se basan en la colaboración y el trabajo en equipo. Debe abordar esto con una mentalidad abierta de unir sus cabezas para encontrar la mejor solución.
¿Deberíamos crear historias de usuario directamente con el propietario del producto?
Sugiero que su primera sesión sea para articular la visión. El equipo debe desarrollar una comprensión compartida de hacia dónde se dirige (qué producto) y por qué se dirige allí (beneficios comerciales) antes de saltar a los detalles de cómo llegar allí (acumulación de productos). Eche un vistazo al Tablero de visión del producto de Roman Pichler para ver un ejemplo.
Tengo una reunión de una hora y, según tengo entendido, necesito más que eso. ¿Cuál es su sugerencia sobre cómo proceder?
Mi sugerencia para esta pregunta es la misma que para su primera pregunta. No pienses en términos de lo que necesitas. Piense en términos de lo que necesita el trabajo. Si el trabajo necesita más tiempo, al final de la hora todos pueden ponerse de acuerdo para reunirse de nuevo.
no pertenezco al equipo
Ahora lo haces. Tan pronto como fue nombrado Scrum Master del equipo, se convirtió en un miembro de pleno derecho del equipo. Comience con esta mentalidad y será un Scrum Master más efectivo.
Ashok tiene algunas sugerencias realmente sólidas aquí. Quiero modificarlos un poco para proporcionar algo de contexto:
Kanban vs. Scrum: Si como dices, el trabajo se hace a diario, ¿también se "envía" a diario? Por ejemplo, si su proyecto está reparando defectos informados por los clientes, entonces vienen diariamente y se asignan diariamente y no hay un vehículo de liberación. Scrum fallará por esto casi garantizado. Kanban es la mejor opción. No tiene un sprint de caja de tiempo. En su lugar, tiene una cartera de pedidos y límites de trabajo en curso (WIP). El trabajo se toma de la parte superior de la cartera de pedidos y se trabaja hasta que se termina, luego se "envía".
Todavía puede ser Scrum Master y aún llamarlo "Scrum" para evitar problemas de gestión. Simplemente configure sus iteraciones para un día y haga que su standup incluya la extracción del trabajo pendiente. Parte de su trabajo es brindar al equipo rieles de guía y protegerlos de la gerencia para que puedan hacer su trabajo.
Si tiene que ir con Scrum, entonces haga una iteración de una semana. Tendrá menos posibilidades de fallar al cambiar las confirmaciones de sprint.
Reunión de planificación del propietario del producto: como dice Ashok, y le preocupa, esto es muy temprano y no incluye a las personas que hacen el trabajo. Está bien, trabaja con eso. El propietario de un producto debe presentar su visión en algún momento. El propietario del producto es el propietario de la cartera de pedidos en última instancia. Solo tienen que asegurarse de que el equipo pueda ejecutar el trabajo pendiente.
Trabaje con ellos para tratar de obtener un flujo de nivel épico de lo que quieren hacer. Luego, comience con el entrenamiento temprano de que, para obtener el mayor éxito, debe configurar sesiones periódicas de preparación del trabajo pendiente con el equipo que hace el trabajo y (si opta por Scrum, no es mi recomendación) la planificación de sprints al comienzo de una iteración.
Una cosa en la que centrarse es la parte "Por qué" o "Así que" de las historias de los usuarios. Intente evitar que su OP tome decisiones tecnológicas "usará Perl", ya que ese debe ser el trabajo de los equipos de desarrollo.
Mucha suerte y vuelve con más preguntas, estamos aquí para ayudarte.