1 hora a 2,5 melés largos todos los días: ¿es una locura?

Nada de lo que describiste es Scrum

1. Scrum no tiene los roles que describiste.

2. No parece tener los dos roles esenciales para Scrum: el propietario del producto y el Scrum Master.

3. En Scrum todo no puede ser la máxima prioridad. El propietario del producto crea una lista ordenada. El equipo de desarrollo trabaja en ellos en ese orden.

4. En Scrum no hay reuniones de estado. El Daily Scrum es un evento de 15 minutos con un límite de tiempo para que el Equipo de Desarrollo coordine su trabajo.

No está claro por qué lo etiquetó como Scrum. Consulte la Guía de Scrum .

¿Qué llamadas harías? ¿Qué decisiones tomarías?

Sin embargo, si desea practicar Scrum, puede comenzar enviando a algunas personas para que reciban capacitación en Scrum. Su equipo es demasiado grande para ser un solo equipo Scrum. Puedes dividirlo en dos equipos Scrum. Puede designar el Scrum Master y el Product Owner para los equipos. Los equipos pueden compartir el mismo Scrum Master y/o Product Owner, si es necesario.

Mantener los equipos relativamente estables. Puede dividir los proyectos entre los equipos. Sin embargo, obtendrá una mejor productividad y la moral del equipo si cada equipo se enfoca en un proyecto por sprint. Puede hacer una excepción si hay errores de producción críticos en otros proyectos que no pueden esperar.

No es Scrum... ¿cómo mejorarías esto?

Tomaría dos pasos inmediatos para mejorar esto:

1. Dividir el equipo en dos y asignar la mitad de los proyectos a cada equipo : Independientemente de otros factores, la comunicación es un problema en equipos demasiado grandes. Como mínimo, ahorrará la necesidad de que todos se queden y escuchen todas las reuniones del proyecto.

2. Encuentre una manera de priorizar los proyectos : si la gerencia dice que "todo es de máxima prioridad", en realidad está diciendo que nada es prioritario. Cuando designa uno de los proyectos como "máxima prioridad", lo que está diciendo es "asigne recursos a este proyecto primero y, si quedan recursos, asígnelos a otros proyectos". Si "todo es la máxima prioridad", todos los proyectos carecerán de recursos. En realidad, se desperdiciarán más recursos en el cambio de contexto.

Creo que el dilema Scrum vs. no Scrum es un problema de segunda etapa, primero debe abordar las cosas más importantes, que en mi humilde opinión son:

1. Todo es la máxima prioridad, lo que también significa que nada lo es, lo que también significa que no tienes ninguna prioridad (o más probablemente tus prioridades son el resultado de factores/intereses antagónicos, lo que hace que las cosas sean difíciles de manejar). Eso es lo primero que debe abordar, si no tiene una idea de dónde debe invertir, será muy difícil descubrir también cómo .
2. Tienes 8 proyectos para 10 personas + 3 gerentes. No sé cómo terminó en esa configuración, pero tal vez usted (me refiero como empresa) puede explorar otras formas de administrar su sistema de desarrollo. Podría estar equivocado aquí, pero tal vez 1h * 5d * 13 personas = 65 horas/semana invertidas en coordinación para un equipo tan pequeño es demasiado...

Para solucionar estas cosas, debe tener una comprensión compartida de cuáles son los problemas que enfrenta (es decir, el gerente siente que necesita tener un estado diario completo porque, de lo contrario, no tendrá una idea clara de qué está pasando... si ese es el caso, debe trabajar para encontrar una solución a este problema) y cómo esto afecta el trabajo de cada uno, y las personas que se dedicarán a solucionar esta situación.

Como otros han señalado, esto no es Scrum de ninguna manera o forma.

¿Cómo rectificarlo?

La forma más fácil que he encontrado para reducir reuniones innecesarias como estas es cuantificar su costo.

Toma el costo diario promedio del equipo (sé conservador, aún resultará costoso). Calcule su tarifa por hora, multiplíquela por las horas por semana que toman estas reuniones, multiplíquela por la cantidad de personas en las reuniones.

Use el NÚMERO GRANDE resultante para retroceder y decir que estas reuniones cuestan $X por semana, $XX por mes, $XXX por año en costo directo, sin mencionar el costo en pérdida de productividad de hacer otras cosas. Use eso como justificación para reducir la duración, la frecuencia y el tamaño de la asistencia a las reuniones.

Cuantificar el costo real (sin incluir la pérdida de productividad) de las reuniones periódicas generalmente asusta a las personas para que encuentren una mejor manera.

1 hora a 2,5 melés largos todos los días: ¿es una locura?

No es solo una locura, está mal. Este es exactamente el tipo de situación que Scrum debe prevenir. Si tiene una reunión diaria de 1 hora (sin mencionar 2.5), lo está haciendo mal.

La gerencia requiere que todo el equipo se quede y escuche.

El primer paso para resolver un problema es reconocer el problema. Habla con un gerente; uno a uno es probablemente lo mejor aquí para que puedas hablar libremente y no tengan que responder frente a todo el equipo. Si señala el costo de estas largas reuniones (entre 65 y 160 horas-hombre por semana) y el potencial para mejorar la productividad y la moral, probablemente obtendrá un amplio acuerdo.

¿Qué decisiones tomarías?

Dividir el grupo en dos equipos y aprender a hacer Scrum real en lugar del actual Scrum solo de nombre, como han sugerido otros, son dos buenas sugerencias, pero son grandes pasos que la gerencia puede no estar ansiosa por dar. Una buena capacitación en Scrum puede ser costosa y también puede ser difícil de justificar si los gerentes les han dicho a los clientes u otras partes interesadas que usted ya practica Scrum.

Dado que el objetivo principal aquí es pasar más tiempo trabajando y menos tiempo en las reuniones, puede comenzar por reducir el tiempo permitido para la reunión diaria. La reunión debe enfocarse con láser en transmitir solo la información que ha cambiado desde la última reunión y lo que todos deben esperar para la próxima reunión. Deje de revisar cada ticket en el sprint y, en su lugar, dé a cada desarrollador 1 minuto para dar su estado:

• ¿Qué terminaron?
• ¿Qué esperan terminar para la próxima reunión diaria?
• ¿Qué, si es que hay algo, les impide hacer algo?

Si hay información detallada sobre boletos específicos que deben transmitirse, eso debe hacerse en comentarios escritos adjuntos al boleto en sí; no es necesario que se lea en voz alta o se repita durante la reunión diaria.

Otro objetivo debe ser hacer cada sprint un poco mejor que el anterior. Para fomentar eso, Scrum incluye una reunión de "retrospectiva de sprint". Esta es una oportunidad para que cualquiera en el equipo sugiera mejoras al proceso, pero no es una forma de desahogar frustraciones para todos. La reunión debe tener una agenda en la que cualquier miembro del equipo pueda contribuir (una página wiki funciona bien para esto) y la persona que dirige la reunión (no un gerente) debe ceñirse a la agenda y mantener las cosas en movimiento. Después de una explicación de cada cambio propuesto, deje que el equipo vote sobre si intentarlo o no, y tome nota para la próxima reunión retrospectiva para discutir si el cambio ayudó y debe continuar.

En todos los casos, la discusión o el argumento extensos deben presentarse y abordarse fuera de la reunión, con los resultados informados al equipo por correo electrónico, chat o como sea que el equipo se comunique de manera rutinaria.

Lo que estás describiendo está muy lejos de ser Scrum. Sin embargo, el marco Scrum le ofrece alguna orientación que podría ayudar.

En Scrum limitamos el tamaño de los equipos a un máximo de 9. Esto se hace porque hay muchas investigaciones que muestran que la comunicación en un equipo de más de 9 se convierte en una sobrecarga.

Scrum también limita las reuniones diarias de Scrum a un máximo de 15 minutos. La razón por la que el equipo apoya la reunión es que fomenta una conversación enfocada y efectiva. Vale la pena señalar que el Scrum diario se trata de la sincronización dentro del equipo y no se trata de informar el progreso. Cuando lo piensas, tener a todo el equipo reunido en una reunión cuesta mucho tiempo de trabajo perdido. Por eso es importante que el Scrum diario sea eficiente y cubra temas que afecten a todo el equipo. Cuando se plantea un tema que no concierne a todos, debe ser sacado del Scrum diario y discutido solo por aquellos a los que afecta.

Scrum también enfatiza la importancia de la priorización. La investigación ha demostrado que cuantas más tareas realiza un individuo en paralelo, menos eficientes son. Una buena priorización permitirá a los miembros del equipo trabajar de manera enfocada y eficiente.

¿Cómo recomendaría alternativas apropiadas para asegurarse de que los elementos de sprint no se queden en el camino?

Aquí es donde entra en juego el rol de propietario del producto. El equipo de desarrollo trabaja en las tareas de mayor prioridad y solo necesita concentrarse en estos elementos. Mientras hacen esto, el Propietario del producto mira el panorama general y trabaja con el equipo para refinar continuamente el trabajo pendiente.

Cometiste un error al organizarte con el equipo.

En mi opinión, necesitas estas cosas:

• Hay que desglosar los requisitos, crear tareas, estimarlos y distribuirlos. En otras palabras, esto significa que debe crear el Sprint Backlog (con el propietario del producto y el inversor)

• tienes que realizar la reunión corta de Daily Sprint.

• tiene que asegurarse de que al final del Sprint se entregue la funcionalidad potencialmente entregable.

• tienen que actualizar el estado y los esfuerzos restantes para sus tareas para permitir la creación de un Sprint Burndown Diagram (Un Sprint Burndown Diagram es muy importante)

Parece que estás describiendo reuniones y no scrum.

Scrum debe estar al comienzo del día, todo el equipo presente y de pie.

Menos de 10 minutos con un resumen de las cosas completadas/actualizaciones y un compromiso para las tareas del día actual; realizado por cada persona del equipo.

Creo que tal vez las reuniones de planificación y las reuniones de revisión de historias son sus reuniones de 1 hora.

He usado el siguiente documento "Catorce observaciones de buenas prácticas de Scrum" con éxito, espero que usted también lo haga: http://lookforwardconsulting.com/wp-content/uploads/2011/01/ScrumObservations.pdf

En resumen, un equipo Scrum generalmente consta de unas siete personas que trabajan juntas en una actividad de caja de tiempo corto llamada sprints, con suficiente tiempo para revisar y reflexionar. El mantra de Scrum es "inspeccionar y adaptar", y los equipos Scrum se caracterizan por un intenso enfoque en la mejora continua, de su proceso, pero también del producto. Los roles principales en scrum son Propietario del producto: posee e impulsa el producto y maximiza el retorno de la inversión, The Scrum master: actúa como entrenador y guía al equipo hacia una mayor eficiencia y autoorganización. El equipo de desarrollo: un equipo altamente colaborativo y autoorganizado que hace el trabajo real.

Observación-1: Sprint es propiedad del equipo de desarrollo y SM debe asegurarse de proteger al equipo durante el sprint de la interferencia de la administración que puede afectar negativamente el sprint.

Observación-2: una definición común de hecho que es el resultado de la negociación entre todos los actores en los miembros del equipo Scrum, pero el desarrollo tiene la última palabra.

Observación-3: La cartera de pedidos del producto es propiedad y está clasificada por el propietario del producto. Otro miembro del equipo puede sugerir funciones para agregar, pero es el PO quien tiene la última palabra.

Observación-4: El Equipo es responsable de sus propios compromisos y solo debe asumir compromisos que realmente sienta que va a cumplir.

Observación-5: El PO puede establecer las prioridades para el Equipo.

Observación-6: El Scrum Master no tiene autoridad sobre la actividad del equipo. El SM es quien tiene el conocimiento experto sobre el marco scrum.

Observación 7: la planificación de Sprint se trata de qué PBI construirá el equipo y cómo lo construirá el equipo.

Observación-8: acumulación de Sprint, propiedad y mantenimiento del equipo de desarrollo.

Observación-9: La reunión diaria de scrum es una reunión con límite de tiempo de un máximo de 15 minutos donde el equipo de desarrollo aprovecha la oportunidad para sincronizar sus actividades y responder las tres preguntas: ¿Qué hiciste ayer, qué harás hoy y cualquier obstáculo que otros miembros del equipo pueden resolver. El SM facilitará la reunión.

Observación-10: la revisión del sprint, es el momento para que el equipo brille y presente el incremento del sprint al PO. Solo se puede demostrar el incremento demable.

Observación-11: La retrospectiva es el momento para que el equipo reflexione sobre cómo puede mejorar.

Observación-12: las partes interesadas no tienen autoridad directa sobre el equipo y el SM debe proteger al equipo si la interacción con las partes interesadas se considera una distracción

Observación-13: si el PO decide finalizar un sprint, debe organizar una reunión de finalización con el equipo para decirle al equipo qué hay detrás de la cancelación y el equipo debe presentar elementos de aprendizaje clave para comunicar a las partes interesadas.

Consulte el archivo pdf para obtener más información.