Ejecución del Sprint

Como Product Owner es bastante difícil desconectarse durante la ejecución del sprint porque parece que su función disminuye un poco. Sientes que el equipo avanza junto con el trabajo y solo estás ahí para ayudar cuando te hacen una pregunta.

Desde mi punto de vista, esta es otra área que puede ser un diferenciador para un gran Product Owner. Dicho esto, ¿qué hace un Product Owner durante el sprint?

En primer lugar, debes comprometerte completamente con el equipo. Asiste a todas las reuniones diarias y escucha atentamente lo que está sucediendo. Busca oportunidades para colaborar con el equipo todos los días. ¿Hay probadores con los que pueda sentarse para definir y/o perfeccionar las pruebas de aceptación? ¿Hay historias o características que se acerquen a un estado de demostración? Si es así, siéntate con los miembros del equipo y bríndales una retroalimentación temprana. ¿Qué tal si aparecen errores que pueden necesitar tu juicio y atención? La lista de actividades continúa.

Recuerda también que eres un miembro del equipo, así que habla de tus propios esfuerzos en la reunión diaria. Comparte tus tareas, esfuerzos, planes para ese día, conversaciones que hayas tenido con los interesados, etc.

Prefiero que los Product Owners compartan el mismo lugar con sus equipos. No hay reemplazo para escuchar la actividad, conversaciones, emparejamientos, debates de diseño, preguntas, comentarios, errores, problemas o impedimentos, y simplemente estar allí participando de forma natural e inmediata, cuando y donde se te necesite dentro del equipo.

Sin embargo, en algunos casos esto simplemente no es posible. Por lo tanto, la responsabilidad recae en tu para buscar estrategias alternativas para apoyar a tu equipo. Algunos ejemplos incluyen:

• Si estás fuera de la oficina, accede a todas las reuniones de pie o reuniones relevantes, incluso mientras estás de viaje.
• Establece una noción de horario de oficina, donde estés disponible para el equipo; he visto una o dos horas por la mañana y por la tarde como enfoques bastante efectivos.
• Puedes delegar tus responsabilidades, como un conjunto o un subconjunto, pero asegúrate de que tu equipo sepa que lo estás haciendo; los detalles, por cuánto tiempo, etc. y quién lo representa y en qué capacidad.
• Incluso si estás a distancia o fuera de la oficina, comunícate con tu equipo con regularidad y pregunta si puedes ayudar. Hazles saber a todos que estás disponible, comprometido y que te importa.

Supongo que el punto aquí es que estar presente, incluso cuando no estás físicamente allí, es increíblemente importante para ti, tu equipo y los resultados finales del sprint. Mantente comprometido con el compromiso y tu equipo lo percibirá y responderá de la misma manera.

En muchos equipos, el Product Owner se encuentra en una posición maravillosa para comprender las necesidades y expectativas del cliente, tanto a nivel de historia como de objetivo. Dado eso, y su necesidad de comprender el progreso de los sprints, generalmente encuentro que los Product Owners pasan un tiempo considerable probando su aplicación.

Por lo general, trabajan con el equipo de pruebas y en entornos centrados en pruebas, de modo que el software es, en la mayoría de los casos, un poco más maduro. A intervalos regulares, controlan la interacción de las funciones y el flujo de trabajo; teniendo en cuando la experiencia general del cliente y la usabilidad de las funciones que se entregan dentro del sprint.

Una y otra vez tendrán preguntas y, como resultado, las pruebas impulsarán una colaboración saludable del Product Owner hacia el equipo. También colaboran intensamente con los evaluadores en los requisitos de las pruebas de aceptación de historias individuales y elaboran sus propias pruebas de aceptación para la ejecución automatizada.

El punto clave es que las pruebas son una extensión natural del rol de Product Owner y una excelente manera de contribuir a los esfuerzos de tu equipo de una manera visible y de alto impacto. Realmente recomendaría que esto sea parte de tu enfoque en cada sprint.

A medida que surgen impedimentos que se relacionan contigo, no esperes a que el Scrum Master lo rastree para una acción de seguimiento. En su lugar, se proactivo en hacer avanzar todas sus acciones de impedimento personal. Muestra al equipo que te preocupas por el nivel de atención y el enfoque en la resolución de impedimentos.

Además, mantente al tanto del progreso del sprint a través de tus cuadros burndown del sprint y otros radiadores de información. Mantén la curiosidad. Haz preguntas al equipo sobre el progreso del trabajo y desafíalos si sientes que el trabajo se está quedando atrás de su compromiso de meta. Si están por delante del plan del sprint, sin duda prepara trabajo adicional que puedan llevar a cabo en el sprint.

Si encuentras que un sprint está en peligro y el equipo se está quedando atrás, interactúa con tu Scrum Master y tu equipo para descubrir cómo puedes ajustar los contenidos del sprint y aun así cumplir con el objetivo del sprint. Estate dispuesto a escuchar todas las alternativas para cambiar el alcance del sprint, pero aún así lograr tus objetivos. Mantén la mente abierta. De hecho, sugiere ajustes de forma proactiva.

A esta actividad la llamo hacer micro ajustes en el contenido de un sprint. Cada ajuste debe estar alineado con el objetivo. Y los ajustes ocurren en “ambas direcciones”, basados en descubrimientos positivos y negativos.

Durante el transcurso de todo el desarrollo de software, surgen errores. Es simplemente natural. En el caso de Scrum y otras metodologías ágiles, deseas intentar resolver y/o corregir todos los errores tan pronto como se descubran. Tu equipo necesitará tu ayuda para decidir cuáles son los errores válidos e inmediatos frente a los que se puede diferir. Mientras mantienes una mentalidad “Lean – Arregla Ahora”, ayuda a liderar a tu equipo hacia adelante con una toma de decisiones equilibrada.

También debes hacer preguntas y reafirmar los niveles de calidad de su trabajo. He visto muchos Product Owners que se centran en ofrecer funciones, en lugar de ofrecer funciones de alta calidad. Quieres ser un Campeón de esto último y motivar al equipo hacia esto haciendo preguntas orientadas a la calidad. Por ejemplo: “¿Cómo se pudo evitar este conjunto de errores?” o “¿Qué podemos hacer para mejorar la calidad general del producto?”. Esto marca la pauta de que está igualmente comprometido con la calidad que con la producción, que es un mensaje extremadamente importante que tu equipo debe escuchar continuamente.

Como se indicó en la historia anterior, los sprints a menudo no salen según lo planeado y algo debe ajustarse en el medio de las cosas. Una razón podría ser realizar cambios de prioridad, basados en cambios de clientes externos al contenido del sprint. Otro es cuando el equipo se encuentra luchando con su compromiso original con el trabajo; si subestimaron o sobreestimaron las cosas. Y otra razón es que el software es, por definición, un esfuerzo desafiante y, por lo tanto, a veces pueden surgir riesgos inesperados. Vamos a explorar algunos escenarios aquí.

Un punto importante es que ninguna de estas acciones es responsabilidad exclusiva del Product Owner. De hecho, el líder aquí debería ser el Scrum Master. Él o ella es tu compañero y debe guiarte a ti y al equipo a hacer los ajustes necesarios, etc. Sin embargo, tú juegas un papel importante en lo que llamaré el proceso de recuperación del sprint.

El equipo está luchando por cumplir su compromiso de sprint. En los primeros días del sprint, tú y el Scrum Master se dan cuenta de que es necesario un ajuste. He visto varios enfoques para esto. Clásicamente, Scrum permite cancelar y volver a planificar tu sprint. Eso funciona bien si eres un equipo independiente. Sin embargo, si tu equipo está sincronizado con otros, entonces este enfoque puede resultar incómodo, ya que tendrás que planificar un sprint de longitud reducida para mantener la sincronización entre equipos.

Otro enfoque es simplemente realizar una reunión de replanificación o lo que yo llamo un “reinicio por software”. Aquí es donde el equipo, dados los descubrimientos recientes, intenta maximizar la entrega de contenido hacia el objetivo del sprint original. Dado que estás utilizando el backlog del sprint anterior como punto de partida, esta suele ser una reunión rápida en la que tú y el equipo definen un plan de juego ajustado para el sprint.

Si se hace con la suficiente rapidez, dentro de los primeros 1-3 días de un sprint de dos semanas, he visto a los equipos recuperar significativamente su progreso y, a menudo, alcanzar el objetivo del sprint original. Si se detecta demasiado tarde, simplemente estás tratando de maximizar la entrega hacia el objetivo; no alcanzar el objetivo en sí.

Seamos sinceros, vivimos en el mundo real donde las interrupciones son increíblemente comunes y dinámicas. Por ejemplo, si aparece un error de Gravedad 1 en el sitio de un cliente, rara vez es la respuesta correcta decirles que tendrán que esperar hasta el final del sprint.

O si tienes un arquitecto de base de datos para diez equipos Scrum, rara vez es la respuesta correcta que se centren en un equipo sobre los demás. Las interrupciones ocurren y la multitarea no se puede evitar por completo. Dicho esto, puede ser increíblemente desmoralizador para un equipo Scrum que sus sprints se descarrilen con interrupciones.

Cuando suceda, querrás discutir inmediatamente el impacto con el equipo y volver a planificar el sprint, tratando de mantener el objetivo del sprint tanto como sea posible. Pero más allá del sprint actual, intenta pensar un poco en cómo el equipo puede mitigar situaciones similares en sprints futuros, por ejemplo:

• Reserva de tiempo (capacidad) para interrupciones externas.
• Asignar a un miembro del equipo para que sea el “amortiguador” de las interrupciones externas.
• Planificación de menos trabajo dentro del sprint; sí, eso no es un error tipográfico, realmente lo dije.
• Generar un impedimento para las habilidades específicas del equipo con el fin de ejecutar eficazmente el backlog.
• Capturar el tiempo de interrupción durante el sprint como “arrastre” o tiempo de interrupción para poder cuantificar mejor los impactos.

Uno de mis Product Owners favoritos tuvo problemas para cambiar de opinión con bastante frecuencia dentro de los sprints. Estábamos trabajando en una aplicación de comercio electrónico SaaS (software como servicio) en la que “las cosas cambiaron” a menudo debido a la dinámica de los clientes y del mercado. En estos casos, era más probable que cancelara el sprint y luego volviera a planificar uno nuevo en función de un cambio de prioridad importante en el backlog.

Sin embargo, al volver a planificar, intentamos mantener la mente abierta sobre la integración del nuevo trabajo y el mantenimiento de algunos de los enfoques de los sprints originales. Esto disminuyó los sentimientos de los equipos de ser “sacudidos”.

Otro aspecto de esto es una anticipación insuficiente. Nunca estuve convencido de que no pudiera anticipar estos cambios de alguna manera. Recuerda, estábamos en un modelo de sprint de 2 semanas que es bastante ágil. Como discutiremos a continuación, mirar hacia adelante y anticipar errores es otra actividad importante durante la ejecución del sprint.

Durante el sprint, también debes monitorear el progreso hacia por historia y mapear el progreso en el gráfico de evolución general para tener una idea de si el sprint será exitoso o no; en otras palabras, prepararse para la revisión del sprint. Uno de los inquilinos principales de la agilidad es entregar y demostrar software que funcione, lo que debería suceder en Scrum en la revisión del sprint.