Errores más frecuente al implantar Scrum
Vamos a repasar en este artículo los errores más frecuentes al implantar Scrum y sus consecuencias.
Muchos de los proyectos en los que participamos han comenzado su transición a las metodologías ágiles. El resultado más visible es que hacen ‘sprints‘ de tres o cuatro semanas, pero los incrementos de productividad siguen siendo una promesa. Los proyectos continúan con sus dinámicas previas.
Y tiene sentido. ¿Por qué hacer el mismo trabajo en bloques de tres semanas va a mejorar la productividad? Scrum es mucho mas que sprints o tableros con post-it.
Estos son los errores más habituales al implantar Scrum:
1. No subir los desarrollos a producción después de cada sprint.
Quizás el error más frecuente y también el más importante. Asume que tu cliente no puede saber lo que quiere y que tendrás que modificar el trabajo realizado. Cuanto antes descubras lo que en realidad necesita, más productivo será el proyecto.
Además, como la inversión económica de un sprint es pequeña y tu cliente utiliza las nuevas funcionalidades en tres semanas, su retorno de inversión -ROI- es mucho más rápido. Música celestial para cualquier CFO.
En las metodologías tradicionales los desarrollos se entregan al final del proyecto. Esto no solo retrasa el ROI. Comienzas las modificaciones cuando ya no queda presupuesto.
La única forma de comprobar que has acertado es poner el software en manos de sus usuarios finales.
2. Obligar a que se finalicen todos los trabajos planificados para el sprint.
El segundo error clásico. Si te has equivocado en el sprint planning y no es viable finalizar los trabajos, ¿cuáles son las posibles opciones?
a) Puedes pedir al equipo que haga un sobreesfuerzo y trabaje más horas.
b) Puedes rebajar la calidad y no hacer las pruebas de regresión.
c) Puedes rebajar el alcance y entregar menos desarrollos.
Por inercia cultural, la mayor parte de los proyectos comienzan por la opción a) y terminan por añadir la opción b). Scrum establece que la respuesta mas apropiada es la c).
Buena parte de los incrementos de productividad asociados a Scrum proceden de eliminar la presión de trabajo de los consultores.
3. No tener un Product Owner integrado en el equipo.
El Product Owner es una figura esencial en Scrum, y es otra de las vías del incremento de productividad.
Los programadores trabajan sin una especificación detallada, así que constantemente tienen dudas sobre la funcionalidad a desarrollar. Es necesario que alguien procedente del cliente les explique las Historias de Usuario.
El Product Owner es también el guardián del ROI. No sabe programar, pero entiende el valor que aporta cada Historia al negocio. Si prioriza adecuadamente los desarrollos, conseguirá un mayor retorno de inversión en cada iteración.
Si el Product Owner no está con su squad, los programadores no interpretan bien las Historias, las modificaciones son más frecuentes y el valor para el negocio de cada sprint es menor.
¿Hay más errores típicos?
Aunque estos sean los tres errores más frecuentes al implantar Scrum, hay otros muchos que puedes cometer. Sin ánimo de ser exhaustivos:
Hacer una especificación pesada.
En Scrum se pasa de una idea de alto nivel al desarrollo que hacen los programadores. ¿Para que emplear meses en una especificación detallada si damos por sentado que el cliente no puede saber lo que quiere?
Solicitar que el cliente valide la especificación.
Aunque el cliente firme la especificación, sigue sin ser lo que necesita. Y lo sabe. Tu equipo puede estar valiosas semanas esperando a que el cliente dé su consentimiento. ¿No es mejor emplearlas en desarrollar un prototipo?
Mantener las jerarquías dentro de los equipos.
Ni el Jefe de Proyecto se transforma en Product Owner ni el Líder Técnico en Scrum Master. La figura del Líder Técnico desaparece. Los programadores colaboran desde un plano de igualdad y ninguno impone su criterio a los demás.
El Jefe de Proyecto también se difumina porque ya no es necesario negociar alcance y plazo de cada desarrollo.
No automatizar las pruebas a la vez que se hacen los desarrollos.
Si no automatizas las pruebas, ¿cómo piensas hacer DevOps? No podrás hacer pruebas de regresión y con cada sprint tus desarrollos tendrán menor calidad.
Tener a los equipos separados geográficamente.
No es solo que no puedan hacer el daily. Recuerda que los equipos están creando la especificación a la vez que hacen el desarrollo. Si están separados ¿cómo van a construir ese conocimiento?
No hacer retrospective.
Celebrar los éxitos del sprint y analizar los puntos de mejora aporta cohesión y les permite crecer como equipo. Potencia estos momentos de reflexión para que crezcan en la aplicación de la metodología.
Algunas reflexiones finales
Si has llegado hasta aquí, es porque te interesa la ingeniería del software. Te dejo algunas reflexiones y enlaces para que prosigas tu crecimiento.
Lo primero que debes entender es que el software es diferente al resto de disciplinas de la ingeniería por muchos motivos. Quizás los dos más importantes son:
- Es mucho más complejo describir el comportamiento de un sistema software que de cualquier otro sistema ideado por ingenieros, ya sea un vehículo eléctrico, un puente, un edificio o un compuesto químico. Por eso decimos que el cliente no puede saber lo que quiere.
- No tenemos un lenguaje de alta precisión para describir el software. Por contra, el resto de ramas de la ingeniería disponen de los planos, las matemáticas y la física. Por eso decimos que el cliente no puede decirnos lo que quiere.
No es de extrañar que la tasa de fracaso de los grandes proyectos de software sea del 80%. Esta cifra se mantiene estable desde los años 70. Y es el motivo de la aparición de Scrum.
Así que olvídate de gestionar los desarrollos informáticos como si fueras un ingeniero. Quema tu apuntes de ITIL. Necesitas un enfoque que incluya la psicología. Tu punto de partida es Peopleware, de Tom de Marco. Puedes acceder a su ficha en la wikipedia haciendo click sobre estas palabras verdes.
En novanotio explicamos a nuestros consultores estos conceptos que necesitarán a lo largo de su carrera profesional. Si la gestión de proyectos o el liderazgo de equipos despiertan tu curiosidad, quizás quieras descubrir nuestro proceso de mentoring Novanotio Certified.
Tal vez sea un buen momento para incorporarte a uno de nuestros proyectos y establecer los cimientos de tu carrera con nuestro proceso de mentoring. Este enlace te lleva a algunas de nuestras ofertas de trabajo, espero que encuentres una perfecta para ti.