Scrum: El camino del menor gasto de energía

Y por fin hacer software es algo divertido, algo que anima y reta, y no algo que devoraba implacablemente el tiempo de:nuestr@s novi@, espos@, hij@s, amigos y por ende de nuestro merecido descanso (sea cual sea la forma que le queramos dar).

Y recordando mis clases de mecánica de fluidos, recuerdo que el agua siempre elegía el camino (la línea) del menor gasto de energía – o camino óptimo – (no les suena similar a Lean, eliminando el desperdicio) y así se ha vuelto para mi Scrum. La forma de gastar la menor cantidad de energía para llegar al resultado esperado.

Antes nos desgastábamos en tantas cosas, wow, con solo pensar en la desconfianza típica entre cliente y proveedor, a eso súmele:

• las reuniones tediosas de levantamiento de requisitos
• el juego de las estimaciones, que nunca le acertábamos (cosa que si añoraba de mi anterior reencarnación – la ingeniería civil –  y que volví a recuperar con Scrum)
• la llenadera de actas, y documentos como evidencia de la desconfianza
• el seguimiento constante al riesgo
• la preocupación con el alcance
• el salir perdiendo siempre como proveedor (pues como vamos a perder ese cliente tan importante, regálenle esas horas)
• las horas exhaustivas de pruebas
• el querer comprimir inútilmente el tiempo de pruebas para luego dolorosamente comprobar que ese tiempo NUNCA lo debimos haber recortado.
• el decirnos mentiras entre todos y prometer con firma de sangre fechas que no íbamos a cumplir nunca (si realmente hubiera puesto mi sangre en esos compromisos no estaría escribiendo este post)
• la amistad e idilio entre cliente y proveedor que termina siendo el peor de los odios, o un matrimonio del cual ambos quieren salir pero muchas veces no encuentran como.
• y uno como gerente de proyecto, consultor, desarrollador, comercial en la mitad viendo como pasa todo eso y día tras día, proyecto tras proyecto, el problema se repite una y otra vez..

Pero afortunadamente surgió el Manifiesto Ágil http://agilemanifesto.org/, y poco a poco los que estábamos enamorados de metodologías como RUP – iterativo, incremental y lógico -(que muy contadas veces la vi aplicar correctamente, por lo general venden RUP como un proyecto con las 4 fases – inicio, elaboración, construcción y transición-  cada una de una sola iteración y en especial la de construcción de una sola iteración convirtiéndolo el proyecto en el odiado y reconocido cascada con todas sus consecuencias funestas),vimos como fue creciendo bajo su sombra el arbolito de las metodologías ágiles y hoy más de 12 años después comienza a ser la respuesta a mi pregunta:

¿Por qué si hacer software es tan apasionante, resulta siendo tan frustrante? (últimamente le estaba diciendo PROGRAMACIÓN ORIENTADA A LA FRUSTRACIÓN POF o en inglés FRUSTATION-ORIENTED PROGRAMMING FOP)

o mejor

¿por qué si hacer software es tan apasionante, no es divertido?

Veía y veo iniciativas como CMMi, PSP /TSP tratando de enmarcar cosas que tienen que ver con la creatividad y la imaginación (wow casi no lo reconozco… siempre he sido fiel seguidor de los modelos de calidad, y de apoyar la escritura de código como trabajo de ingeniería, más hoy como una revelación comprendo que hay mucho de arte de libertad-controlada como diria Alan Cyment) y que en su afán de enmarcar y definir todo, terminan haciendo esto que se ve tan divertido o que uno lo imagina así al ver videojuegos en algo digno de señores de corbatas que no aman lo que hacen y que no ven la hora de ser gerentes de proyecto, o hacer un posgrado en administración, finanzas o cualquier otra cosa para cambiar de negocio.

Hoy veo a Scrum junto con las prácticas ágiles de ingeniería como el renacer de la pasión de mi equipo de trabajo, como el renacer de mi pasión por crear y proponer cosas nuevas, como el renacer de la creatividad y de la confianza entre cliente y proveedor.

Y son pequeños hechos, pequeños caos controlados, grandes destellos de creatividad en espacios delimitados de tiempo los que están dando orden a aquello que me atrajo en un principio y que amo tanto:

• los dailys sincronizan al equipo
• los planning nos comprometen
• los review nos enorgullecen o nos hacen sonrojar cuando fallamos (retandonos a ser mejores)
• las retrospectivas nos ayudan a ser mucho mejores
• las reuniones innecesarias no existen
• las reuniones de temas que tenemos que trabajar dentro de un mes o más no existen, por lo tanto tanta complejidad se va perdiendo.
• La verbalización y activación de la comunicación agiliza el desarrollo y afianza el compromiso.
• el horizonte de estimacion es de 2 semanas haciéndonos más precisos y no tenemos sorpresas.
• ver software funcionando (como lo expresa el manifiesto ágil) es el mejor indicador de avance y de felicidad del equipo y del cliente
• el coraje del equipo esta jalando hacia la mejora continua
• si hemos de fallar, fallamos a las 2 semanas y no a los 4 meses.
• el framework de Scrum y las prácticas agiles de ingeniería estan pensados en la mitigación del riesgo.

Definitivamente ganamos todos

• software funcionando y bonito (pruebas unitarias y funcionales automatizadas)
• cliente contento
• equipo contento
• scrum master contento
• gerente del cliente y del proveedor contento.

Creo que por fin encontramos el santo grial del software, lo que nos va a sacar de pobres, la gallina de los huevitos de oro

Ahora mis grandes interrogantes son:

• ¿que huevitos quiero poner?
• ¿mi ciuidad,. mi país, y latinoamérica aprovechará esta gran oportunidad?

Post original en: http://lecciones-aprendidas.blogspot.com/2013/04/scrum-la-linea-del-menor-gasto-de.html