¿Cuáles son los principales indicadores probados para la productividad del desarrollo de software Agile / Scrum?

La gente frecuentemente me pregunta alguna versión de esta pregunta: “¿Cómo puedes probar que Scrum es mejor que una cascada?” ¿Qué puedo medir que muestre definitivamente que un proyecto realizado con Scrum produce un mejor resultado que si hubiera usado otro enfoque? ”

Aquí está lo complicado de esa pregunta: la prueba resulta ser algo bastante subjetivo .

Te daré un ejemplo. ¿Eres una persona feliz? Digamos que me dices “Sí, soy una persona muy feliz”. Ok, demuéstralo. No estoy convencido de que seas feliz, así que demuéstrame que lo eres. ¿Cómo abordarías un ejercicio así?

Podrías dar evidencia para tratar de convencerme. Podrías hablarme de familiares, amigos, pasatiempos, todas las cosas que, cuando se miran juntas, dices, demuestran que eres feliz.

Pero ellos?

Conozco a muchas personas que tienen todas esas cosas y todavía se consideran infelices. ¿Cómo pueden los mismos factores empíricos conducir al éxito (felicidad) en un escenario y al fracaso (infelicidad) en otro?

Te encuentras con el mismo problema cuando intentas crear una lista de cosas para medir para “probar” que Scrum está funcionando o incluso “probar” que un proyecto fue exitoso. Después de todo, ¿qué constituye un proyecto “exitoso”? ¿Que se entregó a tiempo y dentro del presupuesto? Cualquiera que haya construido “estanterías” le dirá que ese no es el caso. Para su información: si no está familiarizado, el término “estantería” describe el software que cumplió con los requisitos … pero no es lo que el cliente realmente quiere, por lo que nunca lo utilizan.

Cuando mides lo que obtienes al usar un enfoque ágil como Scrum, te animo a mirar los resultados del proyecto de manera integral. Ninguna pregunta y ciertamente ninguna estadística le dirá si Scrum está “funcionando” y mucho menos si está funcionando mejor que un enfoque diferente.

En mi propia carrera, comencé a buscar una forma diferente de administrar proyectos después de un desastroso proyecto en cascada de varios años. En mi opinión, el único criterio de éxito que buscaba en el futuro era que nunca más tuve que experimentar un proyecto tan horrible. Y no lo he hecho. Incluso mis proyectos Scrum menos que estelares fueron mejores que ese primer y horrible proyecto. Eso me dio evidencia de que podría haber una mejor manera de lidiar con proyectos grandes y difíciles de manejar.

Avance rápido un par de años. Estaba gestionando un proyecto en el que utilizamos mucho personal contratado. No sé si fue el hecho de que eran contratistas o simplemente no les gustaba dar malas noticias, pero tenían la costumbre de nunca decirme que íbamos a perder una fecha límite hasta la hora 11. No parecían entender cómo esto me puso en una posición difícil con las partes interesadas. Pero cuando comenzamos a hacer Scrum y teníamos el punto diario de inspección y adaptación del Scrum diario, descubrí los problemas mucho antes, lo cual fue muy útil. Más evidencia de que Scrum funcionó mejor que otros enfoques que había usado.

Ahora avance rápido hasta el día de hoy.

Como propietario de dos pequeñas empresas diferentes, invariablemente tengo más ideas y oportunidades que tiempo y dinero para actuar en esas situaciones. Pensar implacablemente como el propietario de un producto, volver a priorizar constantemente para equilibrar los objetivos a largo plazo con los requisitos y oportunidades emergentes, asegura que tome decisiones que muevan a nuestros negocios en la dirección que queremos que vayan.

Finalmente, para saber si Scrum está “funcionando”, miro para ver si un proyecto logró lo que considero que es el objetivo final de cualquier enfoque ágil: que entregó el mayor valor comercial posible por el tiempo y el dinero que se gastó. La verdad es que a veces pensamos que tenemos X meses para completar un proyecto … pero luego la línea de tiempo se acorta. Creemos que tiene Y dólares en presupuesto para gastar … y luego se recorta el presupuesto. No podemos gestionar un proyecto con factores como el cronograma y el presupuesto si esos factores pueden cambiar.

Pero podemos lograr el valor comercial. Los métodos ágiles como Scrum, con su enfoque empírico para la gestión de proyectos, nos ayudan a garantizar que entreguemos el mayor valor posible por el tiempo y el dinero que tenemos que gastar.

¿Y qué es exactamente el valor comercial? Ah … esta es la pregunta que debemos hacer primero, antes de todas las mediciones y el seguimiento. Antes de que pueda averiguar si Scrum creó más valor para usted que otro enfoque, debería saber cuál era el valor que estaba tratando de crear.

Porque el valor comercial, como la felicidad, puede ser terriblemente difícil de describir empíricamente … pero lo sabes cuando lo ves 🙂

La mitad de los equipos “ágiles” no tienen software de trabajo al final de un sprint. Esto evita ingresar el aspecto de comentarios del cliente y retrasa las pruebas. Para productos complejos como el sistema operativo, se tarda 24 veces más en probar tres semanas después de encontrar un error. Para aplicaciones de TI simples, el retraso será de al menos 2-4 veces. ¡Esto no es ágil!

Los indicadores están directamente vinculados con el crecimiento del negocio. Los indicadores probados son tiempo de lanzamiento al mercado, producto innovador, satisfacción mejorada del cliente por resolución más rápida.