Actualmente estoy trabajando en el proyecto X y el propietario de mi producto sigue impulsando nuevas funciones para el trabajo pendiente del sprint que debe completarse en ese sprint.
Empujar nuevas funciones a la cartera de pedidos no es el problema, el problema radica en el hecho de que él desea que yo y los otros desarrolladores las completemos de inmediato.
La forma en que nuestro PO lo maneja no es para nada profesional, ya que discutimos la importancia de las historias de usuario actuales en la reunión de sprint para el próximo sprint.
¿Cómo puedo dirigir esto a mi PO de manera profesional?
De hecho, el Manifiesto Ágil da la bienvenida a los cambios tardíos, consulte el punto 4:
Responde al cambio sobre el siguiente plan
Y la guía de scrum tiene esto:
Durante el Sprint:
No se realizan cambios que puedan poner en peligro el Sprint Goal ;
Los objetivos de calidad no disminuyen; y,
El alcance puede aclararse y renegociarse entre el propietario del producto y el equipo de desarrollo a medida que se aprende más .
Lo importante para ti es que tu equipo tiene una velocidad y has aceptado historias en el sprint en base a eso.
Lo que debe hacer ahora es hacer que la orden de compra establezca la prioridad dentro de la acumulación de esta historia. Si está por encima de un piso (o pisos) actual, lo estima y mueve los pisos más bajos hacia afuera hasta que equilibre su velocidad. Si la historia está por debajo de algo en el sprint actual, entonces, por definición, es menos importante, por lo que tendrá que esperar. Si la historia está al final del sprint y no hay tiempo suficiente para hacerlo, comience y continúe con el siguiente sprint.
Es (intencionalmente) así de simple, o es más importante y lo priorizas sobre el trabajo existente, o no lo es. Si el PO también lo quiere, recuérdeles que la velocidad es una métrica de lo que puede hacer, no un objetivo , si quieren cargarlo, pueden hacerlo, pero no lo lograrán.
Otra cosa es acordar un Sprint Goal con el PO/negocio según la guía. Si entra algo, también lo comparas con eso (¿Esta historia nos ayuda a alcanzar la meta?), si no, entonces necesita una llamada prioritaria sobre el trabajo que estás haciendo. Entonces, un error urgente puede ser prioritario, pero algo más se degrada porque no es parte del cumplimiento de la meta, o tal vez abandone el Sprint por el trabajo de mayor prioridad).
Estoy de acuerdo con todas las afirmaciones anteriores sobre Agile que permite flexibilidad y cambio.
Pero (¡muy grande, pero!) He trabajado con PO que a menudo son bomberos durante todo el sprint de Scrum. Si eso sucede, puede ser muy molesto y/o desmoralizador para el equipo tener que adaptarse constantemente a estos cambios. ¡Este cambio continuo de prioridades también puede afectar seriamente los lanzamientos y, como resultado, tendrá un efecto negativo en el ROI!
En estos casos, he formado parte de equipos donde se tomó la decisión de abandonar Scrum y experimentar con Kanban. Este último ofrece mucha más flexibilidad en la definición de requisitos que Scrum. Kanban también es más adecuado para la entrega continua que para los lanzamientos regulares.
Para leer más, desde dos perspectivas, eche un vistazo a estos enlaces:
https://www.scrumalliance.org/community/articles/2014/july/scrum-vs-kanban
http://kanbantool.com/kanban-library/scrum-and-kanban/kanban-vs-scrum-how-to-make-the-most-of-ambos
Finalmente, tomando una cita de la última referencia
...nunca dejes de mirar hacia atrás, para aprender de tu experiencia y seguir experimentando, ya que nunca sabes qué posible solución puede resultar mejor para ti.
Hablando como alguien que ha sido CTO y Jefe de Producto en diferentes organizaciones, estoy en gran medida de acuerdo con @The Wandering Dev Manager pero quería agregar más de lo que permitiría un comentario.
Esto no debería estar sucediendo como se describe. Veo muchas señales de alerta tanto en la frecuencia como en la inmediatez de las solicitudes. Sugiero tener una conversación honesta con el propietario del producto sobre su proceso actual y cómo afecta su trabajo. También comenzaría a buscar otro trabajo, ya que esta situación podría no mejorar.
Si el propietario del producto es simplemente malo en su trabajo, eso es realmente bueno: puede mejorar o puede ser reemplazado. Desafortunadamente, muchas veces existen situaciones como esta porque el propietario del producto es bastante bueno en lo que hace, pero se ha visto obligado a seguir ciertos patrones debido a la presión desde arriba. No todo el mundo puede invitar a su director ejecutivo a despedirlos en cada batalla. Cuando este es el caso, la situación no mejorará.
En general, los cambios durante un sprint están bien, pero debes estar preparado para ellos. Siempre me aseguro de que mis equipos de producto y tecnología completen los sprints con suficientes puntos para manejar las "soluciones urgentes" y los errores. Cuando ejecuté un producto en una empresa de medios, mis equipos sabían que debían reservar un número determinado de puntos en cada sprint; siempre surgía algo, ya que esa era la naturaleza de nuestro negocio. Nuestro sistema funcionó, porque siempre podíamos planear que sucediera algún tipo de evento. Si un evento pronosticado de alguna manerano sucedió, entonces el tiempo sobrante podría usarse para proyectos personales, tareas domésticas o [¡jadeo!] Salir adelante. El manejo de las características/cambios de última hora siempre quedó a discreción del gerente de producto y en consulta con el gerente de proyecto y el gerente técnico de ese equipo. Siempre nos aseguramos de que la moral del equipo también fuera un factor. Nunca se prometió nada a las unidades de negocio más que un "mejor intento de entrega".
A veces, se toma una decisión comercial extremadamente mala, y nadie se da cuenta de esto hasta que comienza el sprint. Esto ha pasado mucho con las startups a las que aconsejo. Manejar este tipo de situación es bastante simple: tiene una reunión de todos para volver a señalar, volver a priorizar y volver a programar. El sprint es abortado; empiezas desde cero.
Es posible que las partes interesadas de su negocio no entiendan que se necesita una planificación adecuada por muchas razones. Minimiza los gastos generales administrativos, permite que los sistemas interconectados se construyan de manera más eficiente, permite la previsión y la planificación en cómo se diseña una solución... Hay una larga lista de razones, pero solo hay 2 conclusiones principales que las partes interesadas y los propietarios del producto deben comprender:
Cuando el cliente es una organización interna, esto significa que los jefes de departamento deben discutir. Si el cliente es un cliente externo, la empresa debe decidir si la relación comercial es reparable o incluso justificada.
En teoría, estoy de acuerdo con @The Wandering Dev Manager, pero creo que él / ella está facilitando potencialmente que el PO cambie el sprint.
Es trabajo del PO resistir el cambio al sprint (no prevenirlo) de entidades externas (clientes). A menos que haya alguna situación crítica, el sprint debe considerarse inmutable.
Además, se supone que el ciclo de sprint es corto para que cualquier cosa nueva que surja pueda priorizarse en el siguiente sprint sin afectar al cliente. Si tiene sprints de varios meses, entonces realmente no está siendo ágil. El objetivo es un cambio rápido con algún cambio visible (2-4 semanas).
Pero un sprint puede cambiar. Si lo hace, se debe calcular el costo de los elementos nuevos y eliminar una cantidad equivalente de trabajo del sprint para compensar.
Entonces, ¿qué debes hacer al respecto? Bueno eso depende. El trabajo de PO es mantener el sprint. ¿Lo está haciendo? ¿Está dejando el trabajo apropiado para compensar? De lo contrario, "The Scrum Master" debería hablar con el PO.
Esto es lo que causa su orden de compra:
He estado haciendo una de las tareas en el sprint. He realizado cambios en mi base de código local. No estoy del todo terminado. Una vez que termino y estoy satisfecho de que todo está a la altura, pasa a una revisión del código, pasa por el control de calidad y luego se integra en el código de desarrollo compartido. Si transcurre mucho tiempo entre que empiezo la tarea y estoy lista, habrá cambios en el código de desarrollo compartido que entrarán en conflicto con mi trabajo, lo que generará trabajo adicional y riesgo.
Su PO, si obtiene lo que quiere, me obligaría a interrumpir mi trabajo y continuar con otra cosa. Algún tiempo después, vuelvo a la primera tarea. En ese momento, he olvidado la mitad, así que me toma tiempo comenzar de nuevo. Las cosas que estaban en mi mente que necesitaban ser hechas se dejan caer. Caídas de calidad. Cuando termino, hay muchos más cambios en el código compartido, muchos más conflictos, más tiempo perdido.
Al mismo tiempo, destruye totalmente cualquier motivación. Empezar una tarea y que te digan a la mitad que no la quieres es totalmente desmotivador. Y estar desmotivado no aumenta exactamente la productividad. ¿Por qué deberías esforzarte en la siguiente tarea cuando esperas que también se lleve a cabo?
No me sorprendería que este tipo de cosas, que ocurren regularmente, reduzcan a la mitad la productividad de un equipo. En otras palabras, el material nuevo que se insertó en el sprint no se terminará más rápido que si el PO hubiera sido paciente, mientras que el material original se retrasa enormemente. En lugar de dos semanas para los artículos originales y dos semanas para los artículos nuevos, se tarda una semana en comenzar con los artículos originales, tres semanas para los artículos nuevos y dos semanas para terminar los artículos originales. En lugar de cuatro semanas + un equipo feliz, se necesitan seis semanas + produce un equipo infeliz y desmotivado.
Lo que hace su PO puede ser completamente legítimo. Supongo que está en un negocio comercial y el dinero de sus clientes pagará su salario. Hay momentos en que su gente de negocios dice "OK, cambio total de plan" y cuando debe aceptar eso.
Por otro lado, es su responsabilidad hacia los propietarios de la empresa entregar un producto de calidad a un ritmo sostenible, no arruinar su arquitectura porque alguien tiene una idea nueva cada semana.
En situaciones como esta, tener un proceso para esperar lo inesperado es clave. Por ejemplo, una póliza en la que se cambia un piso por otro piso del mismo tamaño es una buena forma de mantener el equilibrio:
En el proceso Scrum,
scope creepocurre cuando el propietario del producto, o cualquier otro miembro del equipo Scrum, aporta trabajo adicional (p. ej., "bañado en oro" o colación de deuda técnica) en el sprint sin discutirlo con el equipo. Todo el equipo siempre debe negociar sacar una historia de usuario del Product Backlog y traerla al Sprint Backlog actual. Sin embargo, si el equipo ha terminado todo el trabajo al que se comprometieron en el sprint actual y no hay forma de que un desarrollador pueda ayudar a otro o probador, pueden plantear el problema en la próxima reunión diaria y solicitar traer nuevos trabajar.
Además, compartir los comentarios y las métricas de los clientes dentro del equipo ayuda a aclarar si es necesario o no un cambio en el producto en sí, los mensajes que lo rodean o el análisis de los datos. Tener una hoja de ruta y adherirse a ella es clave, pero esto solo funciona si todos conocen el plan y los cambios son bidireccionales:
Podemos agregar o cambiar tareas en el plan trimestral, pero esto se refleja como un aumento del alcance y un cambio explícito en el plan.
Referencias
magisch
usuario48138
usuario45590
usuario45590
paparazzi
usuario48138
paparazzi
usuario45590
jane s
El administrador de desarrollo errante
usuario48138
El administrador de desarrollo errante
usuario48138
El administrador de desarrollo errante
alan larimer