Múltiples equipos de scrum que se mueven a una sola acumulación

Actualmente tenemos 5 equipos scrum que trabajan a partir de su propia cartera de productos durante el año pasado. Cada equipo trabaja en su propio sistema dedicado, pero la tecnología subyacente es la misma .Net.

Se ha debatido mucho sobre cómo pasar a equipos basados ​​en funciones que trabajan desde una única cartera de pedidos. La razón es que uno de nuestros sistemas principales tiene una gran cantidad de trabajo por venir y su capacidad no es suficiente para entregar todo el trabajo en el año. La otra razón que creo que es importante es que brinda una mayor flexibilidad para adaptarse rápidamente a los cambios en la cartera.

Se tomó la decisión de cambiar dos equipos para trabajar en una sola cartera de pedidos, pero los desarrolladores no tienen experiencia en los otros sistemas. Una cosa que estamos haciendo es la habilidad cruzada al trasladar un desarrollador de sistemas de experiencia al equipo.

Mi pregunta es, ¿ha experimentado pasar a una sola acumulación de trabajo para dos o más sistemas diferentes? ¿Cuáles fueron tus desafíos? ¿Qué necesitabas hacer para que funcione?

Gestionamos alrededor de media docena de proyectos utilizando una sola cartera de pedidos. Digo "acerca de" porque depende de cómo quieras diferenciar los proyectos.

En términos generales, tenemos cinco o seis propietarios de productos, algunos de los cuales poseen más de un producto. Tenemos un equipo razonablemente pequeño con siete desarrolladores y un líder de equipo que también codifica cuando tiene tiempo. Y tenemos algunos evangelizadores que trabajan con nuestra gente de proceso para mover ideas a la tubería. Por supuesto, varias personas usan varios sombreros que enturbian las cosas, pero lo ignoraré como respuesta. Curiosamente, no tenemos un scrum master formal.

No tuvimos que fusionar los pedidos acumulados, pero parece una tarea sencilla de su parte.

Mantener las cosas organizadas puede ser un verdadero dolor, así que aquí hay algunos puntos que querrás considerar.

• La gobernanza es clave. Todos los que tengan un dedo administrativo en el pastel deben comunicarse con los demás antes de realizar cambios significativos. Y / o aquellos que hacen cambios deben sentirse cómodos con su autoridad para hacerlo (y estar preparados para tomar el calor por un mal cambio). Nuestros creadores de cambios tienen un fuerte respaldo ejecutivo y las líneas están claramente dibujadas alrededor de las áreas. Pero cuando hay una duda, preguntamos antes de cambiar.

• Puede haber más gastos generales relacionados con la preparación, la priorización y las pausas iniciales. La priorización como ritual es la que más sufre porque es difícil reunir a todos los propietarios de manera regular. Usamos varios intermediarios para negociar la prioridad y / o entregar las malas noticias de no hacer el recorte de prioridad.

• Gran parte de nuestro trabajo está impulsado por un compromiso externo. Eso elimina parte de la autonomía de nuestras decisiones, pero esa es la realidad de los negocios. Sin embargo, sus desarrolladores deben ser conscientes de ese cambio. Las plumas pueden erizarse si se percibe una pérdida de control. Sin embargo, tratamos de no comprometernos demasiado, y hemos tenido que decir "no" a algunos propietarios de productos que estaban a punto de llegar al sprint.

• En general, utilizamos dos métodos para etiquetar a qué producto pertenece un elemento de la cartera de productos. Usamos ambos simplemente porque facilita la preparación y otras tareas.

  1. Prologaremos el título de PBI con el nombre del producto o la versión abreviada.
  2. Tenemos un campo separado que indica el producto general, y que también debe completarse.

• Tenemos que hacer un esfuerzo consciente en el entrenamiento cruzado y asegurarnos de que todos tengan una mano en las diversas áreas. Tenemos una base de código muy grande con respecto a nuestro equipo de desarrollo. Parte del código que hacemos también es muy especializado. El liderazgo de nuestro equipo es impresionante en ese sentido y él empujará nuestro nivel de compromiso a un nivel inferior para que podamos permitirnos las ineficiencias que surgen del entrenamiento cruzado. Tener un sólido liderazgo de equipo es fundamental a este respecto.

• Hacemos nuestro mejor esfuerzo para mantener nuestros plazos de sprint. Los proyectos complejos con los miembros más nuevos del equipo se traducen en una sangría común con compromisos. El proceso en torno a su ramificación realmente ayudará aquí. Todo nuestro trabajo se realiza contra una rama que luego se fusiona con una versión troncal. También tenemos un servidor de compilación que se ejecuta todas las noches, además de disparadores ad-hoc. Los desarrolladores que rompen la compilación conocen y resuelven el problema en 24 horas. Período. Si no se resuelve dentro de las 24 horas, su compromiso se revierte y los desarrolladores principales les dan pena. Y los desarrolladores senior son más duros con ellos mismos cuando se trata de mantener la construcción.

• Los recorridos de código y las revisiones se vuelven aún más críticos. Ayuda a mantener a todos actualizados sobre lo que está cambiando en las distintas áreas.

• Del mismo modo, el standup diario involucra a todos los desarrolladores más nuestra gente de UI. Estamos al borde de la comunicación colaborativa beneficiosa y la ineficiencia de demasiadas personas. Pero mantenemos el standup a menos de 15 minutos y rápidamente pasaremos de las discusiones paralelas. Por lo general, terminamos en 5 a 10 minutos.

• No puedo hablar de los efectos en métricas como la velocidad o el compromiso general y las tasas de consumo. Esos aspectos simplemente no han sido lo suficientemente importantes para que los sigamos de cerca. YMMV, así que tenlo en cuenta. Esto también supone que cada equipo tiene una definición razonablemente similar de punto de historia. Si no, eso arruinará las estimaciones iniciales después de la fusión. También generará algunos problemas para las comparaciones históricas, ya que no está utilizando la misma unidad de medida que antes. La salida fácil es declararlo como un "nuevo equipo" para las métricas y comenzar a recopilar datos después de la fusión.

• Hemos visto un beneficio significativo de este enfoque. Hemos tenido algunos sprints donde todas las manos están enfocadas en un área y podemos eliminar muchos cambios en un corto período de tiempo. No debe subestimar el valor que proviene de poder aplicar rápidamente el doble del número normal de desarrolladores en un proyecto en particular. Pero tienes que poner el entrenamiento cruzado antes de tiempo. También significa que nunca tenemos desarrolladores con "nada que hacer" debido a los ciclos de prueba o la preparación o lo que sea. Siempre tenemos una acumulación de pedidos pendientes.

• Dedicar tiempo a proyectos de I + D. De lo contrario, es demasiado fácil para ellos pasar por alto y perder la oportunidad de invertir en esas áreas.

• Realmente trabaje en la codificación sin ego y que si bien puede tener expertos en un área, no tiene propietarios de un área de código. Prevenir la oportunidad de egos magullados es importante cuando se introducen diferentes estilos en un área. Mientras el nuevo código cumpla con los estándares del equipo y sea funcional, debería ser bueno. El hecho de que no sea cómo lo habría hecho el experto no importa.

• Asegúrese de que los equipos involucrados estén usando las mismas convenciones y estilo de codificación. Nada como la inconsistencia aquí para causar estragos en sus intentos de integración.

• Sigue sosteniendo tus retrospectivas, y mantenlas como un grupo. Es importante obtener los comentarios de todos sobre lo que funciona, lo que no funciona y lo que debe probarse de manera diferente. Esto ayuda a generar una sensación de camaradería dentro del equipo y brinda un sentido de pertenencia en todo el proceso de desarrollo.

La respuesta correcta de Scrum es "Pregunte al equipo (s)". Este es el principio de autoorganización donde deberían poder reestructurarse para hacer el trabajo rápidamente. Usted ve que muchas personas en los equipos tienen más conocimiento del contexto que un extraño y saben lo que es mejor. Esto también incluye al propietario del producto.

Supongo que viniste aquí y hiciste la pregunta ya que hay algo que no se siente bien y tienes preocupaciones ocultas. Así que les daré algunos consejos para discutir con el equipo y llegar a la decisión correcta.

Dueño del producto

Solo hay un propietario de producto para una cartera de pedidos y este debe ser una persona de negocios o una persona que represente a una empresa. No debería ser la gestión de TI. Una gran cartera de pedidos tiene muchos elementos y, con varios equipos, podría ser demasiado para un solo PO. Es posible que desee mantener los retrasos separados por este motivo.

Si hay múltiples PO, entonces definitivamente necesita múltiples atrasos ya que los equipos deberían dedicarse en un sprint a un solo PO y atrasados. La razón es que un equipo no necesita gestionar conflictos entre las prioridades de los propietarios de productos.

Desarrollo de producto versus mantenimiento

Los equipos de mantenimiento trabajan en muchas mejoras pequeñas, errores en varios productos diferentes y posiblemente con varios propietarios de productos. Estos equipos de BAU necesitan el apoyo de la administración de TI para ayudar a programar y gestionar los conflictos entre múltiples propietarios de productos.

Los equipos de proyecto deben centrarse en un producto a la vez para minimizar el cambio de contexto y entregar un gran producto a la vez. El cambio de contexto podría resultar en la entrega de muchos productos mediocres con cierto grado de deuda técnica.

Cambio de contexto

Trabajar en múltiples productos o en diferentes características provoca un cambio de contexto que ralentiza la productividad de los equipos. El PO debe tener esto en cuenta al calcular qué sigue y qué equipo debe trabajar en qué parte del trabajo. La cantidad de cambio no es insignificante y no es solo una cuestión teórica, es real y he sido testigo de una caída del equipo de hasta el 80% en la productividad debido a esto.

Un buen PO probará las características grupales y el tipo de trabajo para ayudar a los equipos a hacer menos cambios de contexto, mejorando así su rendimiento.

Riesgo

Lamentablemente, la gerencia intenta poner el riesgo de tiempo, dinero, presupuesto y presiones comerciales en el equipo; y los equipos aceptan esto al aceptar esto. Como profesional del desarrollo, simplemente debe indicar los hechos e impactos de las decisiones y hacer que el negocio sea su propio riesgo.

Ejemplos

• De acuerdo a un tiempo ridículo. Más bien diga qué esfuerzo se va a tomar para hacer el trabajo correctamente y hacer que las empresas gestionen el problema del tiempo

• Estimaciones Las empresas esperan que los equipos estimen con precisión en un mundo de complejidad e incertidumbre. Los equipos deben preguntar a las empresas qué están haciendo para mitigar si se exceden las estimaciones debido a desafíos imprevistos, que son muy probables. Los equipos no deben tener en cuenta la grasa, sino los negocios.

• Deuda técnica. Los equipos deben calcular el código de alta calidad que está completamente probado y calcularlo, es decir, dejar de escribir defectos debido a presiones. Si las empresas quieren una calidad inferior, entonces es su riesgo asumirlas y cuando las cosas salen mal es su problema.

Profesionalismo

Sea un profesional al establecer la construcción de las cosas correctas con la calidad acordada. Estima a tu mejor capacidad en función de los hechos disponibles. Cuando estos hechos cambien, comuníquelo y ajuste la estimación. Como equipo de desarrollo, cree excelentes productos y no asuma riesgos comerciales. Comunicar y gestionar las expectativas.

Inspeccionar y adaptar

Los equipos siempre deben buscar formas de mejorar y si sienten que mejorará las cosas, deberían intentarlo. Luego inspeccione para ver si hay mejoras. Finalmente, deberían adaptarse y mejorar su nuevo enfoque o desecharlo si no funciona. La intención detrás de buscar mejorar siempre debe estar ahí.

Línea de fondo

En definitiva, la gestión de la cartera de pedidos es la elección de la OP. Cómo él / ella quiere gestionar la cola de trabajo depende de ellos. Lo único que se piensa es que DEBEN mantener la línea de trabajo para TODOS los equipos saludables y en buen estado. Por lo tanto, depende de la OP decidir.

El contrato

En las sesiones de planificación de sprint, el equipo debe esperar una lista de elementos de la cartera de productos preparados que sean claros, inequívocos y ordenados. Con una breve discusión con el OP, el equipo debe saber exactamente lo que quiere el OP; el que . Luego, el equipo se concentra en cómo van a construir.

Si la OP llega a la reunión de planificación bien preparada, a quién le importa cómo se gestiona la acumulación. Si la OP no está preparada para la reunión de planificación del sprint, el SM debe abordar esto y hacerlo muy visible, ya que esto es totalmente inaceptable y no es un problema del equipo.

Recientemente absorbimos la cartera de pedidos de otro equipo. El equipo solo tenía un miembro (no sé mucho de un equipo, lo sé), pero hay trabajo real en su cartera de pedidos. No estamos muy familiarizados con su trabajo, y tampoco están muy familiarizados con el nuestro.

A pesar de que sus trabajos pendientes se fusionan, eso no significa que todos tengan que trabajar en todo de inmediato. No es razonable esperar eso, así que no te preocupes demasiado por que todos puedan hacer todo en ambos registros de forma inmediata.

En cambio, comience haciendo que ambos equipos trabajen exactamente en lo que estaban trabajando antes; La única diferencia es que todo está en la misma cartera de pedidos.

Luego, cada iteración / sprint hace que algunos de los miembros de cada equipo trabajen en historias de la otra cartera de pedidos. Al no tener a todos trabajando en artículos desconocidos al mismo tiempo, se extiende el costo de aprender los sistemas de los demás . Con el tiempo, su equipo absorberá gradualmente el conocimiento de los demás.

Si hace todo el aprendizaje por adelantado, habrá penalizaciones de rendimiento significativas. Alguien de la alta gerencia seguramente lo notará, y se verá obligado a absorber la acumulación de trabajo de otro equipo con la esperanza de que el nuevo equipo pueda compensar el bajo rendimiento ... :) Bromas aparte, sin embargo, esta sería mi recomendación.

Supongo que la razón por la que usted (o la gerencia) desea crear una cartera de pedidos combinada para dos equipos es que desea poder elegir solo elementos de la cartera de pedidos para uno de los sistemas y hacer que ambos equipos trabajen en ellos.

Cuando este sea el caso, espere mucha fricción del equipo que se ve obligado a trabajar en el sistema con el que no están familiarizados. Espere que el equipo tome cada gota de agua (es decir, un pequeño elemento de la cartera de pedidos relacionado con su sistema de "casa") para seguir trabajando en el sistema en el que estaban trabajando antes. ¿Quién tiene la culpa de ellos? No es divertido trabajar en algo en lo que no eres bueno. Y el hecho de que el otro equipo sea bueno como algo en lo que no eres bueno lo empeora, porque te hace ver aún más tonto.

Por lo tanto, la única forma de hacer que esto tenga éxito es dividir los dos equipos y formarlos en dos equipos mixtos. Solo entonces, existe la posibilidad de que todos los desarrolladores se pongan al día rápidamente en el sistema (actualmente) "importante".

Eso no es muy bueno para que sea así. Mi compañía anterior, entró en modo de equipo único de producto único porque en una compañía grande, teníamos diferentes personas trabajando en cosas diferentes.

Cambiar entre proyectos también cuesta esfuerzo, y si hay una nueva persona para comenzar a desarrollar gastos generales es realmente grande. Uno tiene que obtener derechos de acceso al sistema desarrollado, repositorio diferente, etc.

Prefiero la especialización, las personas saben lo que están haciendo, tienen toda la información necesaria, conocen las trampas del proyecto y las personas no tienen la sensación de que tienen que abandonarlas de un proyecto a otro para que trabajen, para chupar cada centavo. ellos.

Incluso si están inactivos en su proyecto, son mucho más productivos en lo que conocen, que saltar de un proyecto a otro.