Aplicar un enfoque Scrum uniforme a todos los equipos dentro de un departamento

Donde trabajo, recientemente cambiamos el desarrollo Agile usando Scrum. Pasamos por los típicos dolores de crecimiento, pero hemos llegado a un enfoque que parece funcionar por ahora (¡si funcionará a largo plazo es otra pregunta!).

Obviamente, la gerencia del departamento está feliz de que la transición a Scrum esté funcionando. Pero han comenzado a hacer algo que, para mí, se siente mal.

La gerencia observará a un equipo, verá qué funciona para ellos y lo prescribirá a todo el departamento. Cosas como:

• La definición de "Hecho"
• Qué valores de puntos de la historia se pueden usar para señalar la historia (por ejemplo, omitiendo 8 de la secuencia fib. Porque 1, 2, 3, 5, 13, etc. fueron los únicos utilizados durante un sprint que observaron)
• Indicar a los equipos que deben calibrar su valor de punto de historia de 1 para "actualizar una etiqueta de interfaz de usuario" y limitarlos a un límite superior de 20
  • (aunque no todos nuestros proyectos tienen clientes y no todos los desarrolladores tienen experiencia en UI)
• Decirle a los equipos que usen estimaciones puntuales de la historia de 100 para significar "dividiremos esta historia más tarde"
• Decirle a los equipos que usen estimaciones puntuales del infinito para significar "esto es una epopeya" o "necesitamos más información"

Entiendo que están tratando de ser útiles, pero ¿no deberían todas las cosas anteriores ser específicas del equipo Scrum? Es decir, lo que funciona para un grupo de individuos en un proyecto puede no tener sentido para otro grupo en otro proyecto.

Me preocupa que estemos derivando hacia un enfoque ágil muy prescriptivo y rígido. ¿Estoy justificado al pensar esto, o estoy exagerando?

Editar

Solo para aclarar ... por "Gerencia" y "Gerente" no me refiero al Propietario del Producto. Me refiero a cualquier gerente fuera del Equipo Scrum, pero dentro del Departamento de Software.

Por supuesto, estás justificado al pensar eso. El hecho mismo de que estés hablando de "hacer cumplir Scrum" es una alarmante sirena.
Scrum es ante todo sobre la autoorganización del equipo; pueden elegir cómo hacer su trabajo y cómo organizarse. La gerencia solo tiene voz en el trabajo que debe hacerse.
La razón por la cual los equipos deberían organizarse es que siempre son únicos, debido a las diferentes naturalezas de los miembros individuales del equipo (y las personas con las que trabajan) y debido a las diferencias de los productos en los que trabajan. Una práctica que funciona perfectamente bien para un equipo, puede tener efectos adversos en otro equipo. Es por eso que dentro de cierto alcance (a menudo se usa una metáfora de sandbox), tienen que experimentar, aprender y descubrir qué funciona mejor para ellos.
Lo que necesita es un Scrum master muy competente (uno por equipo), que pueda guiar a un equipo en este descubrimiento, pero al mismo tiempo también puede trabajar con la administración para obtener la libertad para que el equipo realice ese descubrimiento.

Bienvenido a una de las peores pesadillas de scrum. Te has encontrado con una de las razones por las que scrum no puede entregar las cosas geniales que todos tienen en mente al adoptarlo.

Lamentablemente, scrum no es compatible con la alta gerencia que tiende a centralizar y crear procesos de gestión en toda la organización y los equipos. Para tener éxito, la alta dirección debe cambiar su mentalidad y centrarse en lo que necesitan de los equipos. No deberían centrarse en cómo funcionan los equipos. El único momento en que deberían involucrarse es si un equipo no se está desempeñando para descubrir la razón.

Creo que tiene que sentarse con la gerencia y hablar sobre sus requisitos y lo que quieren que los equipos entreguen. Eso puede ser un requisito global para todos los equipos. Podrían ser estimaciones que entienden, duración, etc. Esas cosas no deberían dictar los procesos de los equipos. Es importante que separe las expectativas de gestión de la forma en que ejecuta scrum. Cada equipo tiene que encontrar su propio ritmo y su propia forma de conducir los proyectos, lo que los hará exitosos, productivos y entregará lo que la gerencia necesita. Si, por ejemplo, tiene una estimación de 15 puntos de historia, el equipo debería poder calcular esos puntos en días de hombre (u horas) en función de la velocidad promedio del equipo. Pero será único para el equipo.

Como empresa, equilibrar sus recursos debería ser una ventaja competitiva. De lo contrario, solo cree un grupo de compañías de software individuales que pierdan este tipo de apalancamiento. Una organización con múltiples equipos y proyectos debe preocuparse por la rotación y el equilibrio del equipo. No creo que sea una buena idea para cada combinación única de equipo reescribir el libro sobre cómo van a hacer scrum.

Cada vez que intentas agregar cosas para medir algo, la consistencia es importante, es decir, no compares manzanas y naranjas. La gerencia debe enfocarse en estas necesidades de nivel superior, pero asegúrese de que no se involucren demasiado en los detalles de cómo operan los equipos. Intenta aplicar sus sugerencias, pero prepárate para defender por qué un equipo puede ser la excepción. Cualquier persona a la que no le guste personalmente una forma particular de hacer las cosas necesita ponerse sus pantalones de adulto y lidiar con eso.

Tiene que haber cierta flexibilidad, para que pueda hacer el trabajo. Debe haber consistencia cuando sea necesario. Si se cambia la membresía del equipo, no todos deberían sentir que es su primer día en el trabajo.

Tal vez tus equipos nunca cambien, pero deberías darle una oportunidad a esa opción teniendo algo de consistencia.

No, no estás exagerando y tienes buenas razones para preocuparte. La gestión debe centrarse en el cambio cultural. La gerencia necesita establecer la dirección correcta y presentar el contexto a los equipos para que lo hagan utilizando las ceremonias ágiles que funcionan bien para que el equipo sea productivo.

Me siento afortunado de trabajar en una organización que ha estado pasando por una transformación ágil de cascada durante más de un año y comenzó en la cartera en la que trabajo. Originalmente comenzaron con un proyecto donde se formó un equipo ágil. El éxito de la entrega a través de ceremonias ágiles como retros, estimación relativa, predicción histórica usando velocidad condujo a que toda la cartera formara equipos adicionales con su propia cartera de pedidos.

Por experiencia, Agile no es prescriptivo y no puede implementar un enfoque de cortador de galletas. Solo porque funcionó en un equipo no significa que funcionará en otro. Sé esto por experiencia porque originalmente pensamos que podríamos impulsar nuevos equipos aplicando las mismas cosas como DoD, lo que significa 1 punto, lo que significa 8 puntos. Pero no funciona tan contextualmente, tienen poco significado cuando se aplican a un equipo diferente. Por cierto, para la historia de un equipo por encima de 8 puntos significaba que era demasiado grande y necesitaba dividirse.

Lo que funcionó fue establecer pautas para los equipos, como que tienen que hacer stand-ups, retros, exhibiciones al mismo tiempo y en cada acción retro donde se burlaron e implementaron para mejorar los nuevos equipos. Otras cosas, como la definición de hecho y el tamaño de los puntos de la historia, se introdujeron después de un par de sprints a medida que el equipo se familiarizó más con el concepto de narración de historias y completar tarjetas y no tener que arrastrarse al siguiente sprint.

Sé que esto es difícil de vender para la gerencia, ya que quieren saber cuándo se entregarán los proyectos y cuando se forman nuevos equipos ágiles, es difícil dar esa imagen por adelantado. Pero ahora la cartera tiene la reputación de tener una fuerte capacidad de entrega ágil. Todavía estaríamos tropezando si el enfoque del cortador de galletas continuara siendo empujado a los otros equipos.

La inconsistencia en la práctica entre los equipos Scrum puede ser un problema, por ejemplo, si los miembros del equipo se mueven entre equipos.

Sería mejor intentar resolver este tipo de problemas de intercambio de conocimientos entre equipos de una manera más ágil, tal vez algo como ejecutar sesiones de Lean Coffee o Scrum-of-Scrum que involucren a sus maestros de scrum. Con suerte, esto hará que su gerencia se dé cuenta de que se está apropiando de esta área y deje de tratar de manejar los problemas de manera descendente.