¿Cómo mide un equipo scrum su productividad frente a su productividad previa al scrum?

Trabajé con una organización que estaba en una posición similar. Comenzaron a adoptar Scrum antes de medir la efectividad de la antigua forma de trabajar.

Encontraron algunas métricas para comparar usando datos históricos:

• Examinaron documentos/correos electrónicos de proyectos antiguos y midieron cuánto tiempo transcurrió desde la solicitud de trabajo inicial hasta que algo entró en producción, luego lo compararon con los tiempos equivalentes en proyectos basados ​​en Scrum.
• Tenían algunas encuestas de usuarios comerciales antiguas que hacían preguntas como "¿Está satisfecho con el tiempo que lleva completar los proyectos?". Usando preguntas muy similares, encuestaron a las mismas personas nuevamente y compararon entonces con ahora.
• Examinaron las cifras históricas de defectos de producción de los proyectos y las compararon con las cifras que se produjeron en los proyectos recientes de Scrum.

Puede que no le sorprenda que, en ausencia de datos de proyectos anteriores, es difícil mostrar mucha comparación. Puede usar alguna estimación relativa en proyectos anteriores y tomar dos de tamaño similar o funcionalidad similar y compararlos.

Usted menciona específicamente el hecho de que se siente más rápido y, a veces, lo es, pero puede ser más difícil obtener números exactos. Sin embargo, probablemente tenga estos números: compare la generación de valor/ingresos de un proyecto en scrum que usa versiones iterativas con uno que tiene una gran versión al final. Si lo graficas, probablemente se verá así:

No se trata exactamente de Scrum, sino más bien de lanzamientos iterativos o lanzamientos al final del proyecto. Sin embargo, podría proporcionar algunos de los datos duros que está buscando.

Más allá de eso, también puede establecer una línea base de sus datos a medida que su equipo adopta Scrum y luego mostrar que mejora con el tiempo y que el equipo puede mejorar continuamente. Nuevamente, esto es más una promoción para los bucles de retroalimentación que obtienes en Scrum que Scrum en sí mismo, pero probablemente esté bien.

RESPUESTA CORTA

1. Evalúe los tiempos y cronogramas de entrega de sus procesos anteriores (cadencia de entrega)
2. Recuerde, la medida principal del éxito es el software que funciona: muestre su cadencia de entrega en Scrum y la diferencia entre ahora y en el pasado.

Ejemplo adicional: una vez trabajé en un proyecto que tenía 8 herramientas desarrolladas para buscar diferentes tipos de inventario. Cada tipo de inventario (50 en total) tenía su propio conjunto de requisitos. En cascada, mi cliente recibió 8 herramientas en aproximadamente 8 años (en un entorno heredado de fusión en frío). Desarrollamos un motor de plantillas en Java y creamos las nuevas herramientas utilizando Scrum y DevOps y creamos 45 herramientas en menos de 6 meses. Utilizamos técnicas de estandarización de acceso a datos, como las API de capa de servicio, para poder predecir cómo se almacenarían los datos en el futuro, lo que nos permitió esencialmente escribir pequeños archivos de configuración para cada tipo de inventario; el motor de plantillas hizo el resto.

En Scrum, la productividad se mide en términos de entrega real.

Si Scrum se utiliza para el desarrollo de software, el software que es valioso para los usuarios finales se entrega después de cada Sprint. Un pronóstico preciso del Sprint Backlog, el cumplimiento de un Sprint Goal y un Product Owner satisfecho son suficientes para medir la Productividad.

Puede aplicar medidas de ingeniería de software objetivas, como puntos de función, contra el software que se desarrolló utilizando otro enfoque y compararlo con los puntos de función entregados en la misma cantidad de tiempo en Scrum.

Sin embargo, dudo que este tipo de enfoque lo ayude a convencer a los desarrolladores para que usen Scrum.

Al avanzar con esto, tenga en cuenta que generalmente "obtiene lo que mide". La velocidad y la calidad son buenas, pero no a expensas de otras áreas: felicidad, propiedad, autonomía, experiencia en el dominio/forma en T, descentralización de habilidades y conocimientos, sostenibilidad, etc.

En mi experiencia, estos a menudo tienen un impacto mucho mayor en el valor real entregado, son mucho más difíciles de medir y no se representarán en los datos de conteo de defectos o velocidad.

Realmente me gusta la respuesta de Barnaby, sin embargo, no estoy seguro de si puede hacer la comparación adecuada que pueda convencer a los escépticos y nerds de datos. El problema es que con esta configuración en particular no es posible saber por qué los proyectos posteriores funcionan mejor (o peor).

En mi opinión, dos factores funcionan aquí: la forma antigua estableció buenos fundamentos, por lo que la nueva forma simplemente juega con ella y se basa en ella, o la nueva forma realmente logró reformar. Creo que no hay forma de probar el segundo factor, hasta que no se pueda falsear el primero.

Es un problema común en los deportes. Hay deportistas que no ganaron nada relevante en su carrera como deportista joven, pero cuando se incorporan a la competición de adultos empiezan a ganar. Los entrenadores tienden a decir que el cambio funcionó, sin embargo, en varios casos, los entrenadores que trabajaron con ellos cuando eran más jóvenes establecieron todos los fundamentos (principalmente físicos) que fueron clave para comenzar a ganar.

Si realmente quiere probar algo aquí, vuelva a la forma anterior para un par de sprints/iteraciones . Tiene datos de su scrum y puede recopilar datos de su antigua forma de hacer negocios, porque ahora sabe lo que está buscando. Su caso debe ser reversible ; si su prueba muestra que la forma antigua es peor que scrum, tiene sus resultados. Sin embargo, si los resultados no son definitivos, lo único que se puede decir es que la nueva forma sienta mejor, lo cual es bueno, pero nunca será suficiente.